Day 31: Certificate Lifecycle — CSR, Issuance, Renewal, ACME

Phase 1 · June 13, 2026

Agenda (2–3 hours)

• Read (60 min): RFC 2986 (PKCS#10 CSR format); RFC 8555 §1–6 (ACME overview, accounts, orders)
• Study (45 min): CSR structure, issuance workflow, ACME protocol flow
• Practice (45 min): Generate a CSR and sign it with a local CA
• Challenge (30 min): Shell script for cert lifecycle

Certificate Signing Request (RFC 2986)

CertificationRequest ::= SEQUENCE {
    certificationRequestInfo  CertificationRequestInfo,
    signatureAlgorithm        AlgorithmIdentifier,
    signature                 BIT STRING
}

CertificationRequestInfo ::= SEQUENCE {
    version     INTEGER { v1(0) },
    subject     Name,
    subjectPKInfo SubjectPublicKeyInfo,   -- the new public key
    attributes  [0] IMPLICIT Attributes  -- optional, e.g., SANs as extensions
}

The CSR signature proves the applicant possesses the corresponding private key.
The CA does not implicitly trust the subject DN in the CSR — it validates separately.

CSR: What the CA Actually Uses

A CA typically uses from the CSR:

• Public key (mandatory — this is the whole point)
• Subject DN (often overridden by CA's own validation)
• Extension requests (SANs from the extensionRequest attribute)

A CA typically ignores or overrides:

• CN if it's a domain cert (SAN is authoritative)
• Requested validity periods
• Any extensions the CA's policy doesn't allow

Don't assume the issued cert matches the CSR exactly — always inspect the issued cert.

Certificate Issuance Workflow

1. Applicant generates private key (stays with applicant, never leaves)
2. Applicant generates CSR with public key + requested subject/SANs
3. Applicant submits CSR to CA with proof of identity/domain control
4. CA validates: domain control (DV), organization (OV), or extended (EV)
5. CA issues cert: signs TBSCertificate with CA private key
6. CA logs cert to CT logs (for public trust)
7. CA returns cert to applicant

For device provisioning: steps 3-4 are replaced by device identity verification
(TPM attestation, IMEI validation, hardware token, etc.).

ACME Protocol (RFC 8555): Let's Encrypt Style

Client                              ACME Server (CA)
  │── newAccount (JWK) ────────────►│
  │◄── Account URL ─────────────────│
  │── newOrder (identifiers) ────────►│
  │◄── Order URL + authorizations ──│
  │── fulfill challenge (HTTP-01/DNS-01) ──[on public web/DNS]
  │── POST /challenge (ready) ──────►│
  │◄── authorization valid ──────────│
  │── POST /finalize (CSR) ──────────►│
  │◄── Order processing ─────────────│
  │── GET /certificate ──────────────►│
  │◄── PEM cert chain ──────────────│

Challenge Assignment

Write a shell script cert_lifecycle.sh that:

1. Generates an EC private key (P-256)
2. Creates a CSR with: subject CN=test.example.local, SAN dNSName: test.example.local
3. Signs the CSR with a local CA (from Day 15)
4. Verifies the issued cert's subject, SAN, and expiry
5. "Revokes" the cert by adding its serial to a CRL signed by the CA
6. Verifies that openssl verify -crl_check now rejects the cert

Document each step's output in comments. This is your reference script for cert lifecycle operations.

Resources

• RFC 2986: PKCS#10 CSR format
• RFC 8555: ACME protocol (Automated Certificate Management Environment)
• openssl-req(1), openssl-ca(1) man pages
• Let's Encrypt staging ACME server (for real ACME testing without rate limits)