Distribute Sophos Firewall CA Certificate for TLS Inspection

When a Sophos Firewall decrypts HTTPS connections via TLS Inspection or HTTPS Scanning, the firewall creates a new certificate for the inspected connection and signs it with a local CA. Clients must trust this CA, otherwise browser warnings will appear or applications will terminate the connection.

Sophos Firewall includes the built-in CA SecurityAppliance_SSL_CA by default. This CA can be downloaded under Certificates > Certificate authorities and distributed to managed clients. The important point is not only that some Sophos CA is present on the clients. The distributed CA must match the CA that is actually used for re-signing in the TLS Inspection configuration.

An environment with its own enterprise PKI can instead issue a dedicated subordinate CA for Sophos Firewall TLS inspection. This keeps the signing key on the firewall and anchors trust in the existing enterprise root CA, but requires a controlled PKI and pilot process.

SecurityAppliance_SSL_CA isn’t the built-in Default CA for locally signed certificates. If this other trust anchor must be rotated, use Renew the Sophos Firewall Default CA safely. Don’t replace both CA objects together on suspicion.

Depending on the operating mode, this selection is checked in different places: for DPI-based SSL/TLS Inspection Rules, the CA under Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings is relevant. A Decryption Profile assigned to the rule can override these global values. For Web Proxy, the HTTPS Scanning CA is under Web > General settings > HTTPS decryption and scanning. If the active path selects a different CA from the one trusted on the clients, certificate errors occur even though a Sophos CA has been distributed.

The article Properly Implement Sophos Firewall TLS Inspection describes the entire rollout. This guide focuses on distributing the CA certificate to Windows, macOS, and Firefox.

What this certificate does

The Sophos Firewall CA certificate is not a server certificate for WebAdmin, WAF, or VPN Portal. It is the trust basis that allows clients to accept HTTPS connections newly signed by the firewall.

Separation is important:

• Firewall CA: signs newly generated certificates during TLS Inspection.
• Re-Signing CA or HTTPS Scanning CA: the specifically selected CA that the firewall uses in DPI mode or Web Proxy mode.
• Client Trust Store: decides whether browsers and applications trust this CA.
• SSL/TLS Inspection Rule: decides which traffic is decrypted.
• Decryption Profile: determines how strictly certificates, TLS versions, and errors are handled.
• Exclusion List: prevents decryption for problematic or deliberately excluded targets.

Distributing the CA alone does not activate TLS Inspection. Distribution only prevents managed clients from displaying certificate warnings for decrypted HTTPS traffic. Whether traffic is actually decrypted depends on firewall rules, web policy, SSL/TLS Inspection Rules, Decryption Profiles, and exceptions.

CA distribution also does not replace clean protocol control. SSL/TLS Inspection Rules apply to TCP traffic. If web traffic runs over QUIC or HTTP/3 on UDP 443, inspection behaves differently and must be handled separately.

Before the rollout

Before distribution, it should be clear which clients should use TLS Inspection. A CA certificate should not be placed on every device indiscriminately, but specifically on managed corporate clients.

Preparation:

• Define a test group or test OU.
• Clarify operating mode: DPI mode, Web Proxy, or both variants.
• Document the selected CA in SSL/TLS inspection settings, the Decryption Profiles in use, and Web General settings.
• Document rollback and exception processes.
• Download the CA certificate only from your own firewall.
• Test distribution on a few devices first.
• Check browsers, business applications, and updates after distribution.
• Assess mobile devices and apps with their own trust store or certificate pinning separately.
• Remove old or unused CA certificates from the client trust store.

⚠️ Warning: If the CA or private key has been compromised, redistribution is not enough. The CA must then be regenerated on the firewall, redistributed, and the old CA removed from clients.

Choose distribution method

The appropriate distribution method depends on how the devices are managed.

• Windows Domain Clients: GPO in Trusted Root Certification Authorities. clean for traditional Active Directory environments.
• Windows without Domain: MDM, Intune, or local import. local import only for tests or individual devices.
• macOS: MDM profile or System keychain. manual installation only for tests or small environments.
• Firefox: Use Windows Trust Store or Mozilla Enterprise Policies. Firefox behaviour must be checked separately.
• BYOD or private devices: usually not distributed. TLS Inspection belongs on managed corporate devices.
• Server: only for deliberately inspected server workloads. outgoing server traffic may have other risks and exceptions.

For productive operation, it is crucial that the same rollout can also be reversed later. Those who distribute the CA via GPO, MDM, or policy should therefore also test the withdrawal of the old CA.

