Set up Sophos Firewall Let's Encrypt certificates

With Let’s Encrypt certificates on Sophos Firewall you can create public HTTPS certificates directly on the firewall and have them renewed automatically. This is particularly useful for WAF publishing, WebAdmin, User Portal, VPN Portal, Captive Portal, SPX Portal, hotspot login pages, and SMTP TLS configurations.

The function reduces manual certificate work, but does not replace proper planning. DNS, public accessibility, port 80, certificate names, WAF rules, portal access and monitoring must match. If validation or renewal fails unnoticed, a portal or published web application can suddenly fail with a certificate warning despite the WAF rule actually being correct.

For the actual publication of a web server, Sophos Firewall WAF: Publish web servers securely fits first. This article focuses on the certificate side and operation of Let’s Encrypt on the firewall.

When Let’s Encrypt makes sense on the firewall

The built-in Let’s Encrypt method makes sense if the Sophos Firewall itself provides the public service or stands in front of it as a reverse proxy.

Not every service fits this path. For wildcard certificates or certificates that are to be used on multiple systems outside the firewall, an externally generated certificate is often better. There is the existing article Create Let’s Encrypt wildcard certificate for this purpose.

Limits and important differences

Sophos Firewall creates Let’s Encrypt certificates for specific FQDNs. The integration is not the same as a freely managed ACME client on a Linux server.

Important points:

• The domain must be specified as a full FQDN.
• Wildcard domains are not the right way for the built-in firewall process.
• IP addresses are not valid certificate names.
• HTTP domain validation must be able to reach the firewall via port 80.
• The firewall creates temporary web server or WAF components for validation.
• After successful issuance, the temporary validation components are removed again.
• Certificates are short-lived and must be renewed automatically.

Sophos introduced the feature with SFOS 21. The Avanet classification of the innovations at the time can be found in the blog post Sophos Firewall v21: the most important innovations. Several WAF and Let’s Encrypt fixes are listed in recent release notes. For productive environments, this means: firmware status, certificate status and WAF operation should be checked together, not in isolation.

Requirements

Before creating a certificate, these points should be clarified:

• The firewall runs on a SFOS version with Let’s Encrypt support.
• The public DNS name points to the WAN address or hosted address of the firewall.
• Port 80 can be reached externally for HTTP validation.
• There is no active DNAT, WAF or other rule intercepting the validation request on port 80.
• The firewall can communicate on the Internet itself.
• The date, time and NTP of the firewall are correct.
• For later service it is clear whether the certificate is used in WAF, WebAdmin, Portal or SMTP TLS.
• An owner regularly checks certificate expiration, renewal status and affected services.

⚠️ Let’s Encrypt is not a workaround for unclean public accessibility. If port 80 is blocked by an old DNAT rule, another WAF rule, an upstream NAT, or a provider filter, the certificate request or renewal may fail.

Schedule certificate namesBefore the technical setup, it should be determined which host names are really needed. Good certificate planning prevents later corrections to WAF rules, portals and DNS.

Examples:

If you have multiple applications, you shouldn’t rush to pack everything into one certificate. A certificate with many names can be practical, but it also increases dependencies. When a certificate is renewed, replaced or reverted, all hostnames it contains are affected.

For WAF rules, it is also important that DNS, certificate, domains in the WAF rule and SNI match. The WAF basics are described in Sophos Firewall WAF: Publish web servers securely.

Create Let’s Encrypt account and certificate

The setup is done in the WebAdmin in the Certificates area. Depending on the SFOS version, the exact representation may vary slightly, but the process remains similar.

Basic process:

1. Open Certificates.
2. Open the Let’s Encrypt area or certificate request.
3. Prepare Let’s Encrypt account on the firewall.
4. Enter the desired FQDNs.
5. Select WAN interface or public address for HTTP validation.
6. Check whether port 80 points to the firewall from the outside.
7. Request certificate.
8. After successful issuance, check under Certificates > Certificates whether the certificate is present and valid.

