Import CRLs and revoke certificates on Sophos Firewall

Import an external Certificate Revocation List (CRL) under Certificates > Certificate revocation lists > Add. The file must come from the CA that issued the affected certificate. Before uploading it, check the issuer, signature, thisUpdate, nextUpdate, and revoked serial numbers. A visible list entry is not sufficient proof afterward: Test the actual service with a valid certificate and, in a controlled test environment, with a revoked certificate.

The process is different for locally signed certificates. SFOS can revoke these itself and automatically adds their details to the local CRL. An externally signed certificate, however, must be revoked by the external CA; the firewall cannot create that revocation itself.

Import a CRL in eight steps

1. Document the affected certificate, issuer, serial number, and firewall service using it.
2. Prepare a backup, independent management access, and a valid replacement certificate.
3. Obtain a current complete CRL from the issuing CA. Do not use a CRL from another CA with a similar name.
4. On an admin computer, read the file as DER or PEM and check the issuer, signature, thisUpdate, and nextUpdate.
5. Confirm that the associated CA chain is present under Certificates > Certificate authorities.
6. Under Certificates > Certificate revocation lists > Add, enter a clear name, select the CRL file, and click Save.
7. Perform a normal positive test with a certificate that remains valid and a controlled negative test with a revoked test certificate.
8. Document the owner, source, and renewal date before nextUpdate.

⚠️ Do not revoke a certificate assigned to production or the Default CA merely to test the feature. WebAdmin, portals, VPN, or other management services and tunnels could fail. First test revocation with a certificate issued specifically for this purpose and with a confirmed recovery path.

Distinguish expiry from revocation

A certificate may remain valid for months and still no longer be trustworthy. This can happen when its private key has been compromised, its holder has lost authorization, or the certificate may no longer be used for its original purpose. The CA then revokes the serial number and publishes this status in a CRL.

A CRL includes, among other things:

• the Issuer, meaning the entity that signed the CRL;
• thisUpdate, the issue time of this list;
• nextUpdate, the latest time by which the CA announces a new list;
• the serial number and revocation time of revoked certificates;
• a digital signature for verifying its origin and integrity.

The filename alone has no trust value. A file named vpn-current.crl may be outdated or belong to a different issuing CA. The issuer, signature, freshness, and serial number of the actual certificate are what matter.

Locally or externally signed

SFOS separates two responsibilities:

• Locally signed certificate: The firewall signed the certificate with its internal CA. It can be revoked under Certificates > Certificates. SFOS automatically adds the revocation to the corresponding local CRL.
• Externally signed certificate: An external enterprise or public CA issued the certificate. Only that CA can publish the revocation. The current CRL is then uploaded to the firewall as a file.

An externally supplied CRL does not replace the associated CA chain. The certificate, issuing CA, possible intermediate CAs, and CRL must match. Import and assign certificates on Sophos Firewall explains how to distinguish certificates, private keys, CSRs, and CA chains.

Prepare the CRL file safely

Record the current state before making a change:

• name, issuer, and serial number of the affected certificate;
• CRL issuer and trusted source;
• current thisUpdate and nextUpdate;
• affected service and its working positive test;
• responsible PKI owner;
• backup and recovery path if certificate validation blocks production access.

The firewall time must be correct. An incorrect date can make certificates and revocation lists appear outdated or not yet valid. If necessary, verify the time source and NTP configuration with Configure Sophos Firewall system time and NTP.

Match the certificate and CRL

On an admin computer, OpenSSL shows the issuer and serial number of a PEM certificate:

openssl x509 -in client-cert.pem -issuer -serial -noout

Replace client-cert.pem with the local certificate file. The command only reads metadata and does not display a private key.

Inspect a DER-encoded CRL as follows:

openssl crl -in corp-issuing-ca.crl -inform DER -issuer -lastupdate -nextupdate -crlnumber -noout

For a PEM-encoded CRL, replace DER with PEM. corp-issuing-ca.crl is an example name and must be replaced with the file from the local issuing CA. The displayed issuer must match the intended certificate chain, and nextUpdate must not already have passed for the planned operating period.

Verify the signature and revoked serial numbers

Verify the signature against a prepared CA file:

openssl crl -in corp-issuing-ca.crl -inform DER -CAfile corp-ca-chain.pem -verify -noout

corp-ca-chain.pem contains the CRL signer’s certificate and the CA chain required to verify it. The PKI owner provides this file; it is not assembled from an arbitrary download source. If the CA provides a PEM CRL, replace DER with PEM here as well.

To display full CRL details, including revoked serial numbers, use:

openssl crl -in corp-issuing-ca.crl -inform DER -text -noout

The output can be long for large enterprise CAs. It contains no private key, but it does contain internal PKI metadata and serial numbers. Do not paste the unfiltered output into public tickets, chats, or screenshots.

Import an external CRL into SFOS

Only obtain an external CRL from the responsible CA or its trusted PKI process. A file from an old ticket or an undocumented file share is not a reliable source.

