Set up a subordinate CA for Sophos Firewall TLS inspection

For TLS inspection, Sophos Firewall must re-sign certificates for the HTTPS destinations being visited. Instead of using the built-in SecurityAppliance_SSL_CA, you can use a dedicated subordinate enterprise CA. Managed clients then continue to trust the organization’s own root CA, while the private key of the subordinate CA remains on the firewall.

The safe process consists of six steps:

1. Generate a CSR for the new subordinate CA on Sophos Firewall.
2. Have a Microsoft AD CS Enterprise CA sign the CSR with the Subordinate Certification Authority template.
3. Import the issued CA certificate directly into the existing CSR.
4. Add the corresponding root CA to the firewall as Validation only.
5. Select the subordinate CA as the re-signing CA and initially use it only in a pilot rule.
6. Verify the certificate chain, real HTTPS traffic, logs, and rollback.

⚠️ A re-signing CA can issue certificates for third-party domains. Its private key is therefore particularly sensitive. The CA must only be used for the intended inspection path and must not be exported or shared in tickets. Do not enable it in production without a tested recovery path.

This process is written for AD CS in Enterprise CA mode. Sophos explicitly states that the documented procedure doesn’t apply to a Standalone CA. Another internal PKI can also issue a subordinate CA, but it requires its own process reviewed by the PKI owner.

When a subordinate CA is useful

A dedicated subordinate CA is most useful in managed enterprise networks where clients already trust an internal root CA. This avoids distributing an additional, independent Sophos trust anchor to every device. Rotation, revocation, and ownership can be incorporated into the existing PKI governance.

However, the solution is not automatically simpler. The firewall receives a key that it can use to sign certificates for TLS inspection. The CA therefore needs a narrowly defined purpose, documented owners, a limited lifetime, and tested revocation and renewal procedures.

For smaller environments without an internal PKI, the built-in Sophos CA is often the simpler approach. Distribute the Sophos Firewall CA certificate for TLS inspection explains its selection and client deployment. Introduce Sophos Firewall TLS inspection correctly covers the complete pilot and exception process.

Prepare the CA design and recovery path

Define the purpose, names, and dependencies before generating the CSR. One example is:

• SFOS object name: SFOS-TLS-Inspection-SubCA-2026
• Common Name: SFOS TLS Inspection SubCA 2026
• issuing root CA: Example Enterprise Root CA
• intended use: TLS inspection and HTTPS decryption on FW01 only
• pilot network: 10.20.30.0/24

These are documentation examples and must be replaced with the organization’s naming convention, PKI, and pilot group. A separate CA for each firewall or clearly defined inspection cluster simplifies assignment, revocation, and rotation later.

Before the change, make sure the following are available:

• a current configuration backup and working independent management access,
• documentation of the current re-signing CA and its client deployment,
• access to an AD CS Enterprise CA and approval from the PKI owner,
• a small managed test group with a working recovery path,
• a plan for revocation, renewal, and a controlled return to the previous CA.

Create and restore a Sophos Firewall backup explains the backup and restore process. A backup does not replace documenting the currently selected re-signing CA and the clients that trust it.

Generate the CSR on Sophos Firewall

Generate the CSR on the firewall so that the private key is created there and doesn’t have to be transported between AD CS, an administrator workstation, and the firewall.

1. Go to Certificates > Certificates.
2. Select Add.
3. Under Action, select Generate certificate signing request (CSR).
4. Enter a unique name such as SFOS-TLS-Inspection-SubCA-2026.
5. Select the key type, key length or curve, and secure hash according to the organization’s PKI policy. Sophos uses RSA, 2048 bits, and SHA-256 in its example; these are product examples, not universal requirements.
6. Enter the subject attributes and subject alternative names approved by the internal PKI.
7. Save the CSR and open it using the download icon.
8. Use Copy to clipboard and submit the CSR only through the authorized AD CS process.

The CSR does not contain the private key. It still belongs in the controlled PKI process because it specifies the identity, public key, and requested CA purpose.

Issue the subordinate CA with AD CS

Submit the Sophos CSR through the web enrollment page of the responsible AD CS Enterprise CA:

1. Open Request a certificate.
2. Select Advanced certificate request.
3. Paste the complete CSR.
4. For Certificate template, select Subordinate Certification Authority.
5. Review the request according to the internal approval process and select Submit.
6. Under Certificate Issued, choose a suitable format, such as Base 64 encoded.
7. Download the issued subordinate CA certificate.
8. Also download the certificate of the root CA that signed the subordinate CA.

Important EKU boundary: If the issued CA certificate contains an Extended Key Usage section, it must include TLS Web Server Authentication for this signing purpose. If it doesn’t, don’t use the certificate as a production re-signing CA. The PKI owner must correct the CA template and issue a new certificate.