Download Sophos Firewall CA

On the Sophos Firewall, the certificate is downloaded via the web interface:

1. Log in to the Sophos Firewall as an administrator.
2. Open Certificates > Certificate authorities.
3. Find the CA SecurityAppliance_SSL_CA or the deliberately used custom CA.
4. Download the certificate using the download icon.
5. Then check whether the same CA is selected in the active TLS Inspection configuration.

The certificate is usually available as SecurityAppliance_SSL_CA.pem. This file contains the public part of the CA and can be distributed to clients. The private key must not be distributed to clients.

In SFOS 22, you can also download the CA actually selected directly where it is used. In the DPI path, the download icon appears next to Re-sign RSA with and Re-sign EC with. If two different CAs are selected, affected clients must trust both. In the web proxy path, the icon appears next to HTTPS scanning certificate authority (CA). Downloading it at the point of use reduces the risk of distributing a similarly named CA object that isn’t active.

The file should be treated as a security-relevant configuration element. The public part is not a password, but it defines which CA clients will trust in the future. Therefore, the file should come from your own production firewall, be versioned or at least traceably stored, and not reused from old projects. Before distribution, record the subject, issuer, serial number, validity period, and fingerprint shown in the certificate details. Compare these values on at least one pilot client after import; the display name alone is not reliable proof of identity.

There are two additional paths for checking the active CA:

• DPI mode: Open Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings and compare the CA selected there with the downloaded file. If the active rule uses a Decryption Profile, check its re-signing CA as well.
• Web Proxy: Open Web > General settings > HTTPS decryption and scanning and check the HTTPS Scanning CA.

This check prevents a common rollout error: the default CA is distributed to clients while the firewall already uses a different CA in a Decryption Profile or in Web Proxy.

Distribute certificate via GPO on Windows

In Active Directory environments, a group policy is the cleanest way. Edge, Chrome, and many Windows applications trust the Windows certificate store.

Recommended path in Group Policy Management:

Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities > Certificates

Procedure:

1. Open Group Policy Management on a Domain Controller or admin client.
2. Use an existing GPO for client baseline or create a new GPO for TLS Inspection test group.
3. Navigate to Trusted Root Certification Authorities > Certificates.
4. Right-click in the certificate list.
5. Select All Tasks > Import.
6. Import SecurityAppliance_SSL_CA.pem.
7. Link the GPO only with the desired OU or security group.
8. Run gpupdate /force on a test client or wait for regular update.

For productive environments, the GPO should not be applied directly to all computers. A test OU reduces the risk if a certificate is imported incorrectly or an application reacts unexpectedly.

Install certificate locally on Windows

For individual test devices, the certificate can be imported locally. There are two sensible variants:

• Local Computer Store: applies to all users on the device and is usually correct for managed clients.
• Current User Store: applies only to the logged-in user and is sometimes sufficient for tests.

For the local computer:

1. Log in as a local administrator.
2. Start certlm.msc.
3. Open Trusted Root Certification Authorities > Certificates.
4. Right-click in the certificate list.
5. Select All Tasks > Import.
6. Import SecurityAppliance_SSL_CA.pem.

For the current user, certmgr.msc can be used alternatively.

After import, browsers and applications should be restarted. For some applications, logging out or restarting the client is advisable.

Trust certificate in macOS keychain

On macOS, the certificate is imported via the Keychain Access.

Procedure:

1. Copy SecurityAppliance_SSL_CA.pem to the Mac.
2. Open the certificate by double-clicking.
3. Provide it in the System keychain or a managed MDM profile.
4. Open the certificate and set Always Trust under Trust.
5. Confirm the change with an admin account.
6. Restart browsers and affected applications.

In larger macOS environments, distribution should be done via MDM. Manual installation is more suitable for tests or individual devices.

Mobile devices with Sophos Mobile

For a larger number of managed Android, iOS, and iPadOS devices, distribute the CA through an MDM policy. Sophos Mobile can add the root certificate directly to the device policy that is already assigned. Apple recommends MDM or Apple Configurator; with Apple Configurator, first create a configuration profile on macOS.

Example for iOS and iPadOS in Sophos Mobile:

1. Go to Policies > iOS & iPadOS.
2. Select the policy already assigned to the intended devices.
3. On the Edit policy page, select Add > Root certificate.
4. Under Root certificate, use Upload a file to upload only the public CA certificate that devices must trust according to the planned chain. For SecurityAppliance_SSL_CA, this is the public CA part downloaded from SFOS.
5. Select Apply, then Save.
6. In the policy list, use the arrow to select Update devices. If this option isn’t available, the change is deployed during the next automatic synchronization.

