← Week 2: ACM Private CA — architecture + API

Day 14: Week 2 Challenge — CA Hierarchy + Issuance Flow Design

Phase 5 · September 8, 2026

← Week 2: ACM Private CA — architecture + API

Agenda (3 hours)

  • Complete acm-pca-design.md §1–4 (CA hierarchy, templates, issuance flow, revocation + audit)
  • Code (60 min): Implement the full issuance round-trip in Rust
  • Review (30 min): Read §1–4 as if you were your tech lead
← Week 2: ACM Private CA — architecture + API

Week 2 Deliverable: acm-pca-design.md §1–4

acm-pca-design.md:
├── §0 Key Custody Model (Day 7) ✓
├── §1 CA Hierarchy Design (Day 8) ← complete today
├── §2 Certificate Templates (Day 10) ← complete today
├── §3 Issuance API Flow (Day 11) ← complete today
├── §4 Revocation + Audit (Day 12–13) ← complete today
├── §5 Failure Mode Analysis (Week 3, Day 15)
└── §6 Integration with Provisioning Service (Week 3, Day 20)
← Week 2: ACM Private CA — architecture + API

§1 Checklist: CA Hierarchy Design

  • [ ] Hierarchy diagram (3 tiers minimum)
  • [ ] For each CA: type (ROOT/SUBORDINATE), validity, subject DN, location (ACM PCA / offline)
  • [ ] Root CA activation decision: ACM PCA Root or offline HSM? Rationale written
  • [ ] Path length constraints specified
  • [ ] Cost estimate: number of CAs × ACM PCA price + monthly cert volume × $0.75
  • [ ] Blast radius analysis: what's the impact if the issuance CA is compromised?
← Week 2: ACM Private CA — architecture + API

§2 Checklist: Certificate Templates

  • [ ] Template table: cert type / template ARN / key usage / EKU / SAN type / validity
  • [ ] At minimum: device cert, service mTLS cert, SVID-like cert
  • [ ] APIPassthrough usage documented for URI SAN (SPIFFE)
  • [ ] CSR validation responsibility noted: ACM PCA doesn't validate subject identity
  • [ ] Short validity rationale for each cert type
← Week 2: ACM Private CA — architecture + API

§3 Checklist: Issuance API Flow

  • [ ] Sequence diagram (caller → provisioning service → ACM PCA → response)
  • [ ] IssueCertificate call with correct parameters (CA ARN, template, validity)
  • [ ] GetCertificate polling with exponential backoff
  • [ ] Idempotency token design (how is it derived? device ID + timestamp?)
  • [ ] Error handling: what happens when ACM PCA returns RequestInProgressException?
  • [ ] DynamoDB write: where does the provisioning service record the issued cert serial?
← Week 2: ACM Private CA — architecture + API

§4 Checklist: Revocation + Audit

  • [ ] CRL configured (expiration days, S3 bucket)
  • [ ] OCSP decision: enabled or not? Rationale
  • [ ] Revocation procedure: who can revoke? What IAM policy?
  • [ ] Serial tracking: DynamoDB table design (device_id → cert_serial)
  • [ ] Short-lived cert policy: which cert types rely on expiry instead of revocation?
  • [ ] Audit logging: CloudTrail + DynamoDB inventory + periodic audit report check
← Week 2: ACM Private CA — architecture + API

Code Exercise: End-to-End Issuance (Mock)

If you don't have ACM PCA access, implement with a mock:

// Mock the ACM PCA issuance flow using rcgen as a stand-in CA
pub struct MockAcmPca {
    ca_cert: rcgen::Certificate,
    ca_key: rcgen::KeyPair,
}

impl MockAcmPca {
    pub fn issue(&self, csr_pem: &str) -> anyhow::Result<String> {
        // Parse the CSR
        let csr = rcgen::CertificateSigningRequestParams::from_pem(csr_pem)?;

        // Issue a cert (this is the real ACM PCA logic, simplified)
        let cert = csr.signed_by(&self.ca_cert, &self.ca_key,
                                  &self.ca_key)?;
        Ok(cert.pem())
    }
}

This mock makes Days 11's code testable without AWS credentials.

← Week 2: ACM Private CA — architecture + API

Review Rubric for §1–4

Ask yourself:

  1. Could a new team member follow §3 to implement the provisioning service?
    (Is the API flow specific enough?)

  2. Could your security team approve §1 without additional questions?
    (Are the key custody decisions explained with rationale?)

  3. Could your on-call engineer follow §4 to revoke a compromised device cert?
    (Is the procedure step-by-step and actionable?)

  4. Is the cost estimate in §1 defensible in a design review?
    (CA count × price + cert volume × price)

If the answer to any is "no" — fill the gap now.

← Week 2: ACM Private CA — architecture + API

Preview: Week 3

Week 3 addresses the harder questions:

Week 2: How to build the happy path (hierarchy → issue → revoke → audit)
         ↓
Week 3: What happens when things break
         - CA unavailable? HSM failure? CRL expired?
         - Cross-account sharing? Multi-region DR?
         - SPIRE + ACM PCA integration?
         - PQC readiness for your CA?
         - Is ACM PCA the right choice vs. running your own CA?
← Week 2: ACM Private CA — architecture + API

Resources

  • Your notes from Days 8–13
  • ACM PCA architecture patterns: docs.aws.amazon.com/privateca/latest/userguide/ca-hierarchy.html
  • aws-sdk-acmpca Rust examples: docs.rs/aws-sdk-acmpca → client module
  • Phase 4, Day 11 (SPIRE CA options + ACM PCA UpstreamAuthority)