1. Open Certificates > Certificate revocation lists.
2. Select Add.
3. Enter a clear name, such as Corp-Issuing-CA-CRL.
4. Select the previously verified .crl file.
5. Click Save.
6. Confirm that the new entry appears in the CRL list.
7. Run the planned positive and negative tests for the affected service.
8. Record nextUpdate, the owner, and the source in the operations documentation.

Corp-Issuing-CA-CRL is only an example name. Replace it with a name that identifies the actual issuing CA and purpose. Avoid names such as Current or New CRL, because after a few months they no longer reveal a clear owner.

The current SFOS 22 help does not document automatic retrieval from an HTTP or LDAP URL on this page. A one-time upload is therefore not a permanent operating process. Before nextUpdate, obtain a new list from the CA, verify it again, and update it on SFOS through the approved CRL process. Do not remove the previous list until the new file has been accepted and the affected service has been tested again.

Revoke a locally signed certificate

A locally signed certificate is revoked directly on the firewall. First determine whether it still protects WebAdmin, a portal, VPN, WAF, SMTP, or another service. If it does, assign and test a valid replacement certificate first.

1. Under Certificates > Certificates, identify the locally signed certificate.
2. Recheck its subject, issuer, purpose, and service assignment.
3. Confirm the backup and independent management access.
4. In the certificate row, run the revoke action for exactly this certificate.
5. Under Certificates > Certificate revocation lists, find the CRL for the associated local CA.
6. Select Download. SFOS supplies a .tar archive from which the .crl file is extracted.
7. Read the downloaded CRL with OpenSSL and compare the test certificate’s serial number.
8. Retest the actual service positively and negatively.

Sophos permits this direct revocation only for locally signed certificates. If the revoke action is unavailable for an external certificate, this is not a UI fault. The external CA must revoke the certificate and issue an updated CRL.

Verify the effect of the revocation list

A successful upload confirms only that SFOS accepted the file. It does not by itself prove that the intended service evaluates the CRL in its specific authentication path. A reliable acceptance test therefore has several layers:

1. File: Issuer, signature, thisUpdate, nextUpdate, and serial number are correct.
2. SFOS list: The expected CRL entry is visible after saving.
3. Positive test: A certificate that remains valid from the intended trust chain works.
4. Negative test: A test certificate issued and revoked for this purpose is rejected during a maintenance window.
5. Service log: Time, certificate, and rejection reason match the test.
6. Operations: After a CRL update and after a planned HA failover, establish and test a new connection again.

The correct log depends on the service. For certificate-based IPsec, charon.log is an important lead; the complete VPN workflow is in Sophos Firewall IPsec VPN troubleshooting. Other functions use other logs. Map Sophos Firewall service logs correctly maps these functions to access_server.log, sslvpn.log, csc.log, and other files.

A packet capture can show connection establishment and termination, but it does not automatically prove a CRL decision. For this purpose, the service log, certificate data, and controlled test case are more important.

Keep CRLs current in operations

A CRL needs an owner and a renewal process. Especially with an external CA, updates must not depend on one person’s memory.

Useful operational records include:

• responsible PKI or firewall team;
• exact CA and trusted source;
• expected update interval;
• nextUpdate of the currently imported list;
• affected firewall services and test cases;
• last successful positive and negative test;
• procedure for an unscheduled revocation after a key compromise.

After an urgent certificate revocation, do not wait for the normal review date. The external CA supplies an updated CRL, which is verified, imported, and tested on the affected service. Before changing production certificates, keep a current firewall backup with a verified recovery path.

In an HA cluster, do not infer identical runtime behavior merely from a visible entry on both nodes. After a planned failover, establish a new connection and inspect the log on the node that actually processed the test.

Troubleshoot errors systematically

SFOS rejects the CRL file

First check on the admin computer whether the file is actually a CRL and whether it is DER- or PEM-encoded. A renamed certificate, an HTML download of a portal error page, or a damaged archive is not a valid revocation list. Then check the issuer, signature, and CA chain.

Do not convert the file using online converters or unknown websites. If another format is required, convert it locally with OpenSSL or ask the CA to supply the CRL again in the required format.

The import works, but so does the revoked certificate

Check these points in order:

• Do the certificate and CRL really come from the same issuing CA?
• Is the certificate serial number present in the CRL?
• Is the CRL current, or is nextUpdate already in the past?
• Is the firewall time correct?
• Does the test actually use the expected certificate rather than another certificate from a cache, profile, or service assignment?
• Was a new connection established, or was an existing session simply continued?
• Does the service-specific log show certificate or revocation validation?

If any of these fundamentals are missing, do not experiment with service restarts or changes to the Default CA. First prove the CA, serial number, current CRL, and actual connection path.

An external certificate cannot be revoked on SFOS

This is the expected product boundary. The firewall can only revoke locally signed certificates itself. For an externally signed certificate, trigger revocation at the external CA and then import its new CRL.

A service fails after local revocation

First use the prepared management or console access. Assign a previously verified valid replacement certificate to the affected service. Do not plan to reuse the revoked certificate as a production solution. Then recheck the service, logs, and the certificate actually presented.

If it is unclear which services depend on the CA or CRL, do not revoke more certificates or delete revocation lists. Instead, save the configuration, certificate assignments, and support data and investigate the case with the PKI owners or Sophos Support.

FAQ