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.
• Automate DigiCert or another public CA: Renew a Sophos Firewall certificate via XML API and verify services combines issuance, XML API upload, service assignment, and an external listener test in one controlled end-to-end workflow.
• 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.

Information and actions in the certificate list

Under Certificates > Certificates, SFOS displays the Subject, Issuer and Purpose when you hover over a certificate name. The available actions let you copy the certificate or download it as a .crt file; the downloaded file does not contain a private key. Regenerate is available only for the built-in ApplianceCertificate. Locally signed certificates can be revoked directly; SFOS automatically adds them to the Default CRL. The controlled revocation procedure is described in Certificate Revocation Lists on Sophos Firewall.

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.

Encrypted POP3 and IMAP retrieval also has a separate TLS assignment under Email > General settings. Scan and test POP3 and IMAP on Sophos Firewall explains how the mail-server CA, certificate validation, scan option, and firewall rule work together.

If the firewall is to be integrated into the organization’s PKI for this purpose, Set up a subordinate CA for Sophos Firewall TLS inspection explains the CSR, AD CS, EKU, and import process for a dedicated re-signing CA.

The built-in Default CA is the trust anchor for locally signed certificates. Saving its settings regenerates the CA and can affect portals, SSL VPN, IPsec peers, and trusting clients. Renew the Sophos Firewall Default CA safely provides the controlled change procedure.

Validity and the trust chain are not sufficient when a certificate has been revoked early. The dedicated CRL workflow explains how to import, update, and verify local and external Certificate Revocation Lists on Sophos Firewall.

In FIPS 140-3 mode, SFOS additionally validates newly generated and imported certificates against the permitted key and digest algorithms. Enabling this mode is a separate factory-reset migration, not a normal certificate change.

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.

Generating a locally-signed certificate

For an internal service, SFOS can sign a certificate directly with the built-in Default CA. This is a sound approach only when the connecting devices already trust this CA or receive its public certificate through a controlled process. A certificate from a public CA is normally the better choice for publicly accessible services.

Under Certificates > Certificates > Add, select Generate locally-signed certificate. Then specify a unique name and the required validity period; SFOS proposes one year by default. Key type (RSA or Elliptic curve), key length or curve, and Secure hash must match the organization’s cryptographic requirements and the clients.

The Common name is mandatory in the Subject. SFOS initially fills Country name, State, Locality name, Organization name, Organization unit name and the contact email address from the license data; check every value against the actual organization and intended purpose before saving. Under Subject Alternative Names, enter all DNS names and any required IPv4 or IPv6 addresses.

At least one SAN or a Certificate ID is required. The Certificate ID under Advanced settings is intended only for compatibility with earlier SFOS versions and does not replace a correct SAN list for modern HTTPS clients. After Save, check the Default issuer, validity, SANs, and subsequent service assignment.

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 Secure 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.

Also check the other Subject fields and the contact email address. SFOS may prefill them from the license data, but they belong to the specific certificate request and must not be accepted without review.

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. Select the purpose that matches the issued object:
   • Certificate only: The issued server or client certificate is stored under Certificates > Certificates.
   • Certificate authority only: This option applies to a CA issued from the CSR, such as a subordinate CA. It then appears under Certificates > Certificate authorities.
   • Certificate and certificate authority: The upload contains both the issued certificate and its root or subordinate CA.
5. Select Import certificate.

For a CA import, SFOS initially uses the Common Name as the CA name; it can be changed before the import. SFOS links the certificate or CA certificate issued from the CSR to the associated private key stored on the firewall. It 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.

When a CA is uploaded directly, SFOS detects the X.509 file format automatically; .pem, .der and .cer are supported. If the CA matches a CSR generated on the firewall, SFOS adopts the CSR name and sets the purpose to Signing and validation, because the associated private key is already on the firewall. Then check the private-key icon. Use as a re-signing CA belongs to the separate procedure for the subordinate TLS Inspection CA.

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.

Import an external signing CA without a matching firewall CSR

This procedure is for an externally generated intermediate CA that the firewall will use to sign certificates, not for the server certificate or a validation-only trust chain. You need the CA certificate and that CA’s own private key as a verified pair. Do not transfer the root CA’s key to the firewall. A firewall-generated CSR remains preferable because it avoids key transport.

If the signing CA contains Extended Key Usage (EKU), it must include TLS Web Server Authentication. Do not change a CA already used for re-signing to Validation only: it would lose the signing capability needed to re-encrypt decrypted SSL/TLS traffic. Before changing anything, preserve a backup, the previous CA selection and its dependencies.

1. Open Certificates > Certificate authorities and select Add, not the server certificate list.
2. Upload the intermediate CA certificate or paste its certificate text. SFOS automatically detects .pem, .der and .cer.
3. SFOS checks for a matching firewall CSR. If one matches, its name and Signing and validation are adopted; the private key is already on the firewall. Change the proposed name if necessary and select Save. No additional key upload is needed.
4. If no CSR matches, additional options appear. Under Use certificate for, select Signing and validation for this signing CA.
5. Upload the Private key belonging to this intermediate CA, not the server certificate’s private key. Enter the private-key password for encryption; it must contain no more than 30 characters. Use a protected key and a strong password within this limit for the transfer.
6. Enter a unique CA name or change the proposed name, then select Save.
7. Separately upload or paste the associated root CA through Certificates > Certificate authorities > Add, set Use certificate for to Validation only, and select Save. It validates the intermediate CA and does not require a private key for that purpose.
8. Under Certificates > Certificates, check the green tick in Trusted for the imported server certificate. Then under Certificates > Certificate authorities, open the filter next to Type, select Uploaded, and click Apply. The private-key icon must appear beside the intermediate/subordinate CA; it confirms the signing key is present, not that a traffic test has succeeded.