For Android, add the root certificate to an Android policy in the same way. Don’t rely only on the policy status afterward. On iOS, check Settings > General > About > Certificate Trust Settings; on Android, check Settings > Security > Advanced > Encryption & credentials > User credentials. A real decrypted HTTPS request remains the final proof.

Never put the private key of the re-signing CA in Sophos Mobile or on an endpoint. Distribute only the public CA certificate. Start with a small pilot group and test removal of the CA as well.

Verify certificate on managed devices

After distribution, it should be verified on at least one test device per platform whether the CA has really landed in the correct trust store.

• Windows Computer Store: Open certlm.msc and search under Trusted Root Certification Authorities > Certificates.
• Windows Current User Store: Open certmgr.msc and check the user trust store.
• macOS: Open Keychain Access and check the trust status in the System keychain.
• Firefox: Open Settings > Privacy & Security > Certificates > View Certificates.

If a certificate is only in the user store, but an application expects the computer store, the browser may work while another application still shows certificate errors. Conversely, browsers with their own trust store may ignore the Windows or macOS distribution if not configured accordingly.

Firefox on Windows

Current Firefox versions on Windows search the operating system certificate store for additionally installed root CAs by default. If the Sophos Firewall CA is deployed to the Windows computer store by GPO, a second import into a separate Firefox database is therefore normally unnecessary. This behavior is controlled in Firefox by Allow Firefox to automatically trust third-party root certificates you install, the security.enterprise_roots.enabled preference, or the ImportEnterpriseRoots enterprise policy.

There are consequently two sensible approaches in managed Windows environments:

• Use the Windows trust store: the recommended standard approach when the CA is already deployed by computer GPO. Automatic use of operating system CAs must remain enabled in the managed Firefox configuration.
• Import the certificate directly through a Mozilla Enterprise Policy: an alternative when Firefox trust is deliberately managed separately or the operating system trust store must not be used.

With the first approach, the CA inherited from Windows can work without appearing as a separately imported entry in the Firefox certificate manager. The Windows computer store and a real HTTPS test are then authoritative. The following GPO instructions describe the second approach with Install Certificates.

Download Firefox GPO templates

Mozilla provides the policy templates on GitHub. Required files include:

• firefox.admx
• mozilla.admx
• firefox.adml
• mozilla.adml

The files can be downloaded from the Mozilla Policy Templates Repository or as policy_templates.zip.

Import templates

The ADMX and ADML files are copied to the central PolicyDefinitions path.

Typical local path:

C:\Windows\PolicyDefinitions

For a central store in the domain, the PolicyDefinitions folder under SYSVOL is used instead.

Configure Firefox policy

In the group policy, the certificate is then entered under the Firefox policies:

Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates

Procedure:

1. Enable the Install Certificates policy.
2. Enter the filename of the certificate, for example, SecurityAppliance_SSL_CA.pem.
3. Copy the certificate file via GPO or software distribution to the expected user profile directory.

Depending on the Firefox version and policy configuration, certificates are read from these directories:

%USERPROFILE%\AppData\Local\Mozilla\Certificates
%USERPROFILE%\AppData\Roaming\Mozilla\Certificates

After the next Firefox session, the certificate should be visible in the Firefox certificate manager.

Mozilla describes the recommended operating system trust and policy import in Set up Certificate Authorities (CAs) in Firefox. Additional paths and variants are documented in the wiki: Add Root Certificate to Firefox.

Verify functionality

After distribution, it should not only be checked whether the certificate is present. It is crucial to verify whether TLS Inspection works properly.

Useful tests:

1. Restart the test client or re-login the user.
2. Open a browser and access an HTTPS site decrypted by the Sophos Firewall.
3. Display the website’s certificate in the browser.
4. Check if the certificate chain runs through SecurityAppliance_SSL_CA or the chosen Sophos CA.
5. On the firewall, check in Log Viewer > SSL/TLS inspection whether the traffic is shown as decrypted and which rule or action was applied.
6. Test important business applications, update services, collaboration tools, and identity providers.

If the browser still shows the original public website certificate, this connection was not decrypted. In that case, either no matching SSL/TLS Inspection Rule applies, an exception wins, the traffic runs over another path, or QUIC/HTTP/3 bypasses the expected TCP path.

If the browser warning disappears but applications still show errors, the problem often lies not with the certificate itself. Common causes are certificate pinning, missing TLS exceptions, an incorrect decryption profile, or an unsuitable SSL/TLS Inspection Rule.

