FileMaker Server 22 now has Let's Encrypt baked in, but I'm having problems with it that Claris hasn't been able to solve. Across my domain with a particular hosting provider, I cannot get a single SSL issued. The test validation passes, but the actual SSL fails to issue, giving " Certificate Request Failed. Failure / timeout verifying challenge passed"
Port 80/443 are both open in Windows Firewall, and I can run curl -i http://EXAMPLE.DOMAIN/.well-known/acme-challenge/test.txt from any machine outside my network and it returns 200/the contents of the text file, so I know the port is open. But when I go to letsdebug.net and run a test I get "Connection reset by peer".
The hosting provider swears there's nothing upstream blocking port 80, but I'm no longer confident that there's nothing blocking either the port or let's encrypt's servers themselves. Does anyone have further ideas/tests I can run down before going back to the hosting provider?
My domain is:
*.portagebay.com
I ran this command:
FileMaker's "Request" function
It produced this output:
"Certificate Request Failed. Failure / timeout verifying challenge passed"
My web server is (include version):
FileMaker Server 22.0.2.204
The operating system my web server runs on is (include version):
Windows Server 2019
My hosting provider, if applicable, is:
private cloud
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):
no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
FileMaker Server 22.0.2.204
No, sorry I should've been clearer. I'm trying to issue multiple for different subdomains and used that notation to represent such. I've tried to issue them to:
All failed, but when I tried on a couple AWS instances using identical SW versions and port settings, I was able to get it to pass on: hawk.portagebay.com
Well, we haven't seen one of these in quite a while.
There is a (very good) chance that your server hosting company is using a Palo Alto brand firewall.
That brand has an "Application" setting on the firewall for "ACME Protocol". They need to allow that. Some time back Palo Alto disabled ACME by default and we saw these problems often.
Even if not that brand they must have something similar in their firewall.
From my own AWS-based test server see the results below. You can probably easily reproduce this from other client systems. Using a "user-agent" string similar to Let's Encrypt fails with "reset by peer". The default curl string works as expected.
curl -i http://cedar.portagebay.com/.well-known/acme-challenge/Test404
HTTP/1.1 404 Not Found
Content-Type: text/html
Server: Microsoft-IIS/10.0
curl -i http://cedar.portagebay.com/.well-known/acme-challenge/Test404 -A "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
curl: (56) Recv failure: Connection reset by peer
Make sure they're checking the inbound rules, from the Internet to the servers. It's kind of confusing, since the actual ACME protocol is spoken outbound from the server to the CA, but thing that Palo Alto labels as "ACME Protocol" is actually for incoming validation requests.