Issuer
The CA identity signing a certificate.
Chapter 9 of 16 · Application/workload user · orders-api
Issue a short-lived service certificate, validate its identity and chain, install it atomically, and replace it before expiry.
Chapter 7 complete, the PKI role created by bootstrap, and OpenSSL installed.
orders-api can install and rotate a SAN-constrained certificate while keeping its private key opaque.
| Owner | Consumer-facing responsibility |
|---|---|
| You own | Defines consumption, validation, reload, and stop-using behavior. |
| Platform team owns | Provides trusted runtime identity, protected delivery, network, and telemetry. |
| Vault owns | Operates auth mounts, policies, engines, audit, and recovery. |
The CA identity signing a certificate.
Allowed names, key types, usages, and maximum TTL.
The identity names a verifier actually checks.
A complete swap that never exposes mismatched partial files.
source learn-vault/.runtime/learner.env
cd learn-vault/labs/pki
./issue.sh orders-api.lockbox.internal
./inspect.sh
./rotate.sh orders-api.lockbox.internal| Symptom | TLS fails after certificate rotation. |
|---|---|
| Likely causes | Cert and key swapped separately, SAN mismatch, untrusted issuer, expired chain, or reload failure. |
| Inspect safely | Compare fingerprint, SAN, issuer, validity, modes, and reload timestamp. |
| Do not print | Private key bytes, issuance response, or client credentials. |
Break it: Request a name outside the allowed lockbox.internal domain.
Fix it: Use the role-approved SAN and validate issuer, SAN, expiry, and key correspondence.
Escalate with time, endpoint, auth path, role, mount, namespace when relevant, status code, request ID, and sanitized error class. Never attach a credential or response body.
labs/bootstrap owns the disposable server, auth mounts, policies, roles, and engines; learner actions begin after setup.
$0; local containers only
Run labs/bootstrap/setup.sh and source .runtime/learner.env unless the chapter lab says AppRole alone is sufficient.
Issue to ignored storage, inspect public metadata, compare derived public-key digests, then rotate.
cd learn-vault/labs/pki
./issue.sh orders-api.lockbox.internal
./inspect.sh
./verify-pair.sh
old_serial=$(./serial.sh)
./rotate.sh orders-api.lockbox.internal
test "$old_serial" != "$(./serial.sh)"
./cleanup.sh
Complete every item in the Verify section using metadata-only evidence; no secret value appears in terminal output or tracked files.
Use the Failure drill and Break it / fix it evidence fields. Stop before broadening policy, weakening identity or TLS checks, or copying secret-bearing diagnostics.
Remove the runtime certificate directory. Use serial-based revocation when real incident policy requires it.
orders-api has a service identity with an explicit SAN, trust chain, and rotation deadline.
Modern TLS verification uses subject alternative names.
Compare digests of derived public keys.
Prepare complete files and rename within one filesystem.
No. High-risk compromise can still require it.
Short-lived PKI works when constraints, trust, atomic reload, and expiry telemetry are designed together.