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.

Besides the built-in CA, you can import an externally generated signing CA or create a Certificate Signing Request (CSR) on the firewall and have an external CA, such as Active Directory Certificate Services, issue a subordinate signing CA. With an external signing CA, import both the subordinate signing CA and its root CA on the firewall. Clients need the matching public trust anchor and required public chain, not the private signing key. The linked PKI procedure covers issuance; the following steps cover selection, distribution, and verification.

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: Use GPO to deploy to Trusted Root Certification Authorities. This is the preferred approach for traditional Active Directory environments.
• Windows without a domain: Use MDM, Intune, or local import. Local import is best suited to tests or individual devices.
• macOS: Use an MDM profile or the System keychain. Manual installation is best suited to tests or small environments.
• Firefox: Use Windows Trust Store or Mozilla Enterprise Policies. Firefox behaviour must be checked separately.
• BYOD or private devices: Normally, don’t distribute the CA to these devices. TLS Inspection belongs on managed corporate devices.
• Servers: Distribute only for server workloads whose inspection has been assessed deliberately. Outgoing server traffic may involve different 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

Prepare the web proxy rule and CA

For a web proxy pilot, open Rules and policies > Firewall rules, select IPv4 or IPv6, and create a rule through Add firewall rule > New firewall rule. For example, use TLS-CA-Pilot as a freely chosen name, set Source zones to LAN, Source networks and devices to the pilot network, Destination zones to WAN, and Destination networks to the intended targets. Adapt zones, networks, and targets to the actual path; don’t grant blanket access to all clients for a certificate test.

Before making changes, record the previous rule values and CA selection for rollback. Separately check HTTPS scanning certificate authority (CA) under Web > General settings > HTTPS decryption and scanning, then distribute its public certificate to all affected pilot endpoints and verify trust by fingerprint. The shared web proxy CA is global: changing it is not a per-rule CA pilot, affects all web proxy clients, and requires their trust in advance and a maintenance window.

Only then, in the selected firewall rule under Security features > Web filtering, choose the appropriate web policy, enable Scan HTTP and decrypted HTTPS, Use web proxy instead of DPI engine, and explicitly Decrypt HTTPS during web proxy filtering, then select Save. The scan option alone doesn’t decrypt; CA selection under Web > General settings doesn’t replace the firewall rule’s decryption control.

During initial setup, check that the Default CA settings are fully configured under Certificates > Certificate authorities > Default. This is a configuration check, not an instruction to regenerate the CA or distribute Default instead of the active SecurityAppliance_SSL_CA.

Download the public CA certificate

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.

For a manual pilot, provide the verified public file through the company intranet or controlled email distribution. Users save it locally and compare its identity with the separately recorded certificate details before granting trust. GPO or MDM remains preferable for larger groups.

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 to the intended test OU. If needed, use a security group through security filtering, not as a GPO link target.
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.

For an individual user, the login keychain is also an option: double-click the downloaded file to open Keychain Access, verify its identity, and select Always Trust. Safari also uses this macOS trust. For a managed device-wide rollout, System or MDM remains appropriate; don’t confuse user and system scope.

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

⚠️ Android: installation is not approval for decryption. Sophos documents CA import but also recommends excluding all Android devices from DPI SSL/TLS inspection because of certificate errors. This guide therefore defaults to DPI exclusion for all Android devices. The following Android import and HTTPS test steps apply only to a separately approved, narrowly scoped managed-device pilot: a documented business need must justify departing from that recommendation for named devices and applications. Verify the actual trust store and every affected application before approval; on failure, roll back the pilot and restore exclusion. MDM installation fixes neither certificate pinning nor trust in every app. The DPI recommendation is not a blanket statement about web proxy compatibility; that path also requires separate application validation.

Manual mobile pilot

If the device doesn’t accept the PEM file, conversion to a compatible certificate format such as .der, .cer, or .crt may be necessary. A filename extension alone doesn’t determine the encoding; never use a private-key file. Menu labels vary by Android version and manufacturer. A Pixel example uses Settings > Security & location > Advanced > Encryption & credentials:

1. Under Credential storage, select Install from storage or Install from SD card.
2. In the file picker, use Menu > Open from to select the storage location and open the public certificate file.
3. Enter the device PIN, assign a recognizable certificate name, and select VPN and apps for this app pilot; Wi-Fi is the separate category offered. Confirm with OK.
4. Check the identity and import under User credentials, then test a decrypted HTTPS request. Successful import doesn’t guarantee that every Android app trusts the user certificate store.

