Certificate Revocation

Introduction

Secure communication relies heavily on digital certificates. These certificates validate the identity of devices and ensure encrypted data exchange. However, there are situations where a certificate must no longer be trusted—such as when a private key is compromised or a device is decommissioned. This is where certificate revocation come into play. In WeOS revocation is realized in form of Certificate Revocation List (CRL) checking.

A Certificate Revocation List is a digitally signed list, issued by a Certificate Authority (CA), that enumerates certificates that have been revoked before their scheduled expiration date. CRLs are a critical component of the Public Key Infrastructure (PKI) used in WeOS to maintain trust and security across the network.

Features

Periodically Updated: CRLs are updated at regular intervals to reflect the current status of certificates.
Locally Cached: After every restart WeOS routers cache CRLs in volatile memory to reduce lookup latency and maintain availability during network disruptions.
Used in Certificate Validation: During TLS handshakes or other secure operations, WeOS checks the CRL to ensure that the peer’s certificate is still valid.

Limitations

Only static CRL distribution points (CRLDP) can be defined.
Only OpenVPN and logging can be configured to do the CRL validation.

Overview

Let us consider the following scenario. Alice wants to communicate with Bob. Bob sends his certificate and a chain leading to Root-CA(i.e bob.pem, ca2.pem, root.pem) to Alice for verification.

                                   +-------------+                                  
                       publishes   |             |                                  
         root.crl <----------------+  Root-CA    |                                  
                                   |  (root.pem) |                                  
                                   +------|------+                                  
                                          |                                         
                                          | Root signs CA2                           
                                          |                                         
                                          |                                         
                                   +------v------+                                  
                        publishes  |   CA2       |                                  
           ca2.crl <---------------+  (ca2.pem)  |                                  
                                   |             |                                  
                                   +------|------+                                  
                                          |                                         
                                          | CA2 signs Bob's cert                    
                  (TLS handshake)         |                                         
                                          |                                         
+-------------+      alice.pem     +------v------+                                  
|             |-------------------->             |                                  
|    Alice    |                    |     Bob     |                                  
|             |  bob.pem + chain   |             |                                  
|             <---------------------             |                                  
+-------------+                    +-------------+

Figure 1: CRL in context of TLS handshake.

Alice trusts the Root-CA because she added root.pem into her own Local-CA Store. However when Bob presents his certificate to Alice during a TLS handshake, Alice needs to check if Bob’s certificate is still valid or if it has been revoked (invalidated before its expiration date).

CRLs are published periodically. The Root-CA publishes a root.crl (a list of revoked certificates it issued). CA2 (which is signed by Root-CA) publishes a ca2.crl (a list of revoked certificates it issued, including Bob’s if revoked). Both of these certificate are accessible from their respective CRL distribution points: http://crl.root.com/root.crl and http://crl.ca2.com/ca2.crl.

Alice downloads or has access to the latest ca2.crl. She verifies signature of ca2.crl and then looks for Bob’s certificate serial number in ca2.crl. If Bob’s certificate is not in the list, it’s valid. If it is in the list, it’s revoked and Alice should not trust Bob.

WeOS allows for predefining a list of static CRLDPs, i.e. URLs from where CRLs can be downloaded. Alice configuration should look like this:

alice:/#> configure
alice:/config/#> pki
alice:/config/pki/#> revocation 1
alice:/config/pki/revocation-1/#> show
Server #                      : 1
Label                         : revocation1
Description                   : CRL signed by Bob's cert issuer
URL                           : http://crl.ca2.com/ca2.crl
Protocol                      : CRL
Renewal threshold             : 80 %
alice:/#> end

alice:/#> revocation 2
alice:/config/pki/revocation-2/#> show
Server #                      : 2
Label                         : revocation2
Description                   : CRL signed Root-CA
URL                           : http://crl.root.com/root.crl
Protocol                      : CRL
Renewal threshold             : 80 %

After configuration the system downloads CRLs and keep them up-to-date. Other services in the system (e.g. OpenVPN tunnels) that rely on certificates can use these CRLs for revocation checking during TLS handshaking.

Configuration

WeOS allows only static CRLDPs, thus it is important that the Issuer of downloaded CRLs that signed the lists matches the issuer of end-entity certificate or any other certificate in the chain provided by the peer during TLS handshake.

In our example scenario, Alice will be able to verify the revocation status of bob.pem only if she adds http://crl.ca2.com/ca2.crl to her configuration. If the CRL issued by CA2, issuer of Bob’s certificate, is not present in Alice’s config she won’t be able to download it and verify Bob’s revocation status. The same is true while validating any other certificate in chain provided by Bob.

Note

Root-CAs are self-signed and thus inherently trusted and cannot be revoced. One need to be removed a self-signed certificate from the system to distrust it.

Security

The CRL distribution point could be targeted by attackers to disrupt the availability of distributed CRLs, making services relying on a CRL not work as expected.

Revocation Policies

Sometimes it might be desirable to accept a peer’s certificate even when the revocation status cannot be verified. This flexibility is important in environments where network connectivity to CRL distribution points is unreliable, or where continuous service is critical. This enables organizations to choose the appropriate trade-off between security and operational continuity.

Services in WeOS may provide different revocation policies. By default, revocation is disabled. Other policies if available in the service (e.g. tunnels), such as relaxed or strict, allow administrators to balance security and availability based on operational needs.

Service	Default Policy	Supported Policies	Notes
OpenVPN tunnel	disabled	disabled, relaxed, strict	Policy can be set per tunnel.
Logging	disabled	disabled, enabled	Applies to both source and destination logging configurations.
DDNS	N/A	N/A	Not supported

Table 1: Revocation Policy Support by Services

Where available, a strict policy will typically enforce immediate rejection of certificates if the CRL cannot be checked or is unavailable, maximizing security but potentially disrupting service if the CRL source is temporarily unreachable. In contrast, a relaxed policy may allow continued operation using cached or expired CRLs, prioritizing service availability even if revocation status cannot be confirmed in real time. Details are provided per service.

Configuration

Configuration of static CRLDPs is done in config context.

example:/#> configure pki revocation 1
Creating new revocation entry 1
example:/config/pki/revocation-1#> show
Server #                      : 1
Label                         : revocation1
Description                   :
URL                           :
Protocol                      : CRL
Renewal threshold             : 80 %

[no] label [NAME]

Assigns a label to the revocation configuration, which will be displayed in lists.

NAME: The name of the revocation configuration.
no: Resets the label to revocation#.

[no] description [STRING]

Adds a description to the revocation configuration, which will be displayed in lists.

STRING: A short description of the revocation configuration.
no: Resets the description to an empty string.

[no] url [STRING]

Specifies the URL of the CRL location. The URL consists of a scheme, subdomain, top-level domain, second-level domain, subdirectory, and port. Supported schemes are FTP, TFTP, HTTP, and HTTPS.

STRING: The URL of the CRL location.
no: Resets the URL to an empty string.

[no] protocol [crl]

Specifies the protocol for the revocation type.

[crl]: Currently, only CRL is supported.
no: Resets the protocol to the default, CRL.

[no] renewal-threshold <1-99>

Configures the threshold for renewing the CRL. The value is specified as a percentage of the CRL’s lifetime.

<1-99>: The threshold for renewing the CRL. The default value is 80 percent, meaning the CRL will start renewing when 80 percent of its lifetime has passed.
no: Resets the renewal threshold to the default value of 80 percent.

Services

By default, services in WeOS that support revocation are configured to don’t check revocation status. However the revocation can be enabled per Tunnel :

OpenVPN
Syslog, (both Source and Destination)