Post-Quantum Cryptography
Red Hat Certificate System
The enterprise private Certificate Authority (CA) and public-key infrastructure (PKI) framework that anchors digital trust across hybrid cloud environments — a feature-by-feature look at Red Hat Certificate System's PQC readiness, constraints, and roadmap.
For threat model definitions — Harvest Now, Decrypt Later and Quantum Forgery — and status definitions, see Post-Quantum Cryptography at Red Hat.
PQC overview
Red Hat Certificate System (RHCS) serves as a critical enterprise-grade framework acting as a private Certificate Authority (CA) to manage digital identities, issue and revoke cryptographic certificates, and handle public-key infrastructure (PKI) operations across hybrid cloud environments. As a core trust anchor, RHCS requires a comprehensive Post-Quantum Cryptography (PQC) strategy to protect against quantum forgery and retroactive decryption threats. This assessment covers RHCS in its delivery of pure post-quantum algorithms for certificate management, key recovery, and status validation.
Scope
|
In-scope components
|
Out-of-scope (quantum-resistant)
|
Constraints
Phased delivery timeline
Red Hat Certificate System follows a staged rollout. RHCS 11.0, released in July 2026 alongside RHEL 10.2, introduced native support for all parameter sets of the ML-DSA digital signature algorithm (FIPS 204), enabling pure ML-DSA for CA signing and OCSP responses. RHCS 11.0.1, released in August 2026, completes the PQC suite by adding ML-KEM (FIPS 203) for quantum-resistant key encapsulation in the Key Recovery Authority alongside ML-DSA for signing. Automated lifecycle transitions for post-quantum certificates remain under active development and are the only forward-looking item in this assessment.
Dual certificate chain mandate
RHCS implements a dual-certificate issuance and verification model (issuing parallel classical RSA/ECC and modern PQC ML-DSA chains), allowing modern RHEL 10 clients to establish quantum-safe verification pathways while preserving full backward compatibility for legacy RHEL 8 and RHEL 9 nodes.
Threat: Harvest Now, Decrypt Later (HNDL)
At-a-glance PQC status for each RHCS capability against passive data-harvesting attacks. Expand any capability below the table for notes and references.
| Capability | Status | Min. version | Risk |
|---|---|---|---|
| Key recovery authority (KRA) storage | PQ-Capable | RHCS 11.0.1 | Critical |
| Certificate enrollment & lifecycles (EST) Certificate Signing Requests (CSRs) |
PQ-Capable | RHCS 11.0 | High |
| TLS | PQ-Capable | RHCS 11.0 | High |
| Automated Lifecycle Transitions & Zero-Touch Provisioning | Under active development | — | High |
Notes & references
▸ Key recovery authority (KRA) storage
Encrypted key escrow and archived secrets can be intercepted via HNDL attacks and retroactively decrypted once a CRQC goes online, exposing historical private keys. RHCS 11.0.1 (August 2026) integrates ML-KEM-512/768/1024 for KRA storage and transport key encapsulation. Private keys in the KRA vault are encrypted using quantum-resistant KEM (FIPS 203).
▸ Certificate enrollment & lifecycles (EST) — Certificate Signing Requests (CSRs)
Session handshakes are vulnerable to network sniffing and passive data harvesting, allowing future retroactive decryption of enrollment credentials and private metadata. EST (RFC7030) has been fundamentally updated to support the automation and lifecycles of PQC certs. RHCS 11.0 can receive, parse, and process enrollment requests containing PQ public keys.
Red Hat Enterprise Linux 10.2 and 9.8 are here: The intelligent evolution of enterprise Linux
▸ TLS
Session handshakes are vulnerable to network sniffing and passive data harvesting, allowing future retroactive decryption of enrollment credentials and private metadata. EST relies entirely on TLS for channel encryption and client/server authentication, so RHCS 11.0 leverages the underlying RHEL 10.2 network stack. The EST endpoint natively supports ML-KEM for the initial TLS handshake; this prevents the HNDL threat of EST cert enrollment traffic in transit.
▸ Automated Lifecycle Transitions & Zero-Touch Provisioning
Session handshakes are vulnerable to network sniffing and passive data harvesting, allowing future retroactive decryption of enrollment credentials and private metadata. Hybrid Lifecycles: RHCS will allow admins to use existing, legacy authenticated EST tunnels to request and enroll the machine's first new PQ ML-DSA cert. Once enrolled, the device can use that PQC cert for its subsequent automated renewals.
Threat: Quantum Forgery
At-a-glance PQC status for each RHCS capability against signature-forgery attacks. Expand any capability below the table for notes and references.
| Capability | Status | Min. version | Risk |
|---|---|---|---|
| Certificate authority (CA) signing | PQ-Capable | RHCS 11.0 | Critical |
| OCSP response signing | PQ-Capable | RHCS 11.0 | High |
Notes & references
▸ Certificate authority (CA) signing
Attackers with a CRQC can execute quantum signature forgery to issue counterfeit certificates, completely undermining the root of trust across private and public infrastructure. RHCS 11.0 supports ML-DSA for signing operations. Crypto libraries OpenSSL, GnuTLS, NSS support creating private CAs and signing CSRs using ML-DSA.
What's new in post-quantum cryptography in RHEL 10.1
Red Hat Enterprise Linux 10.2 and 9.8 are here: The intelligent evolution of enterprise Linux
▸ OCSP response signing
Adversaries can forge status validation responses, tricking systems into trusting revoked or malicious certificates, breaking real-time revocation checking controls. Because RHCS 11.0 natively supports ML-DSA, the OCSP subsystem can be configured to use an ML-DSA signing certificate. When a client queries the revocation status of a cert, the RHCS OCSP responder can cryptographically sign the OCSP response payload using quantum-resistant ML-DSA. Note: an OCSP responder's signing key must match (or complement) the algorithm family of the cert it is verifying to ensure the client can parse the response — if your RHCS CA issues ML-DSA certs to end-entities, the OCSP responder must sign its responses with ML-DSA.