For a manual iOS pilot, provide and import the public CA file on the device. Then enable trust only for the identified root certificate under Settings > General > About > Certificate Trust Settings > Enable full trust for root certificates and test HTTPS. Don’t enable several unknown root CAs.

Distribute centrally through the device policy

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. Then connect one or more iOS devices to the Mac to install the profile containing the CA certificate.

Root certificates installed on iOS and iPadOS devices through MDM or Apple Configurator are automatically trusted. This differs from manual import; the trust check below isn’t an instruction to change a setting that is already enabled.

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.

On iOS, check the trust status there for the intended root certificate after verifying its identity against the recorded fingerprint. If trust is still disabled, enable trust under Enable full trust for root certificates for this root certificate only. If it is already trusted, leave the setting unchanged; then repeat the decrypted HTTPS request to verify it.

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

A manual import is also possible for a single test profile: open Settings > Privacy & Security > Certificates > View Certificates > Authorities > Import, select the public CA file, and select Open. In Downloading Certificate, enable only Trust this CA to identify websites for the CA whose identity you have already checked, then select OK. Restart Firefox and test the decrypted HTTPS path. This profile import doesn’t replace centralized distribution.

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

Copy firefox.admx and mozilla.admx directly into the selected PolicyDefinitions folder. The matching firefox.adml and mozilla.adml belong in its language-specific subfolder, not alongside the ADMX files.

Typical local path:

C:\Windows\PolicyDefinitions

For a domain Central Store, use \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions instead. Replace both occurrences of <domain> with your AD domain’s DNS name. If a Central Store exists, deploy the Mozilla templates there; a copy in the local folder alone is not sufficient for domain GPO editing.

Preserve the language folders from the downloaded package and use ADMX and ADML files from the same template version. For example, place the English ADML files in C:\Windows\PolicyDefinitions\en-US or, when using the Central Store, in \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\en-US. Copy any other required languages into their respective package subfolders. en-US is an example template language, not a requirement based on this article’s language.

Reopen the Group Policy editor and verify that Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates is visible without resource errors. If it is missing, correct the destination folder, language subfolder, and version pairing before continuing with the certificate policy.

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.

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. Correlate the fresh request on the firewall by source, destination, and time, identify the actual operating mode, and use the corresponding checks below.
6. Test important business applications, update services, collaboration tools, and identity providers.

DPI: Under Rules and policies > SSL/TLS inspection rules, check the matching inspection rule, action, Decryption Profile, and re-signing CA. In Log Viewer > SSL/TLS inspection, correlate the same fresh request by source, destination, and time, then check decryption and the applied rule/action. Also check DPI exclusions.

Web proxy: Confirm the firewall rule that actually matches, its web policy, and Decrypt HTTPS during web proxy filtering. Check the shared HTTPS scanning certificate authority (CA) under Web > General settings and applicable exceptions under Web > Exceptions. In Log Viewer, correlate the relevant web-filter/proxy logs for that same fresh request by source, destination, and time; the browser’s certificate issuer and chain must match the selected CA. SSL/TLS inspection rules do not govern web proxy decryption. A DPI decryption entry is neither promised nor required here; a web-filter log entry alone doesn’t prove decryption.

If the browser still shows the original public website certificate, this connection was not decrypted. In DPI mode, check the inspection rule and its exclusions; for web proxy, check the matching firewall rule, decryption control, and web exceptions. A different traffic path or QUIC/HTTP/3 can also bypass the expected TCP path.

If the browser warning disappears but applications still show errors, the certificate itself often isn’t the cause. Certificate pinning or a separate trust store may be responsible. In DPI mode, also check the Decryption Profile, inspection rule, and TLS exclusions; for web proxy, check the firewall rule and web exceptions using the checks above.

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 may be responsible. For DPI, check SSL/TLS logs and TLS exclusions; for web proxy, check web-filter/proxy logs and Web > Exceptions, always for the same request.
• 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: Use the mode-specific checks above: inspection rule, profile, and SSL/TLS logs for DPI; firewall rule, decryption control, shared CA, web exceptions, and web-filter/proxy logs for web proxy.
• Warnings after CA regeneration: Clients may lack the new active CA. Distribute the new public CA first and verify its fingerprint. Remove an old, non-compromised CA only when no active path still uses it; follow the emergency procedure if it is compromised.
• 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: DPI may lack a matching inspection rule; web proxy may lack the firewall-rule decryption control or match a web exception. Use the mode-specific checks above and verify the actual traffic path.
• Only mobile apps or individual clients fail: Consider separate trust stores, certificate pinning, and app-specific validation. Exclude Android devices from DPI by default; a separately approved Android pilot must revert to exclusion on failure. Assess other exceptions narrowly rather than disabling inspection globally.

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