Before importing, review the issuer, subject, validity, basic constraints, and, where present, extended key usage in the certificate viewer. Give the root and subordinate files unambiguous names so they cannot be confused with server certificates.

Import the subordinate and root CAs

Import the subordinate CA into the existing CSR

1. Go to Certificates > Certificates.
2. Select the import action for the CSR created earlier.
3. Select the subordinate CA certificate issued by AD CS.
4. Select Certificate authority only. SFOS detects the CA type and shows the CA options.
5. Review the name and select Import certificate.
6. Go to Certificates > Certificate authorities and locate the imported CA.

SFOS automatically associates the private key belonging to the CSR with the subordinate CA. The private key icon must therefore be visible for this CA in the CA list. If it is missing, the CA is not ready for signing; uploading the file again elsewhere does not restore the missing key association.

Add the root CA for validation only

1. Go to Certificates > Certificate authorities and select Add.
2. Upload the root CA certificate that issued the subordinate CA.
3. Under Use certificate for, retain Validation only.
4. Compare the name and fingerprint with the approved root CA documentation.
5. Save and check the subordinate CA chain again.

The firewall doesn’t need the private key of the root CA. Signing and validation is intended only for the subordinate CA whose private key already resides on the firewall through the CSR. Import and assign certificates on Sophos Firewall explains the general differences between a certificate, CSR, private key, and CA chain.

Select the CA for TLS inspection

Importing the CA does not change any traffic. First enable the new CA in a narrowly scoped pilot. The selection is in different locations depending on the inspection path:

• DPI: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• Decryption profile: Profiles > Decryption profiles
• Web proxy: Web > General settings > HTTPS decryption and scanning

Only a CA with the Signing and validation purpose and an available private key may be used as a re-signing CA. Don’t change an in-use signing CA to Validation only, because the active re-signing path would lose its key.

For the pilot:

1. Document the current selection and affected rules.
2. Select the new CA in the intended inspection path.
3. Limit the rule to the defined test group or pilot network.
4. Verify the CA chain on the pilot clients. In an AD domain, the enterprise root CA should already be trusted, but the complete chain to the new subordinate CA must still build successfully.
5. Generate a real HTTPS request and review the certificate details, inspection rule, decryption profile, and log entry together.

Only proceed with a broad production change after the pilot passes. Selecting the CA doesn’t automatically enable an inspection rule, and client trust does not prove that traffic is actually being decrypted.

Validate operation and security

A successful test includes several pieces of evidence:

1. Under Certificates > Certificate authorities, the root CA is present as Validation only.
2. The subordinate CA is assigned Signing and validation and shows the private key icon.
3. A pilot client trusts the root CA and can build the complete chain.
4. A deliberately decrypted HTTPS site presents a server certificate signed by the new subordinate CA.
5. The hostname, original destination, and browser status are correct, with no unexpected certificate warning.
6. Log Viewer shows the expected SSL/TLS inspection rule and action for this exact test.
7. A source outside the pilot remains on the previous path.

Also test applications with certificate pinning, custom trust stores, or sensitive update paths separately. One successful browser request is not enough to approve the entire rollout.

Rotation and rollback

Renew the subordinate CA before it expires. Keep the new and old CAs clearly distinguishable during a controlled transition. First issue and import the new CA, validate it on pilot clients, and only then select it incrementally in the inspection path.

If a test fails, use the prepared recovery path:

1. Disable the pilot rule or switch it back to the previous re-signing CA.
2. Use a new browser process to confirm that the previous certificate path is active again.
3. Don’t delete the new CA while rules, decryption profiles, or web proxy settings still reference it.
4. Involve the PKI owner if the EKU, chain, template, or revocation status is unclear.
5. Don’t continue to use compromised keys. Revoke the CA, issue a new one, and clean up trust stores in a controlled manner.

Only delete a CA after no configuration references it, the previous path is no longer required, and retention and audit requirements have been met.

Troubleshoot specific symptoms

The private key icon is missing

If the certificate wasn’t imported through the matching CSR, SFOS cannot associate it with the key created on the firewall. Check the CSR association path and the issued certificate. Don’t import private keys from tickets, email, or uncontrolled storage.

The CA cannot be selected as a re-signing CA

Check the CA purpose, private key icon, and certificate extensions. If Extended Key Usage is present, it must include TLS Web Server Authentication. A root CA with Validation only is intentionally unavailable for re-signing.

A client reports an untrusted chain

Check the root and subordinate CAs, their fingerprints, and the trust store on the affected client. Then compare the issuer actually presented in the browser with the CA selected on SFOS. The mere presence of the root CA on the firewall or client does not prove that the correct re-signing CA is active.

The browser works, but an application doesn’t

The application may use a custom trust store or certificate pinning. First document the destination, client, inspection rule, and time of the error. Don’t add a global Don't decrypt exception. Isolate the issue in the small pilot and approve only the required exception with a documented reason.

FAQ