Renew the Sophos Firewall Default CA safely

The built-in Default CA on Sophos Firewall isn’t an ordinary description entry. As soon as its settings are saved, SFOS automatically regenerates the CA. This creates a new key and therefore a new trust anchor. Existing trust relationships don’t automatically match it afterward.

A controlled renewal therefore doesn’t begin with Save, but with a complete dependency list. This includes locally signed certificates, WebAdmin and portals, SSL VPN profiles, certificate-based IPsec peers, and external systems that trust the previous CA.

⚠️ Important: Only renew the Default CA with a verified backup, independent management access, a maintenance window, and a plan for every dependent service. A cosmetic change to the country, organization, or common name doesn’t justify an unplanned regeneration.

Renew the Default CA in ten steps

1. Document the technical reason, change owner, maintenance window, and success criteria.
2. Identify all certificates, services, VPN profiles, peers, and clients that trust the existing Default CA.
3. Check whether the actual target is only the ApplianceCertificate or the separate SecurityAppliance_SSL_CA.
4. Positively test the current configuration backup, SSMK, local admin access, and recovery path.
5. Download the old Default CA and record its SHA-256 fingerprint, subject, serial number, and validity.
6. Approve the new CA details, key type, and compatibility with all peers in writing.
7. Under Certificates > Certificate authorities > Default, enter the prepared values and save them only during the maintenance window.
8. Download the new public CA and distribute it to peers, clients, and trust stores in a controlled manner.
9. Test WebAdmin, portals, SSL VPN, IPsec, and every other dependent service separately.
10. Document the fingerprint, logs, test results, and remaining old profiles. Use the prepared recovery path if a critical error occurs.

Distinguish the Default CA, ApplianceCertificate, and inspection CA

Sophos Firewall contains several objects with different purposes:

• Default: internal CA for locally signed certificates.
• ApplianceCertificate: built-in server certificate used by default for WebAdmin, the user portal, and the captive portal. It is signed by the Default CA and can be regenerated separately.
• SecurityAppliance_SSL_CA: separate built-in CA for HTTPS inspection and re-signing when selected in the TLS inspection configuration.

These objects must not be treated as the same thing. A problem with one ApplianceCertificate doesn’t prove that the Default CA is defective. Likewise, changing the Default CA doesn’t automatically perform a planned rotation of the SecurityAppliance_SSL_CA.

Import and assign certificates on Sophos Firewall explains the general work with certificates, private keys, CSRs, and CA chains. The inspection CA has its own procedure in Distribute the CA certificate for HTTPS scanning.

When regeneration is justified

A planned change may be required when:

• the previous CA key is known or reasonably suspected to be compromised,
• the CA is expiring and is still actively used,
• identity, key type, or cryptographic requirements are being migrated in a controlled manner,
• Sophos Support requires regeneration for a confirmed issue.

An isolated failed VPN download, a browser warning without chain analysis, a cosmetic subject request, or an old community command aren’t sufficient reasons. For an issue involving .ovpn and ApplianceCertificate, first troubleshoot the SSL VPN configuration download systematically.

Inventory dependencies before the change

Certificates and assigned services

Under Certificates > Certificates, record at least the name, subject, issuer, validity, and actual assignment of every locally signed certificate. Depending on the environment, this includes:

• WebAdmin, the user portal, and the captive portal,
• the SSL VPN server certificate,
• site-to-site and remote access IPsec using Digital certificate,
• WAF, SMTP, API, or other TLS services,
• self-generated client or server certificates outside the firewall.

A visible certificate isn’t automatically a dependency. What matters is whether a production service uses it and whether the peer trusts its issuing Default CA.

Trusting systems and distribution paths

Also document:

• browsers and operating systems with the old CA installed,
• MDM, GPO, or software distribution for the new CA,
• IPsec peers with an imported Default.pem, remote CA, or DN mapping,
• SSL VPN users and the distribution path for new .ovpn profiles,
• monitoring, API clients, or integrations that pin certificates,
• HA, emergency, and external management access.

Stop the change if it isn’t clear who distributed the previous CA or which peers trust it.

Preserve the initial state and recovery path

Before the maintenance window, download the Default CA under Certificates > Certificate authorities. The archive contains the public portion, not automatically a separately usable export of its private key.

PEM data can be inspected read-only on an admin computer:

openssl x509 -in Default.pem -noout -subject -issuer -serial -dates -fingerprint -sha256

Specify the input format for a DER file:

openssl x509 -inform DER -in Default.der -noout -subject -issuer -serial -dates -fingerprint -sha256

Store the fingerprint and output in the before-state together with the firewall name, serial number, SFOS build, and change ticket. Don’t attach certificate files and internal PKI data unprotected to public tickets.

Also store a current Sophos Firewall backup with its password and SSMK externally. A restore replaces the entire configuration, restarts the firewall, and may revert later changes. It is a planned last recovery path, not a quick undo function for the CA.

Prepare the maintenance window

Before Save, all of the following must be green:

• local admin account or a second admin tested from the management network,
• console or another independent recovery path available,
• new CA values and cryptography compatible with all peer systems,
• owners of VPN peers, MDM/GPO, and portals available,
• new profiles, trust-store distribution, and test accounts prepared,
• enough time for a complete backup restore if required.

In an HA cluster, make the supported WebAdmin change on the current primary. SFOS doesn’t document uninterrupted CA or session continuity for this change. Therefore, after a planned failover, test fresh sign-ins and all critical services again. Don’t edit the CA independently on both nodes.

Update the Default CA in SFOS

