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.

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.

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 productive firewall, be versioned or at least traceably stored, and not reused from old projects.

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.

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.

Planned change:

1. Prepare new CA or new firewall CA.
2. Distribute new CA to a test group.
3. Test TLS Inspection with the test group.
4. Distribute new CA to all affected managed devices.
5. Check firewall rules and decryption profiles.
6. Remove old CA only when all productive devices have 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.

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.
• Regenerate CA in case of device loss or CA compromise.

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