PKI and certificate lifecycle

Summary. This page describes the CA hierarchy and the lifecycle of certificates, orders, and CA keys: request, order, approval, issuance, renewal, revocation, status distribution, offline root, and ceremonies. Every organization has its own hierarchy; the procedures are the same in every installation, regardless of the operating model.

• Root CA – the top CA, self-signed, permanently offline.
• Issuing CA – a CA of an organization or a partner, certified by the root; issues system certificates.
• CA generation – a CA with its own key; a key change creates a new generation.
• Profile template – a template maintained in the management application from which an order is created.
• Profile class – a category defined in the worker's rule set with binding rules (lifetime, extensions, approval rule, manual or automatic).
• CSR – a PKCS #10 certificate signing request, signed by the requester as proof of possession.

graph TD
  W[Root CA<br/>offline, HSM] --> C1[Issuing CA partner A<br/>nameConstraints: partner-a.example<br/>pathLen 0]
  W --> C2[Issuing CA partner B<br/>nameConstraints: partner-b.example<br/>pathLen 0]
  C1 --> S1[stock.partner-a.example]
  C1 --> S2[machine7.plant.partner-a.example]
  C2 --> S3[orders.partner-b.example]
  classDef off fill:#e1dfdd,stroke:#323130,color:#201f1e
  classDef ca fill:#fde7e9,stroke:#a4262c,color:#201f1e
  classDef ee fill:#deecf9,stroke:#0078d4,color:#201f1e
  class W off
  class C1,C2 ca
  class S1,S2,S3 ee

The content of a CA certificate is fixed in the root tool and cannot be configured freely: cA=TRUE, pathLenConstraint=0, keyUsage limited to keyCertSign and cRLSign, nameConstraints critical. Every tenant has at least one issuing CA of its own; no CA is shared between tenants. Each algorithm generation gets its own CA: a classical CA does not become hybrid after the fact but is replaced by a hybrid generation.

The following profiles show the structure with the default values. Parameter sets and lifetimes follow Cryptography and the post-quantum transition and the default values in Operations and emergencies.

A partner's issuing CA (hybrid)

Version:                 3
Serial number:           <from the root tool, at least 64 bits of randomness>
Signature algorithm:     ecdsa-with-SHA384 (1.2.840.10045.4.3.3)
Issuer:                  CN=<root CA>
Validity:                5 years (default)
Subject:                 CN=<CA name>, O=<tenant>
Public key:              EC P-384
Extensions:
  basicConstraints       critical: cA=TRUE, pathLenConstraint=0
  keyUsage               critical: keyCertSign, cRLSign
  nameConstraints        critical: permittedSubtrees dNSName=l.example
  subjectKeyIdentifier, authorityKeyIdentifier
  cRLDistributionPoints  URL of the root's CRL (distribution)
  authorityInfoAccess    caIssuers: URL of the root certificate (distribution)
  subjectAltPublicKeyInfo (2.5.29.72)  non-critical: ML-DSA-87, 2.16.840.1.101.3.4.3.19
  altSignatureAlgorithm   (2.5.29.73)  non-critical: ML-DSA-87, 2.16.840.1.101.3.4.3.19
  altSignatureValue       (2.5.29.74)  non-critical: the root's ML-DSA signature

System certificate

Version:                 3
Serial number:           <from the CA worker, at least 64 bits of randomness>
Signature algorithm:     ecdsa-with-SHA384
Issuer:                  CN=<CA name>, O=<tenant>
Validity:                30 days automatic, at most 1 year manual
Subject:                 CN=stock.l.example, O=<tenant, set by the worker>
Public key:              EC P-256 (generated by the system)
Extensions:
  basicConstraints       critical: cA=FALSE
  keyUsage               critical: digitalSignature
  extendedKeyUsage       serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)   per profile class
  subjectAltName         dNSName=stock.l.example                           exactly one
  subjectKeyIdentifier, authorityKeyIdentifier
  cRLDistributionPoints  URL of the CA's CRL
  authorityInfoAccess    caIssuers: URL of the CA certificate
  subjectAltPublicKeyInfo (2.5.29.72)  ML-DSA-65 (generated by the system)
  altSignatureAlgorithm   (2.5.29.73)  ML-DSA-87
  altSignatureValue       (2.5.29.74)  the CA's ML-DSA signature

