Import and assign certificates on Sophos Firewall

A certificate is only ready for use on Sophos Firewall when four elements match: hostname, server certificate, private key and issuing CA chain. The certificate must then be assigned to the correct service. Simply adding an entry under Certificates > Certificates does not change any portal or WAF rule.

For a certificate issued by an internal or public CA, the safest standard approach is:

1. Generate a Certificate Signing Request (CSR) under Certificates > Certificates > Add.
2. Have the CSR signed by the required CA.
3. Import the issued certificate using the import action for the existing CSR.
4. Check the installed associated CA under Trusted and the expiry date under Valid until.
5. Assign the certificate to the required service and test it from a client.

This approach generates the private key on the firewall, so it never has to leave the device. An existing certificate generated externally can also be uploaded, but it requires the associated private key and, where necessary, the missing intermediate and root CAs.

If a PFX or PEM file is already available, the quick route is Certificates > Certificates > Add > Upload certificate: select the format, upload the certificate with the required private key and password, then check the associated CA, validity period and service assignment.

Which certificate method is suitable?

• Public or internal CA, new certificate: Generate the CSR on the firewall. This reduces key transfers and helps prevent mismatched certificate and key pairs.
• Existing certificate with private key: Upload the certificate as PEM, DER, CER or PKCS12. The format, password and CA chain must be correct.
• Let’s Encrypt for a public firewall service: The built-in process can handle issuance and renewal. The complete procedure is described in Set up Let’s Encrypt certificates on Sophos Firewall.
• External wildcard certificate: Create it outside the firewall and then import it. Create a Let’s Encrypt wildcard certificate explains the planning and DNS-01 validation.
• Only for internal, managed clients: A locally signed certificate may be sufficient if every client trusts the issuing internal CA.

A self-signed or locally signed certificate does not automatically provide insecure encryption. Without a distributed trust chain, however, the client cannot reliably verify its identity and displays a warning. A public CA is therefore normally the better choice for publicly accessible portals and WAF applications.

Distinguishing certificates, CAs, private keys and CSRs

These four components have different purposes:

• Server certificate: contains the identity, public-key information, valid names and validity period. It is presented to the client.
• Private key: proves that the firewall is authorised to use the certificate. It must never be included in tickets, screenshots or public storage.
• CA certificates: form the trust chain from the issuing intermediate CA to the root CA. A private CA key is not required for this purpose.
• CSR: contains the certificate request and public key. When the CSR is generated on the firewall, the associated private key remains on the device.

A CA for TLS Inspection serves a different purpose from a server certificate for WebAdmin or WAF. The Inspection CA signs new certificates for clients during decryption. Distribute the Sophos Firewall CA certificate for TLS Inspection explains how to select and distribute it.

Preparing names, validity and the chain

Before importing a certificate, establish which name users and systems will actually open. Modern clients primarily check the Subject Alternative Names (SAN). The Common Name alone is not a reliable substitute.

Example:

• URL opened: https://vpn.example.com
• certificate name in SFOS: public-vpn-example-com-2026
• SAN in the certificate: vpn.example.com
• DNS: vpn.example.com points to the intended firewall or WAF access point

vpn.example.com is an example and must be replaced with the organisation’s own FQDN. If an admin instead connects using the IP address or another alias, the certificate only matches if that name or IP address is also included as a SAN.

Check before making the change:

• The firewall date, time and NTP configuration are correct.
• Every required FQDN is included as a SAN in the request or certificate.
• The private key and certificate belong together.
• The intermediate and root CAs are known.
• The expiry date and renewal responsibility are documented.
• The existing certificate and its assignments are retained as a rollback option.

Recommended method: generate the CSR on the firewall

Create the CSR

1. Open Certificates > Certificates.
2. Select Add.
3. Under Action, select Generate certificate signing request (CSR).
4. Enter a meaningful internal name, such as public-vpn-example-com-2026.
5. Select the required Key Type, key length or curve, and hash according to the organisation’s security requirements and the CA’s specifications.
6. Under Common name, enter the primary FQDN, such as vpn.example.com.
7. Under Subject Alternative Names, add at least the DNS name that will actually be used.
8. Save the request and download the CSR using the download icon.

The internal certificate name is only an SFOS label. It does not have to match the FQDN, but should make the purpose and renewal year clear. By contrast, the SAN entries are part of the technical identity check and must match the URL used later.

Have the CSR signed

