Day 12: Revocation — CRL, OCSP, and RevokeCertificate

Phase 5 · September 6, 2026

Agenda (2–3 hours)

• Read (45 min): ACM PCA User Guide — "Configuring a CRL"; "Using OCSP"
• Study (60 min): CRL vs. OCSP; revocation in a private PKI; the validity/revocation tradeoff
• Write (45 min): Design revocation policy for your provisioning service

Why Revocation Matters

You issue a certificate to a device. Later:

• The device is lost or stolen
• The device is decommissioned
• A private key is compromised
• The device's identity is determined to be fraudulent

You need to tell relying parties: this certificate is no longer valid.

Two mechanisms: CRL and OCSP.

Certificate Revocation List (CRL)

A CRL is a signed list of revoked certificate serial numbers,
published periodically to a well-known HTTPS URL:

CRL Structure:
- Issuer: CN=Leo Device Issuance CA
- This Update: 2026-09-06T00:00:00Z
- Next Update: 2026-09-13T00:00:00Z  ← CRL expires after 7 days
- Revoked Certificates:
    Serial 0x1a2b3c:  revoked 2026-09-01T12:00:00Z  reason=keyCompromise
    Serial 0xdeadbe:  revoked 2026-09-05T08:00:00Z  reason=cessationOfOperation

ACM PCA publishes CRLs to S3 automatically:

s3://acmpca-crl-bucket-<account>/crl/<ca-id>.crl

The CRL URL is embedded in the CRL Distribution Points extension of every issued cert.

Configuring CRL in ACM PCA

use aws_sdk_acmpca::types::{
    RevocationConfiguration, CrlConfiguration,
};

let revocation = RevocationConfiguration::builder()
    .crl_configuration(
        CrlConfiguration::builder()
            .enabled(true)
            .expiration_in_days(7)
            .s3_bucket_name("my-acmpca-crl-bucket")
            // Optional: custom CNAME for the CRL URL
            // .custom_cname("crl.leo.amazon.com")
            .build()?
    )
    .build();

// Pass to CreateCertificateAuthority or UpdateCertificateAuthority
client
    .create_certificate_authority()
    // ...
    .revocation_configuration(revocation)
    .send()
    .await?;

Online Certificate Status Protocol (OCSP)

OCSP provides real-time revocation status — no downloading a full CRL:

Client → OCSP Responder: "Is cert serial 0x1a2b3c valid?"
OCSP Responder → Client: "Status: GOOD / REVOKED / UNKNOWN"
                          Signed by OCSP responder certificate
                          Valid until: <timestamp>

ACM PCA can act as an OCSP responder. Configure it at CA creation:

let revocation = RevocationConfiguration::builder()
    .ocsp_configuration(
        OcspConfiguration::builder()
            .enabled(true)
            // Optional: custom OCSP responder endpoint
            // .ocsp_custom_cname("ocsp.leo.amazon.com")
            .build()
    )
    .build();

The OCSP URL is embedded in the Authority Info Access extension of issued certs.

CRL vs. OCSP: Comparison

For your provisioning service with short-lived certs (1-hour SVIDs or 90-day device certs):

• 1-hour SVIDs: revocation is largely moot (cert expires before CRL is checked)
• 90-day device certs: CRL is appropriate; OCSP adds real-time capability

RevokeCertificate API

use aws_sdk_acmpca::types::RevocationReason;

client
    .revoke_certificate()
    .certificate_authority_arn(ca_arn)
    .certificate_serial(serial_number)  // hex string: "1a:2b:3c:..."
    .revocation_reason(RevocationReason::KeyCompromise)
    .send()
    .await?;

println!("Certificate revoked. It will appear in the next CRL.");

After revocation:

• ACM PCA adds the serial to the next CRL
• The CRL is republished within minutes
• OCSP responder returns REVOKED immediately

Important: revocation requires the certificate serial number, not the ARN.
Your provisioning service must track (device_id → certificate_serial) in DynamoDB.

The Short-Lived Cert Alternative to Revocation

From Phase 4 (SPIFFE): short-lived certs solve many revocation problems:

Traditional (long-lived certs):
  Issue cert → compromise occurs → revoke cert → wait for CRL propagation
  Problem: CRL propagation delay = window of vulnerability

Short-lived (1-hour SVIDs):
  Issue cert → compromise occurs → cert expires in ≤ 1 hour
  Problem solved: no revocation needed for most cases

For your provisioning service:

• Device certs (90 days): revocation is important (devices can be lost)
• Service-to-service (SVIDs via SPIRE): use short TTL instead of revocation
• ACM PCA-issued long-lived certs: always configure CRL (defense-in-depth)

Challenge Assignment

Design a revocation policy for acm-pca-design.md §4:

## §4. Revocation + Audit

### 4.1 Revocation Mechanisms
<CRL vs. OCSP choice per cert type (device / service / SVID)>

### 4.2 CRL Configuration
<expiration_in_days, S3 bucket, custom CNAME (if any)>

### 4.3 Revocation Procedure
<How does an operator revoke a specific device certificate?
 What system call / API call? Who has IAM permission to do this?>

### 4.4 Serial Number Tracking
<Where does your provisioning service store device_id → cert_serial?
 DynamoDB table design?>

### 4.5 Short-Lived Cert Policy
<For which cert types does short validity replace revocation? Why?>

Resources

• ACM PCA CRL config: docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html
• ACM PCA OCSP: docs.aws.amazon.com/privateca/latest/userguide/ocsp-concept.html
• RevokeCertificate API: docs.aws.amazon.com/privateca/latest/APIReference/API_RevokeCertificate.html
• RFC 5280 §5: CRL structure
• RFC 6960: OCSP spec