Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I ran this command: wacs --emailaddress support@REMOVEDTOAVOIDSPAM.co.uk --accepttos --target manual --host www.northardenpcn.co.uk,northardenpcn.co.uk --manualtargetisiis --validation filesystem --validationmode http-01 --webroot PATHREMOVED\Public --keepexisting --installation iis --siteid 18 --installationsiteid 18
It produced this output:
ACME server https://acme-v02.api.letsencrypt.org/
No luck yet, attempting to force TLS 1.2...
Unable to connect to ACME server
IIS version 10.0
Running with administrator credentials
Scheduled task looks healthy
Please report issues at GitHub - win-acme/win-acme: A simple ACME client for Windows (for use with Let's Encrypt et al.)
Running in mode: Unattended
Target generated using plugin Manual: www.northardenpcn.co.uk and 1 alternatives
(Win32Exception): The message received was unexpected or badly formatted.
Wrapped in AuthenticationException: Authentication failed, see inner exception.
Wrapped in HttpRequestException: The SSL connection could not be established, see inner exception.
The operating system my web server runs on is (include version):Windows Server 2016
I can login to a root shell on my machine (yes or no, or I don't know): I don't know
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): WACS
All working fine until yesterday. One manual cert request failed with the above, then next was fine. Today all fail. Firewall is allowing the traffic out. Could https://acme-v02.api.letsencrypt.org/ be blocking us for some reason?
You might also need to update win-acme to a more recent version; The "No luck yet, attempting to force TLS 1.2..." message was changed in version 2.1.14 which was released in 2021.
Have you recently had changes to your network configuration?
Because HTTP requests on port 80 cannot reach you. See: Let's Debug
And, HTTPS requests connect but with an invalid expired certificate for a different domain name. See: SSL Checker
Now, these are inbound requests to you and you are showing a problem with an outbound connection to the Let's Encrypt API server. But, this looks to me like something changed in your system.
The firewall does allow http requests on port 80 but only for acme-protocol. I can see some of those being allowed through today. Not sure what Let's Debug is doing. Is there a way to see what IP address Let's Debug was using so I can see if I can find the logs?
Is this the first time for this domain name using HTTP Challenge? Just curious. The cert history for that domain only shows wildcard certs probably issued through Cloudflare Universal SSL.
Does your firewall have a log of rejections?
It is probably the same source IP as shown by a DNS query of letsdebug.net I don't know if L/D rotates its IP or similar but might be that.
while non-intuitive, 'acme-protocol' in FortiGate only means challenge traffic from LE(or other acme CA)'s validation traffic, not your connection to ACME API
I remember this because when they added new class in firewall menu(default blocking) they errored out on challenge not connecting to acme server
@Damo: Based on our discoveries in this possibly-related issue: Might you have configured your server to limit the enabled cipher suites, either through group policy or through software like "Nartac"? The Let's Encrypt API endpoint recently changed from using RSA to ECDSA, which most systems should support but some over-zealous "hardening" might have disabled ECDSA cipher suites on your server.
I'll also second the previous recommendation to make sure you're on the latest version of win-acme. Or you might want to switch to the newer simple-acme fork. But I don't think that'll help on its own, until you sort out why you can't connect to the Let's Encrypt API. Once you can connect to it, the error message should change if port 80 connectivity inbound to your system is still a problem, as some posters above think might also be a concern.
Hi Mike,
This sounds like it.
Output of that powershell command for us is...
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Thanks
@Bruce5051@MikeMcQ
Some geoblocking is in place but we've seen and resolved issues with that in the past and not being able reach https://acme-v02.api.letsencrypt.org/ to start the process, even after I unblocked the range for that, was new. I whitelisted the IP for Let's Debug so that reports ok Let's Debug . It was still not getting a connection.
The answer below and in the linked thread about Cipher suites looks the likely culprit, so I'm looking at that now.
Thanks for all the quick replies here btw. Great community!
Also worth saying that enabling TLS1.2 needs to be done for Server Protocols and Client Protocols, if not already done, and you generally need a reboot to actually apply them after settings them.
Keep in mind also you are performing an outgoing https (tcp port 443) call to the Let's Encrypt API. Their HTTP validation is an incoming TCP port 80 connection, and the two are for different parts of the process.