1. Open Certificates > Certificate authorities.
2. Click Default. The name itself can’t be changed.
3. Check Country, State, Locality, Organization, Organizational unit, Common name, and email address.
4. Under Private key settings, deliberately select RSA or Elliptic curve, the corresponding key length or curve, and the Secure hash.
5. Check the values against the change ticket and compatibility list.
6. Click Save only during the maintenance window.

Example values such as CH, Zurich, Example AG, IT Security, fw01.example.com, and pki@example.com are documentation values only. Replace them with the organization, actual firewall reference, and approved PKI naming convention.

⚠️ Save is the cutover point. SFOS automatically regenerates the Default CA. Re-entering the previous subject values later doesn’t restore the old key and fingerprint.

Immediately afterward, download the new Default CA and run the same OpenSSL check. A new SHA-256 fingerprint is expected after regeneration. Unexpected fields, a download error, or a state that can’t be documented are stop conditions.

Migrate dependent services in a controlled manner

WebAdmin and portals

Check which certificate is selected for WebAdmin, the user portal, and the captive portal under Administration > Admin and user settings. If a locally signed certificate using the new CA is selected, clients accessing it must trust the new CA.

Keep an existing full-admin session open during the test. New private browser windows test the FQDN, certificate chain, and sign-in from the intended management source. The CLI command that resets the WebAdmin certificate to the default device certificate isn’t a rollback of the old CA key.

SSL VPN

If SSL VPN uses the ApplianceCertificate or another locally signed server certificate, users must download and import a new .ovpn file after the Default CA settings change. An existing filename or a green tunnel status with an old profile isn’t sufficient validation.

At least one pilot user downloads the new profile through the intended portal path, establishes a fresh connection, and tests DNS, routes, and real application traffic. Remove old profiles from distribution only after all users have migrated successfully.

Certificate-based IPsec peers

With Digital certificate, Sophos Firewall peers exchange their CA certificates. If the peer previously imported the remote Default.pem, replace or add the new public CA on the peer in a controlled manner and verify the mapping again.

The complete connection configuration remains in Configure site-to-site IPsec on Sophos Firewall. For the CA change, test at least IKE establishment, the child SA, both traffic directions, and the actual applications. A green tunnel alone doesn’t prove the return path.

HTTPS inspection and other signing paths

For HTTPS inspection, first identify the signing CA actually selected under Web > General settings. If it is SecurityAppliance_SSL_CA or an external CA, don’t redistribute it just because the Default CA was regenerated.

Only include a signing path in the change when it is proven to use the modified Default CA or a dependent certificate. This limits trust-store changes to endpoints that are actually affected.

Verify the result and logs

Validation separates configuration from function:

1. Download the new CA and document its subject, issuer, serial number, validity, and SHA-256 fingerprint.
2. Under Certificates > Certificates, check the issuer, Trusted, and affected certificate objects.
3. Test WebAdmin, portals, SSL VPN, IPsec, and other assigned services individually.
4. Check vpncertificate.log for the CA and certificate operation at the time of the change.
5. Check configuration-audit.log for the administrator, time, and supported before-and-after data.
6. Correlate only the errors and successes belonging to the test in the relevant service logs.

Trace configuration changes with configuration-audit.log explains the audit trail. Not every service writes the same level of detail to configuration-audit.log, so functional validation remains mandatory.

Rollback and stop conditions

A regenerated CA doesn’t have a simple Undo control. Saving the previous text again doesn’t restore the old private key.

Therefore, define the recovery path for each service in advance:

• retain independent management access and the existing admin session,
• switch portals back to an already validated, independent external certificate if one is available and can be assigned safely,
• revert peer trust and client profiles only according to the documented previous state,
• use a full backup restore only when the effects, restart, SSMK, and loss of later changes are acceptable,
• escalate to Sophos Support with evidence when a dependency is unknown or the certificate state can’t be reproduced.

Don’t make shell database changes, delete certificates in bulk, restart services, or regenerate the CA a second time on suspicion. Stop the change when a critical peer can’t be coordinated, the new trust anchor isn’t distributed, or the recovery path hasn’t been positively tested.

Typical errors after regeneration

The browser reports an untrusted connection

Check the certificate chain actually delivered for the FQDN. If the server certificate is signed by the new Default CA, exactly that CA must be present in the trust store. Don’t import SecurityAppliance_SSL_CA indiscriminately.

SSL VPN no longer connects with the old profile

Correlate the selected SSL server certificate, new CA, portal download, and sslvpn.log. Download a new .ovpn file and import it as a new profile. Distinguish old and new profiles by the certificate and successful connection, not by the filename.

IPsec remains down after the CA change

On both sides, check the CA import, trusted status, local and remote certificates, ID, and strongswan.log. With DER ASN1 DN, a changed CA subject can also affect identity. Don’t relax profiles or IDs on suspicion.

HTTPS inspection shows certificate errors

First check the signing CA that is actually selected. If SecurityAppliance_SSL_CA is still in use and unchanged, the error isn’t automatically caused by the new Default CA. Investigate the certificate chain, decryption rule, and endpoint trust separately.

Checklist

• The reason and scope of the CA regeneration are documented.
• The old CA, fingerprint, backup, password, and SSMK are preserved.
• All certificates, services, peers, clients, and distribution paths are inventoried.
• Default, ApplianceCertificate, and SecurityAppliance_SSL_CA have been assessed separately.
• The maintenance window, admin recovery path, and responsible owners are ready.
• The new CA values and cryptography are compatible with all peers.
• The CA was saved only in the approved window and downloaded afterward.
• WebAdmin, portals, SSL VPN, IPsec, and other services have been tested separately.
• vpncertificate.log, configuration-audit.log, and service logs have been preserved.
• Rollback or support escalation is possible without uncontrolled shell changes.

FAQ