Troubleshooting Lets Encrypt Certificate Issues on Sophos Firewalls

I ran into this while issuing a Lets Encrypt certificate through a Sophos firewall. The ACME account registered fine, the FQDN resolved in DNS, but validation failed. This guide breaks down what you see, where the ACME HTTP-01 validation must succeed, how to find the cause, how to fix it and how to verify the result. I keep commands and exact log lines so you can test fast.

What you see

Common error messages

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. You will use it for direct testing.

Symptoms of failure

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

Expected outcomes

• The CA must GET http:///.well-known/acme-challenge/ and receive the token body, HTTP 200.
• DNS A record for 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 happens

Firewall configuration overview

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

Public IP and DNS settings

The FQDN must have an A record pointing at your public IP. The CA will resolve the FQDN and connect to that IP on port 80. If the A record points elsewhere, validation will hit a different device and fail.

ACME challenge path requirements

The CA will request an exact token URL under /.well-known/acme-challenge. The response must be the token text placed by the ACME client. Nothing may 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

Checking firewall logs

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 for the CA IP at that time, the request never reached the firewall.

Collect the ACME failure line from the firewall or CA and paste it into your notes. That exact error string is evidence for the next tests.

Validating DNS records

Run:

• dig +short myfirewall.mycompany.com
  Expected: the public IP you plan to accept HTTP on.
  Actual: any other IP shows DNS mismatch.

Also run:

• dig +short myfirewall.mycompany.com @8.8.8.8
  This confirms public resolvers see the same answer.

If the IP is wrong, the CA will hit the wrong host. Fix DNS before proceeding.

Testing HTTP access

Use curl and a raw TCP test against 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.
  Actual: connection refused, timeout, 404, 301 to a different path, or an HTML error page.

Also test port reachability:

• nc -vz 11.22.33.44 80
  Expected: succeeded — connection to 11.22.33.44 port 80.
  Actual: connection refused or timed out indicates 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 cannot succeed.

Fix

Adjusting firewall rules

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 the 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 to an internal web server for this FQDN.

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 allow the path through unmodified.

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

Modifying DNS settings

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

If you use split DNS, confirm internal and external resolution match. The CA uses public DNS. The firewall must serve the challenge for the public answer.

Verifying ACME configuration

In the Sophos ACME settings, confirm the FQDN matches the certificate name. Confirm the ACME account is registered and active. When possible, use the firewall’s “test” or “check” FQDN feature that tries to fetch the challenge URL from the internet. If the firewall shows the test passed but the CA fails, cross-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 -> public IP.
• Port 80 TCP on public IP -> hits 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 rewriting /.well-known paths.
• ACME token path accessible and returns the token string.

Check it’s fixed

Reattempting certificate issuance

After fixes, attempt to create the Lets Encrypt certificate again. Note the CA token path and run the same curl test while the CA is validating. The test should show the token body and HTTP 200.

Use the firewall UI to start issuance and watch logs. If the CA logs now show HTTP/200 for the token URL, the certificate will be issued.

Monitoring for new errors

If the CA returns a new error, collect the exact message and token path and repeat the targeted curl test. Common follow-ups are 301 redirects, 404s or 403s. A 301 suggests an automatic HTTP-to-HTTPS redirect on port 80; that will break HTTP-01 unless the redirect is temporary and the token remains accessible at the final URL. A 403 suggests a WAF or ACL blocking the path.

Confirming successful validation

When the certificate is created, confirm 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 any services that require the certificate, for example 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 root cause was path or network reachability. If the curl test still fails while the CA succeeds, timed races or caching may be in play; inspect proxy caches or CDN configuration.

Final takeaway: 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 routed to another server, issuance fails. Use the exact token URL, dig and curl to prove where the failure lies, then fix NAT, firewall rules or DNS so the Sophos firewall can serve the token.