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.

If the inspection CA is to come from the organization’s own PKI, the Default CA is not the correct replacement. Use the separate process to set up a subordinate CA for Sophos Firewall TLS inspection.

When regeneration is justified

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

Distinguish planned rotation with a verified valid, uncompromised old chain from incident recovery after suspected or confirmed key compromise or an already expired CA. Only the first case permits a limited overlap. In an incident, containment and an approved cutoff take priority over the ordinary migration schedule; affected services must not continue using unsafe old trust until every user has migrated.

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.

The download on the CA page only preserves the CA certificate. SFOS 22 additionally provides CertificateAuthority under Backup and firmware > Import export > Export selective configuration. Use Apply selected items > Export > Download to export the CA configuration, including its private key. This file is highly sensitive: store it encrypted, access-controlled, and outside the firewall, and record its retention period in the change.

Treat the selective export as an additional safeguard, not as an untested Undo control. To import it to another firewall or after a reset or reimage, SFOS requires the SSMK that was valid at export time; without it, private keys and dependent configurations aren’t imported. Before the change, therefore verify the export and approved import procedure on a compatible, non-production firewall running the same or later firmware, or confirm it with Sophos Support. Don’t trial-import the old CA on the production firewall. Until this path has been positively verified, don’t plan it as rollback; a complete, compatible backup restore is a last recovery path to the old chain only if that chain is verified valid and uncompromised. Even a verified import procedure is an old-chain recovery option only if that chain is verified valid and uncompromised; restoring a compromised old key does not justify resuming secure service.

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 to a verified valid, uncompromised old chain, 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 name, State, Locality name, Organization name, Organization unit name, Common name, and the contact person’s email address.
4. Under Key type, deliberately select RSA or Elliptic curve, then specify Key length for RSA or Curve name for Elliptic curve and the algorithm under Secure hash. If a Private key password is already set and needs to be changed, include that change in the same approved change.
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.

The fields describe the CA identity: Country name is the country where the firewall is deployed, State the region, and Locality name the city. Organization name identifies the certificate owner, Organization unit name the assigned department, and Common name the hostname or FQDN. The email address belongs to the contact person.

Private key password applies to an existing password for the private key. It is neither the backup password nor the SSMK. Record a planned change in the approved password store, not in the change ticket or a screenshot. The instructions for SFOS 22 and 23 describe this conditional password change, but do not describe a reset function or explain what an empty password field means. If the existing password is unknown or the interface differs, clarify this with Sophos Support before clicking Save, rather than clearing the field as an experiment.

With RSA, larger keys offer greater security but require more time for encryption and decryption. Therefore, approve the key length together with compatibility and operational requirements; for Elliptic curve, select Curve name instead. Secure hash specifies the hash algorithm.

⚠️ 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.

The update instructions for SFOS 22 and 23 confirm automatic CA regeneration, but do not describe automatic reissuance or reassignment for every dependent certificate. Therefore, check the certificate actually served by each service and its chain; downloading the new CA alone does not prove that all services have already migrated to the new chain.

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. During planned rotation, old profiles may remain in distribution only for an approved, limited overlap while the old chain is verified valid and uncompromised; end that distribution no later than the successful migration of all users.

For suspected or confirmed compromise, the incident owner must approve containment and a cutoff. At that cutoff, withdraw old profiles from distribution and remove trust in the compromised old CA from affected clients and peers; do not wait for every user to migrate. An already expired chain does not permit this overlap either. If a validated, independent safe chain cannot be provided, stop the affected service and escalate to incident response or Sophos Support. Restoring the old compromised key does not restore secure service.

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.

Adding the new CA alongside the old one is permitted only for an approved, limited overlap with a verified valid, uncompromised old chain. For compromise, withdraw old peer trust at the incident-approved cutoff; do not continue operating on an expired old chain either. Without a validated safe replacement chain, stop the affected tunnel and escalate.

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.

A check mark under Trusted confirms only that the associated CA is installed on the firewall. It proves neither that external clients trust it nor that sign-in or application traffic works. Even if the subject remains unchanged, the old and new CAs have different fingerprints; do not rely on the name alone.

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.

Simply reimporting the old public CA on a peer or activating an old client profile does not restore the old CA key on the firewall either. A service recovery path works only if the certificate in use, its available private key, and the peers also match the approved old chain. If the CA key is compromised or the CA has expired, returning to the old trust chain is not safe normal operation; involve incident response or Sophos Support and use a safe alternative recovery path.

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 and only if the old chain is verified valid and uncompromised,
• use a full backup restore to return to the old chain only if that chain is verified valid and uncompromised and the effects, restart, SSMK, and loss of later changes are acceptable; otherwise use a validated, independent safe chain or stop the affected service and escalate,
• 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 certificate, selective CertificateAuthority export, backup, password, and SSMK are stored securely.
• 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