Chapitre 7 sur 8

Running your own certificate authority

Two-tier design, key ceremonies, policy, and decommissioning a CA responsibly.

Environ 12 minutes de lecture

À la fin de ce chapitre, vous saurez

  • Design a two-tier private CA
  • Describe what a key ceremony must record
  • Explain the role of an HSM and of a certificate policy
  • Plan for retirement of a CA without breaking clients

Dans ce chapitre

  1. 1. Why private CAs exist
  2. 2. Two tiers, and why the root stays offline
  3. 3. The key ceremony
  4. 4. Operating and retiring

01Why private CAs exist

Public CAs will not issue certificates for internal names such as db01.corp.internal, and they should not: public trust is for names the public can verify. Internal services, devices and staff identities need a CA you control.

The trade-off is stark. You gain control and flexibility, and you take on the full operational burden: key custody, issuance policy, revocation availability and eventually retirement.

02Two tiers, and why the root stays offline

  1. 1

    Offline root CA

    Long-lived, powered down, kept in a safe or HSM. Signs only the issuing CA certificates and CRLs.

  2. 2

    Issuing CA

    Online and domain-integrated. Signs the certificates your services use every day.

  3. 3

    Policy and templates

    Define which names may be issued, which key usages are allowed, and who may request what.

  4. 4

    Revocation publishing

    CRLs and OCSP responses are served from infrastructure that must stay reachable for the certificate lifetime.

03The key ceremony

A ceremony is the documented process of creating or activating a CA key. It exists so that later you can prove what happened, in front of whom, on which hardware.

  • Named participants and their roles, with at least two people present
  • Hardware serial numbers and firmware versions
  • Approved scripts only, with any deviation recorded and justified
  • Backup and restore procedure for the key, including where copies are held
  • Signed record of the public key and certificate produced, verified independently
  • Storage location, tamper evidence and access log for the offline root

04Operating and retiring

  • Inventory every issued certificate with owner, purpose and expiry
  • Monitor expiry and revocation infrastructure availability, not just the CA service
  • Log issuance and review it for unexpected subjects, templates or requesters
  • When retiring a CA, publish revocation data until the last certificate it issued has expired
  • Document trust anchors so the next team can operate what you built

Retirement is the step teams forget. If you switch off a CA while certificates it issued are still in use, clients that check revocation will start failing, and you will have turned a planned migration into an outage.

À retenir

  • Private CAs exist for internal names and identities you control
  • Two tiers separate the rarely used root from the busy issuing CA
  • Key ceremonies create evidence: who, what, where, and with which hardware
  • Retirement requires keeping revocation data alive until the last certificate expires
PrécédentRevocation: undoing trust earlySuivantPKI in practice

Approfondir :PKI Trust Manager admin guidePKI Trust Manager MSCA API reference