PKI, certificates, keys, and secrets
Plan how certificates, keys and secrets are issued, stored, renewed and removed. Assign ownership and recovery procedures for each part of the lifecycle.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.
On this page
Overview#
PKI is an operating system for trust, not a certificate generation task. A secure design defines issuance, identity proofing, trust distribution, storage, renewal, revocation, algorithm transition, backup, incident response, and decommissioning.
Trust inventory#
For every protected flow, record:
- certificate or key purpose: TLS server, TLS client, code signing, firmware signing, media/evidence signing, OSDP secure channel, API token signing, or data encryption;
- subject identity and uniqueness boundary;
- issuing authority and trust anchors;
- private key generation and storage location;
- supported algorithms, protocol versions, key usage, and name constraints;
- enrolment and renewal mechanism;
- revocation or distrust mechanism and offline behaviour;
- overlap window and rollback plan;
- evidence showing the active certificate/key on each endpoint.
TLS endpoint validation#
A client must validate the certificate chain, validity interval, intended key usage, and expected DNS/IP service identity. An encrypted session with an unverified peer protects only against passive observation; it doesn't establish whom the client reached. Never solve a deployment problem by installing a permanent accept all callback or disabling hostname verification.
TLS 1.3 is specified by RFC 8446; exact protocol and cipher policy still depends on device support, ecosystem requirements, and current organizational cryptographic guidance RFC 8446. Record when a legacy device forces weaker choices and isolate it rather than silently lowering the whole system baseline.
Key storage and handling#
- Generate private keys at the strongest practical boundary and mark them non exportable where supported.
- Use unique device and workload keys; shared fleet keys turn one compromise into systemic impersonation.
- Keep secrets out of source, Markdown, URLs, logs, screenshots, packet captures, support bundles, and command history.
- Give services access only to the specific secret version they require.
- Zero or release sensitive buffers according to the language/runtime and threat model.
- Separate encryption, signing, authentication, and key encryption purposes.
Renewal and failure#
Track certificate expiry as an operational signal with enough lead time for approval, rollout, and rollback. Test overlap of old and new trust anchors before removing the old one. Define behaviour when revocation information, enrolment services, or time sources are unavailable; insecure bypass must never be the automatic recovery mode.
Legacy shared key protocols#
Where a protocol uses pre shared keys, document provisioning, uniqueness, storage, rotation, loss, replacement, and downgrade behaviour. A label such as secure channel is incomplete without knowing which base key is installed, whether an installation/default key remains accepted, and how the peer is authenticated.
Sources#
- RFC 5280, RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, accessed 25 August 2026.
- RFC 8446, RFC 8446: The Transport Layer Security Protocol Version 1.3, accessed 25 August 2026.
- NIST TLS, NIST SP 800-52 Rev. 2: Guidelines for TLS Implementations, accessed 25 August 2026.