WeOS
5.29.0

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

Service | Static CRLDP | Dynamic CRLDP (from certificate) | Notes
--- | --- | --- | ---
OpenVPN tunnel | Supported | - | Configurable per tunnel.
Logging (Syslog) | Supported | - | Applies to both source and destination.
IPsec | - | Supported | Uses CRLDPs provided in incoming certificates only.
DDNS | - | - | Revocation not supported.

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

Configuration

When using static CRLDPs it is important that the issuer of downloaded CRLs matches the issuer of the end-entity certificate or any other certificate in the chain provided by the peer during the 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, 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.

Note

Root CAs are self-signed and thus inherently trusted and cannot be revoked. To distrust a self-signed certificate, it must be removed from the system.

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.

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

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
IPsec | relaxed | relaxed, strict | Policy can be set per tunnel, cannot be disabled

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

« Previous Next »