8.2 Revocation & CRLs
Certificate revocation for private CAs, hosted by CertKit.
Every certificate issued by a private CA embeds a CRL Distribution Point — a URL where relying parties check whether the certificate has been revoked. CertKit builds, signs, and hosts a Certificate Revocation List for each issuing CA, so revocation works out of the box with no infrastructure on your side.
Certificates also embed an Authority Information Access URL serving the issuing CA’s own certificate, which lets clients complete the chain when a server presents an incomplete one.
Revoking a certificate
Revoke from the certificate’s page in the dashboard. Revocation takes effect immediately on the server: the serial number is added to the CA’s CRL and the CRL is re-signed in the same operation.
Revocation entries are independent of the certificate’s lifecycle in CertKit. A revoked serial remains on the CRL until the certificate’s natural expiry, even if you later delete the certificate definition.
CRL properties
| Property | Value |
|---|---|
| Format | DER, RFC 5280 |
| Signed by | The issuing CA |
Validity (nextUpdate) |
24 hours |
| Refresh | Re-signed automatically well before expiry, regardless of revocation activity |
An empty CRL is published the moment a CA is created, so the URL embedded in certificates never dangles.
Client behavior and propagation
Relying parties cache a CRL until its nextUpdate time. A client that fetched the CRL just before a revocation may therefore honor the revoked certificate for up to 24 hours. Environments that perform strict revocation checking — NPS/EAP-TLS, hardened mTLS configurations — reject the certificate as soon as they observe the updated CRL.
Endpoint notes
- CRL and AIA URLs are served over plain HTTP by design. Windows CryptoAPI does not retrieve CRL or AIA targets over HTTPS, and the CRL’s integrity comes from its signature, not the transport.
- The endpoints are anonymous. CRLs and CA certificates are public PKI material; the URLs use unguessable identifiers but require no authentication.
Rotation and previous CAs
When an issuing CA is rotated, the previous issuing CA continues to serve its CRL until every certificate it signed has expired. Certificates in the field keep pointing at the CRL of the CA that signed them, so revocation continues to work across rotations.
OCSP
Private CAs are CRL-only; CertKit does not operate an OCSP responder. For private trust, CRLs provide equivalent assurance without adding a latency-sensitive dependency to every TLS handshake.