During validation, the firewall uses the HTTP challenge-response mechanism. To do this, external Let’s Encrypt systems must be able to reach the validation path. If the firewall is behind a router, load balancer or provider NAT, the redirect must point to the firewall.

Use certificate

Once issued, the certificate only exists. It only protects a service once it has been actively selected there.

Typical assignment:

After the assignment, you should not only save in WebAdmin, but also test the service externally. For WAF publications, a test from outside your own LAN is suitable because internal DNS view, NAT loopback or browser cache can otherwise provide false security.

Go-live test

A successful go-live test consists of DNS, TLS, service functionality and logging.

Checklist:

• The FQDN publicly resolves to the expected address.
• Port 80 is accessible to the firewall during validation.
• Port 443 or the HTTPS port used delivers the new certificate.
• Browser does not show certificate warning.
• Certificate contains the expected hostname.
• Expiry date matches the newly created certificate.
• WAF rule, portal or WebAdmin really uses this certificate.
• Log Viewer does not show any noticeable WAF, portal or certificate errors.
• For WAF releases, reverseproxy.log matches the time of testing.

A simple external TLS test can also show which certificate is actually delivered. It is important to carry out the test from outside the customer network, not just from the internal client.

Check certificate chain

After switching to a new Let’s Encrypt certificate, not only the common name or SAN entry should be checked. It is also crucial whether the client sees the complete certificate chain. If a browser, app or monitoring system reports an incomplete chain, the cause could be the certificate selection, an old imported certificate, an incorrect WAF rule or an intermediary reverse proxy.

In practice, you should check these points:- External HTTPS test shows expected FQDN without certificate warning.

• The certificate delivered is really the new Let’s Encrypt certificate from the Sophos Firewall.
• The certificate chain is complete and is not replaced by an old backend or proxy certificate.
• WAF rule, portal or WebAdmin use the same certificate that is visible in the external test.
• If an upstream load balancer, router or reverse proxy is involved, no other certificate will be delivered there.

This check is particularly important if the same domain previously ran through a different publication, or if multiple WAF rules, DNAT rules, or external proxies use the same hostname. Otherwise you will see a valid certificate in WebAdmin, while clients from outside will still receive a different or incomplete chain.

Monitor renewal in the company

Let’s Encrypt certificates are short-lived. The strength of the integration is that the firewall can perform the renewal automatically. Nevertheless, you should not let the process run blindly.

These points should be checked regularly in a company audit:

• Is the firewall running on a current, stable SFOS version?
• Is the certificate still valid?
• Was the automatic renewal successful?
• Is port 80 still accessible for validation?
• Are there new DNAT or WAF rules that could block validation?
• Do users or monitoring show certificate warnings?
• Are there WAF or portal errors in the log viewer?

This check is particularly important after firewall upgrades, WAF changes, provider changes, DNS changes and changes to upstream routers or reverse proxies.

Typical errors

If the WAF and certificate are conspicuous together, you should not just look at the certificate. WAF matching, hosted address, domains, SNI and backend accessibility belong to the same error chain.

Plan rollback

For public portals and WAF applications, it should be clear how to go back before changing a certificate.

Useful preparation:

• do not delete the previous certificate immediately
• Document the affected WAF rule and portal configuration
• Have external test access available
• Know DNS TTL if hostnames are changed
• Select maintenance windows for critical portals
• Prepare user communications if a portal is affected

If the new certificate has been created, but a service then works incorrectly, you can usually select the previous certificate again. However, if the cause is a blocked HTTP validation, a certificate rollback will only help in the short term. Then the validation path must be corrected, otherwise the next renewal will fail again.

Checklist- FQDNs and services documented.

• Public DNS resolution checked.
• Port 80 checked for HTTP validation.
• Conflicts with DNAT, WAF or upstream NAT checked.
• Let’s Encrypt certificate created.
• Certificate assigned to the correct service.
• External HTTPS test performed.
• Log Viewer and WAF reverseproxy.log checked.
• Renewal responsibility and monitoring defined.
• Old certificate only removed after successful operation.

FAQ