Managing Certificate Revocation and Expiration Cycles

In this lesson, you will learn how to design a robust validation mechanism to identify and reject compromised or expired device credentials using CRLs and OCSP responses.

The Problem of Trust Decay

Even with a solid Hardware Root of Trust and secure provisioning, a certificate’s validity can be compromised due to private key theft or premature lifecycle termination. If a device’s certificate is revoked, the system must detect this before allowing any further communication, as simple expiration checks are insufficient for immediate threat mitigation.

CRLs vs. OCSP

In resource-constrained IoT environments, you have two primary strategies for revocation checking:

1. Certificate Revocation Lists (CRLs): The CA publishes a signed list of revoked serial numbers.
   • Embedded Challenge: The list grows linearly over time. Fetching and storing a massive list on a microcontroller is often impractical.
2. Online Certificate Status Protocol (OCSP): A real-time request to the CA asking, "Is this specific serial number still valid?"
   • Embedded Challenge: It requires an active network round-trip during the TLS handshake, increasing latency and vulnerability to network-level denial-of-service.

Implementation Strategy

For many embedded devices, OCSP Stapling is the preferred middle ground. Instead of the device querying the CA, the server provides a time-stamped, CA-signed proof of validity during the TLS handshake. Your device validates this "stapled" response as part of the handshake:

// Pseudo-logic for validating an OCSP stapled response
if (tls_handshake_has_ocsp_staple(connection)) {
    if (verify_ocsp_signature(staple, trusted_ca_pubkey) == SUCCESS) {
        if (check_ocsp_status(staple) == REVOKED) {
            terminate_connection("Credential revoked by CA");
        }
    } else {
        terminate_connection("OCSP staple signature invalid");
    }
} else {
    // Fallback: If no staple, check expiration date locally
    if (is_expired(device_cert)) {
        terminate_connection("Credential expired");
    }
}

By verifying the stapled proof, the device offloads the heavy lifting to the server while maintaining a cryptographically verifiable assurance of the peer's current status without needing to store or parse massive revocation lists.

Key Takeaway: To maintain security in an evolving threat landscape, transition from simple expiration checks to real-time status validation using OCSP stapling to ensure compromised devices are invalidated immediately.