Certificates, signatures, and trust

A hybrid TLS key exchange protects session-key establishment. It does not establish that a website certificate, SSH host key, software update, or device boot signature uses post-quantum authentication. These systems need a separate inventory and migration plan.

A digital signature lets a verifier check an artifact or message against a trusted public key. The hard part of migration is often reaching every verifier, including older devices and recovery environments, before changing what the signer produces.

1. Map who signs and who verifies

Make a row in the readiness worksheet for each trust relationship, not merely each certificate file.

System	Signing side	Verification side and dependencies
Public HTTPS	Certificate authority and server authentication key	Browsers, OS trust stores, intermediates, revocation, certificate tooling.
Private PKI / mutual TLS	Private CA, service and client identities	Every client/server library, enrollment service, device, and recovery image.
Software or package updates	Release pipeline and signing service/HSM	Updater, package manager, offline verification, rollback policy.
Firmware / secure boot	Manufacturer or device-management signer	Boot ROM, hardware trust anchor, firmware parser, field-service recovery path.
Documents and archives	Document signer and timestamp services	Long-term validation software, historical trust material, preservation policy.

Record the algorithm, parameter set, signer version, key location, trust anchor, supported verifier versions, artifact lifetime, and owner. Keep private keys and signing credentials out of the inventory.

2. Collect read-only evidence

With an approved OpenSSL installation, inspect an exported public certificate:

# Inspect a public PEM certificate exported through your approved process.
# This reads metadata; it neither modifies the file nor validates the chain.
openssl x509 -in service-cert.pem -noout -text

Illustrative excerpt: the issuer's signature and the subject's public key can use different algorithms.

Signature Algorithm: sha256WithRSAEncryption
...
Subject Public Key Info:
    Public Key Algorithm: id-ecPublicKey

Here the certificate is signed with RSA while the subject has an elliptic-curve key. Neither becomes post-quantum because the server negotiates ML-KEM. Inspection also does not prove that a trust chain validates or that this is the certificate your service actually presents. See OpenSSL's certificate inspection reference.

For a software or firmware artifact, use its vendor's normal signature-verification command on a known release and retain the result, artifact digest, verifier version, algorithm, and trust source. An unsigned checksum detects changes only relative to a trusted expected digest; it is not a substitute for publisher authentication.

3. Separate algorithm availability from ecosystem support

ML-DSA and SLH-DSA are standardized signature schemes. Their publication does not mean every browser, certificate authority, HSM, bootloader, or document format can use them. Ask each dependency for its supported protocol, encoding, parameter set, and release.

Stateful hash-based systems need additional care. NIST SP 800-208 covers LMS/XMSS-family signatures. Reusing signing state can undermine security; ordinary VM snapshots, cloned signers, and backup restoration must not cause state reuse. Use the vendor's supported state-management design rather than building one from a sample script.

4. Design a migration pilot

Define the trust boundary. Choose a private test CA, staging update channel, or disposable device with documented recovery. Keep production trust anchors intact.
Upgrade verifiers first where required. Test new and existing artifacts with the complete client/version matrix, including offline and recovery modes.
Measure operational behavior. Check artifact/certificate sizes, parser limits, verification latency, HSM capacity, enrollment, renewal, revocation, and incident rotation.
Test negative cases. Modified content, an untrusted signer, expired or revoked identities, and an unsupported algorithm must fail according to policy.
Plan coexistence explicitly. If using dual signatures or parallel PKI, specify which signatures a verifier must require. Merely attaching a PQ signature is insufficient if acceptance still depends solely on a vulnerable alternative.

These are planning checks, not an instruction to replace a public certificate today. Public trust changes depend on the full WebPKI ecosystem; a private test succeeding is not proof of public-browser acceptance.

5. Prove recovery before rollout

Retain a vendor-supported recovery path and document how a failed signer or incompatible verifier is restored. A rollback must still enforce authenticity; avoid recovery modes that accept unsigned updates. For hardware with immutable verification code, establish whether replacement or an authenticated transition mechanism is required.

Define completion separately for issuing new signatures, verifying old artifacts, removing obsolete trust anchors, and covering long-lived devices. Record unresolved vendors, owners, and retest dates. Continue with stored data and key management and the vendor questionnaire.

Documentation reviewed 25 September 2026. Certificate output is illustrative; no CA, HSM, firmware, or signature product execution matrix is claimed.