If Trusted is missing, check the issuer and complete chain; if the key icon is missing, check the CA/key pair, import and password before assigning the CA. Importing alone does not change the TLS inspection CA selection. Enterprise CSR/AD CS, traffic selection and pilot testing remain in the linked subordinate TLS Inspection CA procedure. When switching later, retain the previous CA selection for rollback; remove new CA entries only after confirming they have no dependencies. Switching back cannot undo a key transfer: remove import files from insecure temporary storage and retain protected recovery copies according to the PKI policy.

Upgrade to SFOS 21: check reserved CA names

When upgrading to SFOS 21, NC-146082 can block the migration. The cause isn’t the certificate’s validity, but an existing CA entry whose name SFOS 21 requires 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. The safe workflow for the package, SSMK, and reimport is described in selectively export and import configuration. 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 assignment target first. The WebAdmin/portal group is changed together, while WAF rules and SMTP can be changed individually.
5. Test all services affected by this assignment target using their real FQDNs and ports.
6. If errors occur, immediately select the old certificate again.
7. Migrate the remaining assignment targets 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.

See Set up and test SPX email encryption for the complete portal FQDN, password registration, Reply Portal, and mail flow procedure.

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.

For internal administration only, SFOS can also secure the WebAdmin name with a locally signed certificate. Under Certificates > Certificates > Add, select Generate locally-signed certificate and enter the exact internally resolvable firewall hostname under both Common name and DNS names, for example fw01.example.com. Then set the same value as Hostname under Administration > Admin and user settings, select the new Certificate, and enable Use the firewall’s configured hostname.

For browsers to trust this certificate, download the public certificate of the Default CA under Certificates > Certificate authorities, extract the archive, and distribute Default.der or Default.pem as Default.crt to the managed endpoints. Distribute the Sophos Firewall CA certificate for TLS inspection explains the safe distribution and verification process for Windows, macOS, and Firefox. Only the public CA certificate is distributed, never a private key.

⚠️ This approach removes the browser warning only on managed devices that trust the Default CA. It does not make the certificate publicly trusted. If the Default CA is regenerated later, the certificates and trust distribution must be renewed in a controlled manner.

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.

Set up IPsec Site-to-Site with certificates explains how the CA, Certificate ID, Local Certificate and Remote Certificate work together between two firewalls.

Reset the WebAdmin certificate to default through the console

If WebAdmin is no longer usable after an incorrect certificate assignment, working Device Console access can serve as a break-glass path. First record the FQDN in use, the previous certificate assignment, and the expected fingerprint. Keep any existing administrator session open.

In the Device Console, open 2. System Configuration > 4. Reset Default Web Admin Certificate and confirm the reset with y. SFOS sets the WebAdmin console certificate to the default device certificate. The operation restores neither the previously selected certificate nor an old private key of the Default CA, and it does not regenerate the CA. The supplied Default CA also forms part of the HTTPS chain for web proxy block and warning pages, but option 4 does not reset that proxy function. A browser warning or name mismatch can therefore be expected with the locally signed default certificate.

After the success message, reopen WebAdmin only through the intended management path, inspect the certificate actually presented, and test a fresh sign-in. Because WebAdmin and several portals use the same certificate selection, also test every portal in operation. A repaired production certificate can then be reassigned in a controlled manner under Administration > Admin and user settings. The console reset is a recovery path, not a permanent solution for public trust.

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

Under Email > General settings > SMTP TLS configuration, TLS certificate uses either a CA or server certificate, depending on the configuration, to scan SMTP connections over TLS. Before changing it, document the previous purpose, certificate validation, and the affected inbound and outbound connections. If the firewall itself presents a server identity in public SMTP communication, a certificate from a public CA is recommended for that purpose. After Apply, test both traffic directions with the TLS modes actually in use. 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.

For an externally generated certificate, the public key derived from the private key must match the certificate’s public key:

(
tmpdir=$(mktemp -d)
trap 'rm -rf -- "$tmpdir"' EXIT
openssl x509 -in firewall.pem -pubkey -noout > "$tmpdir/cert-public-key.pem" &&
  openssl pkey -in firewall.key -pubout > "$tmpdir/key-public-key.pem" &&
  cmp "$tmpdir/cert-public-key.pem" "$tmpdir/key-public-key.pem"
)

Replace firewall.key with the local path to the private key. For an encrypted key, openssl pkey prompts interactively for the password. cmp produces no output when the public keys are identical; otherwise, the pair must not be imported. The temporary files contain only public keys, but are still removed after the comparison. Never display or upload the private key or attach it to a ticket.

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 -showcerts -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. -showcerts shows all certificates sent by the service; the server normally does not need to send the root CA. The expected server certificate and the intermediate CAs required to build the chain must appear in this output. Verification: OK additionally confirms the hostname and chain check against the test computer’s trust store. However, an intermediate already present there can conceal an incomplete chain delivered by the server.

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