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 comes into play. In WeOS, revocation is implemented in the 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

• OpenVPN and logging can be configured to use static CRL distribution points (CRLDP).
• IPsec uses only CRLDPs defined in the incoming certificates.

Overview

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 certificates 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 the 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 is valid. If it is in the list, it is revoked and Alice should not trust Bob.

Depending on the service, WeOS allows for static CRLDPs that are predefined in the configuration, or dynamic CRLDPs listed in incoming certificates.

Static vs dynamic CRLDP

• Static CRLDP
• Admin-configured URLs.

• Available when using OpenVPN and logging services.

• Dynamic CRLDP

• URLs embedded in the peer certificate’s CRL Distribution Point extension.
• Currently only available for IPsec.
• Downloaded when starting the tunnel, cached for further use.

Static CRL Distribution Point

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.

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, the issuer of Bob’s certificate, is not present in Alice’s configuration she will not be able to download it and verify Bob’s revocation status. The same is true when validating any other certificate in the chain provided by Bob.

Dynamic CRL Distribution Point

Dynamic CRL checking is currently available only for IPsec tunnels and does not require any additional configuration. CRLs are downloaded after the peer’s certificate is received and the status is verified. The CRL is cached for any further verification until its expiration.

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 organisations to choose the appropriate trade-off between security and operational continuity.

Services in WeOS may provide different revocation policies such as disabled, relaxed or strict, allowing administrators to balance security and availability based on operational needs.

Table 1: Revocation Policy Support by Services

Where available, the 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, the 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

• OpenVPN
• Syslog, (both Source and Destination)
• IPsec