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.

Alternatively, the CSR and CAs can be generated with an external tool such as OpenSSL. Upload externally generated subordinate and root CAs under Certificates > Certificate authorities; a signing CA without a matching firewall CSR also requires its private key through the approved PKI process. The root remains without a private key. This is a different key-transfer path, not the CSR import described below. The subordinate CA can also be used for email TLS configurations; the activation and validation below concern web traffic only and do not enable an email TLS configuration.

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.

Under Subject name attributes, the CSR form contains Country name, State, Locality name, Organization name, Organization unit name, Common name, and Email address. Enter identity details approved by the PKI, not the details of an arbitrary website being visited. Subject Alternative Names accepts DNS names or IP addresses, for example web.exampleorg.com, fd12:3456:789a:1::, or 203.0.113.10. These product example values are not requirements for an inspection CA; agree the SANs with the PKI owner.

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. Select Download certificate to download the issued subordinate CA certificate.
8. On the AD CS welcome page, open Download a CA certificate, select the root CA that signed the subordinate CA, then select Download CA certificate and Save.

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. Under Certificates > Certificate authorities, open the filter next to Name, enter the CA name, and select Apply.

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. The general CA import under Certificates > Certificate authorities > Add can also detect a matching existing CSR. Importing directly at the CSR as described here makes the association explicit, but is not the only documented association path. Without a matching CSR or private key, uploading the certificate again does not create a signing key.

Add the root CA for validation only

The Sophos step-by-step example calls the purpose Validation, while the CA field reference calls it Validation only. The safe role intended here is the same: root certificate for validation only, without the root private key; do not select Signing and validation for the root. For the upload, select the file under Certificate using Browse.

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. DPI has a global selection and a possible per-rule override; the web proxy has a separate selection:

• DPI, global: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• DPI, per rule: The decryption profile assigned under Profiles > Decryption profiles can inherit or override the global selection.
• Web proxy: Web > General settings > HTTPS decryption and scanning

The DPI settings have separate Re-sign RSA with and Re-sign EC with fields. They refer to whether the original website certificate was signed using RSA or EC. SFOS accepts an RSA or EC CA in either field. You can therefore normally select the same subordinate CA for both. A second EC CA is mainly useful when an application only accepts a specific certificate type; all affected endpoints must trust that CA as well.

A decryption profile assigned to an inspection rule can deliberately inherit the global selection with Use CAs defined in SSL/TLS settings. If you set separate Re-sign RSA with and Re-sign EC with values in the profile instead, they override the global settings for that rule. Before the pilot, check both the global CA selection and the profile actually assigned to the rule.

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; it would no longer be usable for active re-signing. This does not establish whether SFOS deletes the stored key.

Secure the pilot scope first: A global DPI CA change also affects existing rules whose profiles inherit the global selection. For an isolated DPI pilot, use a dedicated decryption profile with explicit CA values and assign it only to the pilot rule already limited to the test group. Do not edit a profile shared with production. A new pilot rule does not isolate the global web proxy CA selection; if proxy scanning is already active, a separately approved change covering all affected clients is required. Until then, leave the existing global CA unchanged.

For the pilot:

1. Document the current selection and affected rules.
2. Select the new CA for RSA and EC certificates in the intended inspection path. For DPI, confirm whether the assigned decryption profile inherits or overrides the global selection.
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.

API cross-check: separate CA selection from global switches

Anyone checking or automating CA selection via the XML API must distinguish between the fields in the SSLTLSInspectionSettings object. The references for SFOS 22.0 and 23.0 list the same fields; this does not prove that a specific firewall has already applied a change successfully.

• RSACA and ECCA select the CAs used to re-sign RSA and EC server certificates respectively, corresponding to Re-sign RSA with and Re-sign EC with. The value is the name of the intended CA object, for example SFOS-TLS-Inspection-SubCA-2026, not a certificate file path, private key or enablement value. This selection does not create or import a CA, nor does it distribute client trust. The previously described requirements for signing purpose, private key, chain and profile overrides still apply; where two different CAs are used, the affected clients must be able to validate both chains.

• SSLTLSEngine controls the TLS engine, and SSLTLSInspection controls global SSL/TLS inspection; both accept Enabled or Disabled. These fields represent neither CA selection nor the status of the individual pilot rule. A CA rotation is not a reason to change these global switches. The API reference lists Enabled as the default for both; however, the change must be based on the actual state read from the device, not a documented default.

• TLS13Decryption specifies the global handling of TLS 1.3 connections: Decrypt as 1.3 or Downgrade to TLS 1.2 and decrypt, with the documented default Decrypt as 1.3. This field selects neither a signing CA nor the action of an individual inspection rule. A downgrade is therefore not a remedy for a missing CA chain or signing key; for a CA-only change, the approved TLS 1.3 setting remains unchanged.

SSLv2SSLv3, SSLCompression and SSLConnectionsExceeded are also separate global decisions governing legacy protocols, SSL compression and exceeded SSL connection capacity respectively. Each accepts Allow without decryption, Drop or Reject; the API lists Allow without decryption as the default for each, not as a security recommendation. These decisions must not be reset to example values as a side effect of a CA rotation.

Before making an API change, back up the global values actually stored, both CA object names, profile overrides and affected rules, and define the exact restoration procedure. The reference marks the listed fields as optional; this does not prove that omitted fields remain unchanged on every firmware version. Do not perform an automated write operation unless update and restoration behaviour has been confirmed for the specific build. A documented API response of 200 indicates operation success, and 500 indicates operation failure; even a success message does not replace reading back the stored values and testing with new HTTPS connections. An unexpected value or unclear state must halt expansion of the pilot.

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.

For acceptance, test both an RSA and an EC server certificate in the intended DPI path and, for each, compare the presented issuer, complete root/subordinate chain, client trust, actually assigned profile and logged action. Where different signing CAs are used, validate both trust chains separately. Also confirm that the global switches, TLS 1.3 handling and other global decisions match their documented pre-change state, and that a source outside the pilot remains unaffected.

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:

For a CA rollback, prefer restoring the previous CA or profile. Disabling a pilot rule alone guarantees neither the previous CA nor the previous decryption behavior: a later rule may take over. Check the actual fallback path beforehand and verify the certificate and logs again afterward.

A CA rollback restores only the CA/profile changes made for the pilot to the backed-up pre-change state. Indiscriminately setting SSLTLSEngine or SSLTLSInspection to Disabled, or changing TLS13Decryption, restores neither the previous CA nor the previous protection path. Afterwards, read back the stored selection and overrides, and check the certificate chain and logs using new connections. If no verified restoration procedure is available, do not continue the rollout.

1. Restore the previous re-signing CA or the previous decryption profile, as applicable. Disable the pilot rule only if the previously verified subsequent processing path restores the approved pre-change state; do not indiscriminately disable the global engine or inspection.
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

Check the existing CSR, its issued certificate, and the automatic key association. Importing under Certificates > Certificate authorities > Add also depends on whether SFOS finds a matching CSR. If the matching CSR is absent or the certificate does not match it, the association has not been established. 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