Certificate Revocation Lists

Certificate Revocation Lists

A Certificate Revocation List (CRL) is a signed file from a Certificate Authority (CA) that names the certificates the CA has revoked before their normal expiry. Radiator Server reads CRLs and uses them during TLS handshakes to reject peers whose certificate has been revoked.

See certificates for the configuration reference.

When to Use a CRL

Use a CRL when you need to:

• Revoke a stolen or compromised client certificate before it expires.
• Stop accepting a deprovisioned RadSec proxy or RADIUS/TLS peer.
• Enforce a CA's revocation policy on EAP-TLS, PEAP, or TTLS clients.

Radiator Server reads local CRL files. Publish them on the server filesystem or upload them through the configuration file API.

How to Publish CRLs

Use a crl_directory when CRL files should refresh automatically:

certificates {
    crl_directory "ALL_CRLS" {
        directory "/etc/radiator/certs/crls";
        interval 1h;
    }
}

Radiator Server loads the directory at startup and rescans it on the configured interval. New, removed, and changed files are picked up without a configuration reload.

A crl_directory accepts .crl, .pem, and .der files and ignores other extensions. An empty directory is valid.

Use a single crl block when updates are applied through configuration loads:

certificates {
    crl "ISSUER_CRL" {
        filename "<root>/tls/crl/issuer.crl";
    }
}

The file is reread on each configuration load. For API-managed updates, upload the replacement, deploy it with POST /api/v1/configuration/pending/deploy, then activate it with POST /api/v1/configuration/load. See updating configuration for the file API workflow.

Repeat crl "NAME"; in a tls block to combine single-file and directory sources. Without a CRL reference, that block performs no revocation checks.

When CRL Changes Take Effect

CRL updates take effect when loaded:

Loading changed CRLs revalidates established peers using the changed source. Only peers rejected by the new CRLs and configured verification policy are disconnected; valid peers stay connected. Session resumption state is retired for dependent TLS blocks so new connections use the updated CRLs.

What Happens at Startup

When Radiator starts (or reloads the configuration), each CRL source is read from disk:

• A crl_directory source reads every accepted file. If a single file fails to open, is too big, or fails to parse, Radiator skips that file. The remaining files still load.
• A crl source reads one file. If the file is a PEM bundle that contains more than one CRL, Radiator keeps only the first CRL and logs a warning. Use crl_directory if you need multiple CRLs.

Loading CRLs does not emit freshness messages. Freshness is checked when the CRL participates in peer certificate verification.

What Happens on Every Refresh

Each directory refresh replaces the loaded CRL set if its contents changed. Changes are logged at Debug. Read failures keep the previous CRL set and are logged at Debug, promoted to Error.

If a refresh is still running at the next tick, that tick is skipped.

What Happens on a Handshake

Radiator Server checks the peer's certificate chain against the configured CRLs. A revoked certificate or unusable CRL rejects the handshake unless the configured AAA certificate-verification policy accepts the peer. Final rejections are logged at Debug, promoted to Warn; see TLS handshake rejected by CRL for rejection causes and fields.

allow_stale

A stale CRL (one whose nextUpdate has passed) cannot prove that a certificate is still valid. The default is to reject any peer whose chain depends on a stale CRL with expired_revocation_list.

Set allow_stale yes; on a crl or crl_directory block to relax this rule. With allow_stale yes, Radiator accepts peers when the CRL is past nextUpdate. Two properties to keep in mind:

• A revoked certificate that appears in a stale CRL is still rejected. Staleness and unknown revocation status are relaxed.
• The flag applies to the whole TLS block, not to one CRL. If any CRL referenced from a TLS block has allow_stale yes, every CA referenced from that TLS block is treated under the relaxed policy.

CRLs and AAA Pipelines

In setups that authenticate via an AAA pipeline (for example EAP-TLS with a custom verification policy), the AAA pipeline is the final authority on whether to accept the peer. If the CRL check rejects the certificate but the AAA pipeline accepts it, Radiator accepts the connection. This is intentional: an operator policy can override revocation.

Overrides are logged at Debug, promoted to Warn.

If you want CRLs to actually block revoked peers in this setup, the AAA pipeline must look at the certificate verification result and fail the policy when the certificate was revoked.

TLS Session Resumption

Resumed sessions skip certificate verification, but a loaded CRL change retires resumption state for every tls block that references the changed source. Old tickets and cached sessions cannot bypass the new revocation. Until the update is loaded, the previous CRL set remains active.

To require a full certificate check against the current CRL set on every connection, configure both settings in the tls block:

tls12_session_id_resumption false;
tls13_session_tickets 0;

Both forms of resumption are disabled by default for TLS listeners and EAP methods.

See server TLS - session resumption and CRL enforcement for details.

Operational Tips

• Pick an interval that matches the CA's CRL publishing cadence. Longer intervals delay revocation enforcement. See interval for syntax variants and context-specific support.
• Watch the CRL directory snapshot changed and TLS handshake rejected by CRL log lines and counters. They show that the refresh path and the revocation path work end to end.
• Refresh CRLs before their issuer's nextUpdate time. TLS verification reports a stale CRL when it rejects an affected peer.
• For multiple CRLs, reference several crl entries or use a crl_directory. A single-file PEM bundle keeps only the first CRL and logs a warning.

Related Pages

• certificates clause - configuration reference for crl, crl_directory, and allow_stale.
• server TLS - referencing CRLs from a server-side TLS block, and session resumption settings.
• Duration Units - syntax for the interval value.