Issue creating certificate

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. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: Create certificate (default settings)

It produced this output :

Cached order has status invalid, discarding
** [] Authorizing...**
** [] Authorizing using http-01 validation (SelfHosting)**
** [] Authorization result: invalid**
** [] {**
** "type": "urn:ietf:params:acme:error:connection",**
** "detail": " Fetching Connection reset by peer",**
** "status": 400**
** [] Deactivating pending authorization**

My web server is (include version): IIS 10

The operating system my web server runs on is (include version): Windows server 2022 Standard (20348.1487)

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): win-acme.v2.1.23.1315.x64.pluggable

I have installed a new server and is trying to create and install a new certificate, but it keeps failing. I have used the same procedures on other servers (not Widows server 2022) without any issues.

I'd begin (the troubleshooting) at the beginning.

Is this the IP of that server?:


yes that is the IP

Can you create the expected challenge path and place a test text file there?
[so that we can see if it can be reached from the Internet]
[please ensure not to use any file extension in the test file - (NOT .htm*)]


I have created the file in the folder, but is getting a 404 if I don't add an extension. If adding .txt as extension it is accessible.


You are showing a size of 0KB for the file Test_File-1234, might the file need a small amount of text content to be served? I have no clue what Microsoft-IIS/10.0 will do if the file size is 0.

Supplemental information

$ curl -Ii
HTTP/1.1 404 Not Found
Content-Length: 1245
Content-Type: text/html
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Date: Mon, 13 Feb 2023 15:29:16 GMT

$ nmap
Starting Nmap 7.80 ( ) at 2023-02-13 15:30 UTC
Nmap scan report for (
Host is up (0.18s latency).
Not shown: 999 filtered ports
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 13.49 seconds

You are almost certainly affected by a Palo Alto Networks brand firewall. When trying to access your domain with a User-Agent string like the Let's Encrypt servers it fails. But, other requests succeed. This is a well-known problem.

Have your network admins change the Application Rule for "ACME protocol".

Show them these two curl requests (especially the -A setting). Both should return a 404 once they fix the setting

curl -I
HTTP/1.1 404 Not Found
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET

curl -I -A "Mozilla/5.0 (compatible; Let's Encrypt validation server; +"
curl: (56) Recv failure: Connection reset by peer

That is an indication that IIS is NOT configured to serve extensionless files.


Using win-acme in self-hosting mode means IIS will effectively be skipped and will not really be involved in the challenge request (win-acme will temporarily use it's own http listener in front of IIS), which in turn means you don't have to configure mime-type, extensionless files etc unless you can't get the self-hosting method to work. I'd be surprised if win-acme can't also auto-configure that as fallback (like we do for Certify The Web) because it wasn't originally self-hosting.

It's possible you are either affected by the Palo Alto thing @MikeMcQ mentioned or you have some other blocking software (malware protection, firewall etc), or win-acme simply got stuck somehow and a reboot might fix it. Connection reset is very different to a 404 etc and it seems like you are seeing both depending on the timing. I vote reboot.


I see a test with Let's Debug results in connection reset as well, make sure you're not using geographic filtering at the firewall as Let's Encrypts http validation could come from more or less any country.


Yes, this is classic symptom of the Palo Alto Networks firewall blocking the "ACME Protocol". I have dealt with numerous cases of this.

There is also a general topic on this by Seth Schoen (link here)

Just fyi, the initial test from Let's Debug has a similar user-agent as the actual LE servers which is why it also gets caught up in it.


The ACME Protocol is used for obtaining SSL/TLS certificates from a certificate authority (Let's Encrypt in this case), and LE uses the HTTP or HTTPS protocol. If your Palo Alto Networks firewall is blocking the ACME Protocol, it may be due to a misconfiguration or a security policy that restricts outbound inbound traffic. You may need to configure your firewall to allow traffic on the ports used by the ACME Protocol (port 80 for HTTP and port 443 for HTTPS), or create an exception in your security policy to allow the necessary traffic.


2 posts were split to a new topic: Couldn't create https

Palo Alto added a feature to their firewalls to block ACME Protocol. It is an Application Rule and blocks inbound HTTP Challenges. See my post #7

These are the terms that they use in their firewall to describe this feature


@pnrdk given that you are using Windows, and making an assumption that you do not have easy access to curl there is a Windows application (there is a free use level) Postman (software) - Wikipedia


Just fyi, modern Windows have curl and so do Windows Servers starting 2019 I believe.


Oh, that is great to know; I see it.


Microsoft Windows [Version 10.0.19045.2546]

C:\Users\Bruce>curl --help
Usage: curl [options...] <url>
 -d, --data <data>          HTTP POST data
 -f, --fail                 Fail fast with no output on HTTP errors
 -h, --help <category>      Get help for commands
 -i, --include              Include protocol response headers in the output
 -o, --output <file>        Write to file instead of stdout
 -O, --remote-name          Write output to a file named as the remote file
 -s, --silent               Silent mode
 -T, --upload-file <file>   Transfer local FILE to destination
 -u, --user <user:password> Server user and password
 -A, --user-agent <name>    Send User-Agent <name> to server
 -v, --verbose              Make the operation more talkative
 -V, --version              Show version number and quit

This is not the full help, this menu is stripped into categories.
Use "--help category" to get an overview of all categories.
For all options use the manual or "--help all".


Thanks very much to all contributing on this thread :pray: :pray:
It was the firewall causing issues, so now it is working fine :slight_smile:


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.