Agent certificate. Key agents only verify each other; classical relying parties never see their certificates. An agent certificate is therefore a pure ML-DSA certificate per RFC 9881: subject key ML-DSA-65, the CA's signature with ML-DSA-87, subjectAltName with the host's DNS name, extendedKeyUsage with the identifier for key agents, a lifetime of 30 days with automatic renewal.

Effect of the name constraint. Under RFC 5280, the constraint dNSName=l.example permits the name l.example and every name formed by prepending further labels, such as stock.l.example or machine7.plant.l.example; l.example.attacker.example and xl.example are not permitted.

sequenceDiagram
  participant AS as Requester
  participant VE as Management or enrollment
  participant DB as Database
  participant FG as Approving person
  participant WK as CA worker
  participant RG as Ledger
  participant HS as HSM
  AS->>VE: CSR (proof of possession), profile template, DNS name
  VE->>VE: check CSR, resolve template,<br/>create order as JSON
  VE->>DB: order (bytes), hash
  FG->>DB: approval = signature over hash
  WK->>DB: read order and approvals
  WK->>WK: check against rule set
  WK->>RG: intent with serial number
  WK->>HS: sign TBS (ML-DSA, then classical)
  WK->>RG: result
  WK->>DB: projection of the certificate
  DB-->>AS: certificate via management or protocol

Mandatory content of an order: format identifier and version, order identifier, tenant, origin, correlation identifier, the requester's idempotency key, requester, issuing CA with fingerprint, profile class, profile template and version (informational), certificate type, public key (both for hybrid), CSR and its hash, subject, SAN list, complete extensions with criticality, signature algorithm, start and end of validity, required approval rule, creation time, expiry. Not in the order: the serial number.

The worker's checks: approval or attestation against the rule set; the rule is the one prescribed for the profile class (an order cannot pick a milder one); the CA is permitted and belongs to the tenant; proof of possession (for both keys if hybrid); the name lies within the namespace; only permitted extensions; lifetime; expiry; order not canceled; order not yet executed.

stateDiagram
  [*] --> pending_approval : order created
  pending_approval --> approval_complete : approvals submitted
  pending_approval --> canceled : cancellation
  approval_complete --> claimed : worker starts
  approval_complete --> canceled : cancellation
  claimed --> issued : result in the ledger
  claimed --> rejected : rule violation or maximum attempts
  pending_approval --> expired : deadline passed
  issued --> [*]
  rejected --> [*]
  canceled --> [*]
  expired --> [*]

pending_approval, approval_complete, and claimed are held in the database; issued and rejected are authoritative only in the ledger and are mirrored into the database. If a cancellation arrives too late, the certificate already issued is revoked. The state names are the values the management API returns.

A renewal is a new request with a new order; the old certificate remains valid until it expires. Automatic profile classes renew once only a third of the lifetime remains; the minimum lifetime is three days. Manual classes require a new approval.

stateDiagram
  [*] --> generated : in the HSM
  generated --> certified : ceremony
  certified --> active : enabled in the rule set
  active --> crl_only : remaining lifetime below longest profile lifetime
  crl_only --> retired : last issued certificate expired
  retired --> destroyed : ceremony
  active --> retired : compromise
  destroyed --> [*]

• Rollover: a new key is a new CA generation with a new certificate; the same key is never re-certified. The old generation only signs CRLs from then on.
• Backup: only through the HSM's own mechanism and under a multi-person rule.
• PIN: in the operating system's secret store on the worker host; ceremonies under quorum.
• Monitoring: the HSM's signature counters are reconciled against the ledger; a discrepancy is a suspected compromise.

sequenceDiagram
  participant L as Ceremony lead
  participant V as Custodians (quorum)
  participant Z as Witness
  participant R as Root (offline)
  participant K as Second channel
  L->>R: issuing CA's CSR (media)
  K->>L: key fingerprint and namespace,<br/>read at the worker host's console
  L->>L: compare CSR against second channel
  V->>R: activate root key
  R->>R: sign CA certificate with fixed content
  Z->>Z: countersign the record
  R->>L: CA certificate, root CRL,<br/>public part of the record

Lifetimes, quorums, ceremony schedule, and the nextUpdate of the root CRL are listed as default values on Operations and emergencies.

• Trust relationships between organizations; they are described in Federation and bilateral trust.
• OCSP. Status is published through CRLs that the TLS adapter fetches on a schedule.
• Personal certificates for people signing in to applications. TrustBridge identifies systems, services, and agents; personal approval keys serve approval only.