Troubleshooting Let’s Encrypt certificates on a Sophos firewall

Troubleshooting Let’s Encrypt certificates on a Sophos firewall

I hit this while issuing a Let’s Encrypt certificate through a Sophos firewall. The ACME account registered, the FQDN resolved in DNS, but validation still failed. The useful bit is boring: the HTTP-01 challenge has to work end to end, and anything that rewrites or blocks the token path will break it.

What you see

Look for the ACME error JSON from the CA. A typical line looks like this:

type:'urn:ietf:params:acme:error:connection',detail:'11.22.33.44: Fetching http://myfirewall.mycompany.com/.well-known/acme-challenge/KPM-d71w3TLR32oA5IkrLDkGKAtTIQiUfF7FCeQPKRE [http://myfirewall.mycompany.com/.well-known/acme-challenge/KPM-d71w3TLR32oA5IkrLDkGKAtTIQiUfF7FCeQPKRE]: Error getting validation data',status:400

Record the exact token path the CA tried to fetch. That is the URL to test.

Common signs of failure:

• The ACME registration step finishes, then validation fails with a connection or 400 error.
• Certificate creation stops and the firewall reports an ACME connection error.
• The CA log shows “Error getting validation data” or “connection refused” for the HTTP-01 URL.

What has to happen is simple:

• The CA must GET http://<your-FQDN>/.well-known/acme-challenge/<token> and receive the token body with HTTP 200.
• The FQDN must resolve to the public IP the CA hits.
• Port 80 on the public IP must reach the Sophos firewall and be routed to the ACME responder.

Where it fails

On a Sophos firewall, ACME HTTP-01 validation uses port 80 and expects the firewall to serve the challenge path. NAT, inbound firewall rules, and any web proxy or WAF have to pass the HTTP GET for /.well-known/acme-challenge unchanged to the firewall’s ACME handler.

The FQDN needs an A record pointing at the public IP. The CA resolves the name and connects to that IP on port 80. If the A record points elsewhere, validation goes to the wrong host and fails.

The CA requests an exact token URL under /.well-known/acme-challenge. The response must be the token text placed by the ACME client. Nothing should intercept or rewrite that path. A local web server, a reverse proxy, a WAF rule or a NAT to another host will break validation.

Find the cause

Open the Sophos admin log for the ACME request. Look for the token string and the CA IP attempting the connection. Compare timestamps to the ACME failure time. If the firewall shows no incoming packet from the CA IP at that time, the request never reached the firewall.

Keep the exact failure line from the firewall or CA. That error string tells you which test to run next.

Check DNS with:

dig +short myfirewall.mycompany.com

Expected: the public IP you want to accept HTTP on. If it returns something else, DNS is wrong.

Check public resolution too:

dig +short myfirewall.mycompany.com @8.8.8.8

That confirms public resolvers see the same answer.

Test the exact URL the CA tried:

curl -v http://myfirewall.mycompany.com/.well-known/acme-challenge/KPM-d71w3TLR32oA5IkrLDkGKAtTIQiUfF7FCeQPKRE

Expected: HTTP/1.1 200 OK and the token body. Anything else is a problem: connection refused, timeout, 404, 301 to a different path, or an HTML error page.

Check port reachability:

nc -vz 11.22.33.44 80

Expected: succeeded — connection to 11.22.33.44 port 80. If it times out or is refused, port 80 is blocked before the firewall.

If curl returns an HTML page from an internal web server, the ACME request is being intercepted and will not succeed.

Fix it

Make sure inbound traffic on port 80 reaches the firewall ACME handler:

• If you use DNAT, map external port 80 to the firewall’s management or ACME service IP.
• Create a firewall rule allowing Source Any, Service HTTP, Destination the NATed public IP, Action Accept.
• Remove any rule that redirects all HTTP for this FQDN to an internal web server.

On Sophos, check Web Application Firewall or HTTP Web Proxy rules. Turn off any rule that rewrites or blocks /.well-known/acme-challenge. Make the rule specific to that path where possible, or let the path through unchanged.

If a reverse proxy sits in front of the firewall, configure it to forward the exact challenge path without modification.

If the A record points to the wrong IP, update it to the firewall public IP. Wait for the TTL to expire or lower it before retrying.

If you use split DNS, check that internal and external resolution match. The CA uses public DNS. The firewall has to serve the challenge for the public answer.

In the Sophos ACME settings, check that the FQDN matches the certificate name and that the ACME account is registered and active. If the firewall has a test or check FQDN feature that fetches the challenge URL from the internet, use it. If the firewall test passes but the CA fails, check with an external curl from the public internet.

If the firewall created a self-signed placeholder web page for the FQDN, remove it so the ACME token can be served.

Practical checklist:

• Public A record points to the public IP.
• Port 80 TCP on the public IP reaches the Sophos firewall.
• NAT rule maps external port 80 to the firewall service.
• Firewall rule allows HTTP to the NAT destination.
• No WAF, proxy or internal web server rewrites /.well-known paths.
• The ACME token path is accessible and returns the token string.

Check it’s fixed

After the changes, try to create the Let’s Encrypt certificate again. Note the CA token path and run the same curl test while validation is happening. The test should return the token body and HTTP 200.

Start issuance in the firewall UI and watch the logs. If the CA now shows HTTP 200 for the token URL, the certificate should be issued.

If the CA returns a new error, collect the exact message and token path and repeat the same targeted curl test. Common follow-ups are 301 redirects, 404s or 403s. A 301 usually means an automatic HTTP-to-HTTPS redirect on port 80, which breaks HTTP-01 unless the token stays reachable at the final URL. A 403 usually points to a WAF or ACL blocking the path.

When the certificate is created, check the firewall shows the new certificate and the expiry date. Test a browser connection to https://myfirewall.mycompany.com and check the chain is trusted. Also check the services that use the certificate, such as admin console access or remote VPN, to confirm they present the new certificate.

If the CA succeeded and the curl test returned the token during validation, the problem was path or network reachability. If the curl test still fails while the CA succeeds, there may be timing issues or caching in the way; check proxy caches or CDN settings.

The bit that matters is still the same: the CA must GET the exact /.well-known/acme-challenge path on port 80 at the public IP the FQDN resolves to. If that path is blocked, rewritten or sent somewhere else, issuance fails.