For web traffic, it should also be checked whether QUIC or HTTP/3 bypasses the expected inspection. The article Properly Block QUIC and HTTP/3 on Sophos Firewall explains why Block QUIC protocol remains relevant for web filtering, malware scanning, and TLS Inspection.

Common errors

• Browser still shows certificate warning: CA not in the correct trust store. Check Windows/macOS/Firefox certificate store.
• Chrome works, Firefox does not: Check whether Firefox is allowed to use additionally installed operating system root CAs or whether a separate Mozilla Enterprise Policy applies. Then restart Firefox and test the actual HTTPS path.
• Individual applications fail: Certificate pinning or custom certificate verification. Check TLS Inspection Log Viewer and exceptions.
• Only some clients work: GPO does not apply or wrong OU. Check gpresult and GPO linkage.
• CA is installed, but the warning remains: The distributed CA may not match the CA in the Decryption Profile, in SSL/TLS inspection settings, or under Web General settings.
• DPI works, but Web Proxy does not, or vice versa: Both paths can be configured differently. Check selected CA, rule path, and Log Viewer per operating mode.
• Warnings after CA regeneration: old CA still on clients or new CA missing. Remove old CA, distribute new CA.
• URL feeds or web filter do not work as expected: HTTPS path not decrypted. Check TLS Inspection and web policy.
• Certificate is present, but traffic is not decrypted: no suitable SSL/TLS Inspection Rule or wrong DPI/web proxy path. Check TLS rollout, firewall rule, and Log Viewer.
• Only mobile apps or individual clients fail: own trust store, certificate pinning, or app-specific verification. Check targeted exception instead of global deactivation.

CA rotation and emergency

A CA should not be operated unnoticed for years without knowing the expiration date, origin, and distribution. For productive environments, there should be a small lifecycle process.

The built-in SecurityAppliance_SSL_CA can be regenerated. However, this is not a risk-free preparation step: the old and new CAs aren’t automatically trusted in parallel on all clients. For a planned DPI transition with overlap, use a separately prepared signing CA and test it through a narrowly scoped Decryption Profile. The web proxy, by contrast, has only the global HTTPS scanning certificate authority (CA). Changing it affects the entire web proxy path and therefore belongs in a maintenance window; the new public CA must already be trusted by every affected client. In both cases, the private key remains on the firewall.

Planned change:

1. Record the active CA selection, fingerprints, and all references. Prepare a separate signing CA without regenerating the built-in CA as the first step.
2. Distribute only the public certificate or required public CA chain: first to the DPI test group, or to every affected client before a global web proxy change.
3. In DPI mode, activate the new CA through a narrowly scoped Decryption Profile and verify the issuer, log entry, and test-group applications.
4. After a successful DPI pilot, distribute the public certificate to every affected managed device and confirm the import by fingerprint.
5. Change the remaining DPI fields or the global web proxy CA. Use new connections to verify that the new CA signs them and that the expected rule applies.
6. Remove the old CA from client trust stores only after no inspection path references it and every affected device has received the new CA.

Emergency in case of compromise:

1. Control or temporarily disable TLS Inspection if necessary.
2. Replace affected CA on the firewall.
3. Roll out new CA via the defined distribution method.
4. Remove old CA from all trust stores.
5. Check exceptions, Log Viewer, and affected applications.
6. Document change in incident or change system.

Important: A compromised CA is not a normal certificate problem. If an attacker controls the private key, clients can trust forged certificates. The old CA must then be consistently removed.

For a normal rollback, first restore the inspection path to the previously documented CA or disable the pilot rule. Only after a new connection again shows the old issuer or the original, non-decrypted path should you remove the CA distributed only for the pilot. Removing client trust first while the firewall continues to re-sign with that CA causes certificate failures. Don’t delete shared or still-referenced CAs.

Operation and maintenance

The CA certificate should be part of the operational process:

• Document expiration date and responsible parties.
• Perform CA regeneration only as planned.
• Remove old CA from clients after migration.
• Regularly check distribution via GPO or MDM.
• Document TLS exceptions and review periodically.
• Trigger the incident and CA transition process if the signing private key or firewall may be compromised. Losing a client that only contains the public CA certificate doesn’t compromise the signing key.

When making changes to TLS Inspection, also check the affected firewall rules, decryption profiles, and exclusion lists. Otherwise, the client may trust the CA, but the firewall still does not decrypt the desired traffic.

FAQ