Submit the downloaded CSR to the responsible public or internal CA. Do not have new key files generated if the private key created on the firewall is to be used. The CA then supplies the signed server certificate and, depending on the provider, additional intermediate certificates.

Check before importing:

• The CA signed the correct CSR.
• The SAN list contains all approved names.
• The validity period and issuer match the order or internal policy.
• The complete CA chain is available.

Import the signed certificate into the CSR

1. Open Certificates > Certificates.
2. In the row for the correct CSR, select the import action under Manage.
3. Upload the issued certificate or paste the certificate text.
4. For the purpose, normally select Certificate only. If the same file also contains the CA chain, select the matching certificate and CA purpose.
5. Select Import certificate.

SFOS associates the certificate with the private key stored on the firewall and then removes the CSR entry. Before importing, therefore check carefully that the correct CSR row has been selected.

Uploading an existing certificate with its private key

If the certificate and key were generated outside the firewall:

1. Open Certificates > Certificates > Add.
2. Select Upload certificate.
3. Enter a unique name.
4. Select the existing file format.
5. Upload the certificate and the key data required for that format.
6. If the private key is encrypted, enter its password.
7. Save the certificate.

SFOS supports these certificate formats:

• PEM (.pem): Base64-encoded; the certificate and private key are normally stored in separate files.
• DER (.der) and CER (.cer): binary certificate formats; the private key is stored separately.
• PKCS7 (.p7b): can contain certificates and a chain, but not a private key.
• PKCS12 (.pfx or .p12): can contain the server certificate, CA chain and private key in one file.

RSA and ECC keys are supported. SFOS accepts no more than 30 characters for the password of an imported private key. This product limit is not a reason to use an unprotected private key: set a strong password within the limit for the transfer and then remove the import file from insecure temporary storage.

Add a missing CA chain

Under Certificates > Certificates, a green entry in Trusted indicates that the associated CA is installed on SFOS. If it is missing, check the issuer and chain first:

1. Open Certificates > Certificate authorities.
2. Select Add.
3. Upload the missing intermediate or root CA, or paste the certificate text.
4. For a trust chain only, select Validation only.
5. Save and check the server certificate’s Trusted status again.

A public root or intermediate CA does not need a private key for validation. Signing and validation is only intended for a CA that the firewall itself will use to sign certificates and whose private key is deliberately stored on the firewall.

Upgrade to SFOS 21 or later: check reserved CA names

During the first upgrade of an older installation to SFOS 21 or later, NC-146082 can block the migration. The cause isn’t the certificate’s validity, but an existing CA entry whose name is required by SFOS for built-in Let’s Encrypt CAs:

Lets_Encrypt_R10
Lets_Encrypt_R11
Lets_Encrypt_R12
Lets_Encrypt_R13
Lets_Encrypt_R14
Lets_Encrypt_E5
Lets_Encrypt_E6
Lets_Encrypt_E7
Lets_Encrypt_E8
Lets_Encrypt_E9

Before the maintenance window:

1. Create a fresh configuration backup and have the backup password and Secure Storage Master Key available.
2. Go to Certificates > Certificate authorities and search for the exact names. If there is no match, NC-146082 doesn’t require a change.
3. If there is a match, document the type, subject, issuer, purpose, and whether a key icon is present. The key icon shows that the firewall holds the CA’s private key.
4. Additionally export a CA with a private key under Backup and firmware > Import export > Export selective configuration as CertificateAuthority. Then identify the certificates and services that depend on the CA, such as VPN, WebAdmin and portals, WAF, SMTP TLS, or TLS inspection.
5. Only remove a user-configured entry after all dependencies have been replaced or shown to be no longer required. Then retry the upgrade.

Don’t remove a built-in CA. If WebAdmin refuses to delete the entry, the original private key is missing, or a reference remains unclear, stop the upgrade and involve Sophos Support. Database or Advanced Shell changes aren’t a safe substitute.

After the upgrade, confirm that the built-in Let’s Encrypt CAs are present, dependent certificates show Trusted again, and the affected services work.

Assigning the certificate to the correct service

Before assignment: preserve a rollback path

A certificate change should not start by deleting the old entry:

1. Import the new certificate and complete CA chain.
2. Check the SAN, issuer, validity and Trusted status.
3. Document the existing assignment and affected services.
4. Assign the new certificate to one service first.
5. Test that service using its real FQDN and port.
6. If errors occur, immediately select the old certificate again.
7. Migrate the remaining services one at a time and check each one.
8. Remove the old certificate only when it is no longer referenced and the new configuration is stable.

