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 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:

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.

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

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.
4. Download the certificate using the download icon.

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.

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.

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

Firefox can use its own certificate stores depending on the configuration. In Windows environments, there are two common ways:

• Configure Firefox to use Windows Root CAs.
• Distribute certificates via Mozilla Enterprise Policies.

The second option is useful in environments where Firefox is centrally controlled via GPO.

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 documents additional paths and variants 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 if the traffic is shown as decrypted.
6. Test important business applications, update services, collaboration tools, and identity providers.

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

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