Design PKI and certificate automation
Design the internal certificate authority and automation that issues millions of short-lived certificates to services, devices and people, with an offline root, online issuing CAs, transparency, revocation and monitoring that prevents the classic expiry outage.
01Understand the problem
- Design a two-tier hierarchy with an offline root and purpose-constrained issuing CAs
- Automate issuance with SPIFFE, ACME and MDM enrolment for three very different consumers
- Size the system and choose short lifetimes over revocation where you can
- Monitor so that expiry and mis-issuance are caught by alerts, not by outages
What they probe: why the root is offline, how issuing CAs are constrained, how a workload proves it deserves a certificate, what happens when an issuing CA is compromised or its HSM is down, and how you avoid the classic expiry outage. Where candidates slip: one online root, year-long certificates renewed by a calendar reminder, copying extensions straight from the CSR, revocation as the only compromise story.
A quick vocabulary before the design. A certificate authority (CA) signs certificates that bind a public key to a name. A leaf certificate belongs to an end entity (a service, a laptop); the chain runs leaf → issuing CA → root, and a client trusts the leaf because it holds the root in its trust bundle. Names live in the SAN (subject alternative name) extension: DNS names, URIs, IP addresses. EKU (extended key usage) says what the key may do (serverAuth, clientAuth). Name constraints on a CA limit which names it may issue for. CRL (certificate revocation list) and OCSP (online certificate status protocol) are the two ways to tell clients a certificate is no longer valid before it expires.
Functional requirements
- Issue certificates to workloads (service-to-service mTLS), devices (laptops, EDR agents) and internal web services.
- Lifetimes: workloads 24 h, devices 30 d, internal web 90 d; all renewed automatically with no human step.
- A team can only obtain certificates for names it owns.
- Every issuance is logged and monitorable; revocation is available for the long-lived classes.
- Compromise of any single online component must not require rebuilding trust from scratch.
Non-functional requirements
Issuance availability 99.95 % (an issuer outage longer than the renewal runway becomes a fleet-wide mTLS outage); p99 issuance under 500 ms so pod start-up is not delayed; CA private keys never exist outside an HSM; trust bundle changes reach the whole fleet within 24 h.
This is an advanced module
Design problems: Infrastructure & data is part of the Pro pass. 6 more sections — the deep dives, the final design, follow-ups and the test — unlock with it.
Already a cyart.io or studio.cyart.io member? Your pass code is in your Studio account.