WAF and SMTP can be migrated one at a time. WebAdmin, User Portal, VPN Portal, Captive Portal and the two SPX portals, however, all change simultaneously through a shared certificate selection.

When changing WebAdmin, also keep an existing admin session and an alternative local management route open until the login and certificate have been checked using the intended FQDN.

WebAdmin and portals

Under Administration > Admin and user settings > Admin console and end-user interaction, one shared certificate is selected for these services:

• WebAdmin Console
• User Portal
• VPN Portal
• Captive Portal
• SPX Registration Portal
• SPX Reply Portal

Select the new certificate in the Certificate field and save it with Apply. The certificate must cover every FQDN through which the services in use are accessed. For example, if admin.example.com is used for WebAdmin and vpn.example.com for the VPN Portal, both names must be included as SANs or the URL plan must be standardised.

The VPN Portal certificate protects the HTTPS website from which users obtain profiles and clients. It is not automatically the local or remote certificate of an IPsec tunnel.

WAF

For a WAF publication, edit the relevant rule under Rules and policies > Firewall, enable HTTPS, select the new certificate under HTTPS certificate, and save the rule. The rule uses Protect with web server protection. SNI, the domain in the rule and the SAN in the certificate must describe the same hostname.

Changing a WAF rule restarts the Web Server Protection rules and disconnects existing connections. For production applications, the certificate change therefore belongs in a maintenance window. Sophos Firewall WAF: publish web servers securely describes the complete publication and verification process.

SMTP TLS in MTA mode

For Mail Protection, select the new server certificate in the TLS certificate field under Email > General settings > SMTP TLS configuration and save with Apply. A certificate from a public CA is recommended for public SMTP communication so that remote systems can verify its identity without their own CA distribution. The remaining mail flow is described in Sophos Firewall Mail Protection in MTA mode.

After the change, create a fresh Sophos Firewall backup and document the expiry date, owner and next renewal.

Checking the certificate and its delivery

Check the file before importing

On an admin computer, OpenSSL can inspect a PEM certificate without making changes:

openssl x509 -in firewall.pem -noout -subject -issuer -dates -ext subjectAltName -fingerprint -sha256

Replace firewall.pem with the local file path. The output should show the expected subject, issuer, validity period, required SANs and a SHA-256 fingerprint. The command does not read a private key.

Check an HTTPS service externally

Test WebAdmin, portals and WAF from an admin computer with OpenSSL:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_hostname vpn.example.com -verify_return_error </dev/null

Replace the FQDN and port with those of the actual HTTPS service. -servername sends the name using SNI, ensuring that the correct certificate is selected when multiple WAF or portal destinations exist. The check is successful when the expected certificate is shown, the hostname matches and the output ends with Verification: OK.

For an internal CA, the admin computer must already trust that CA or be given it explicitly as a trust anchor for the test. Otherwise, a verification error may be caused by the test device even though the firewall is delivering the correct chain.

Check SMTP with STARTTLS

SMTP on port 25 or 587 normally starts without encryption and only switches to TLS with STARTTLS. This requires a separate test:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error </dev/null

Replace mail.example.com and port 25 with the SMTP FQDN and the STARTTLS port actually in use. For implicit TLS on port 465, do not use -starttls smtp. Here too, the expected certificate, hostname and Verification: OK must all match.

Also check in the browser or client:

• The URL uses one of the included SANs.
• The issuer and expiry date match the new certificate.
• No certificate warning appears.
• The expected WebAdmin, portal, WAF or mail service works.
• An external test is not still seeing the certificate from an upstream load balancer or reverse proxy.

Common errors and the next check

• Trusted remains empty: the intermediate CA is missing, the wrong CA was imported or the chain does not belong to the server certificate. Check the issuer and CA order.
• The import is rejected: check the file format, private-key password, 30-character limit, certificate and key pair, and system time.
• The browser reports the wrong name: the FQDN or IP address used is missing from the SANs. Compare the URL, DNS and certificate names.
• The browser still shows the old certificate: the service is still using the old assignment or an upstream proxy is terminating TLS. Use openssl s_client and SNI to check the expected destination directly.
• WAF delivers the wrong certificate: check the Hosted Address, Listen Port, Domain, SNI and order of overlapping WAF rules.
• Only some clients display a warning: check the client’s trust store, intermediate certificates, system time and any certificate-pinning restrictions.
• A portal is unavailable after the change: select the old certificate again, then check the FQDN, port, Device Access and certificate chain separately.

FAQ