The TLS and X.509 certificate infrastructure is entering a new era – the post-quantum era. NIST algorithms (ML-KEM and ML-DSA) and hybrid certificates are changing the way we generate keys, create CSR, and perform the TLS handshake. A previously simple CSR is now becoming a critical element: it must comply with the new CA/B Forum requirements, support modern algorithms, and ensure correct ASN.1, SPKI, extension, and composite structure encoding.

In practice, this means that hybrid certificates combine a classical key (ECDSA/RSA) with a post-quantum one, and the TLS handshake generates two independent cryptographic secrets combined into a single shared session key. This provides resistance to future quantum attacks while maintaining full compatibility with today’s clients. However, it requires upgrading libraries to OpenSSL 3.x, preparing DevOps/ACME environments, and verifying whether the infrastructure can handle larger DER and SPKI structures.

In the coming years, PQC-ready certificates will become a global standard. Companies that prepare now – by testing hybrid certificates, modernizing TLS libraries, and updating automation processes – will avoid the risk of their environment becoming non-compliant with the new requirements of the internet.

Fundamentals of X.509 and the origins of the trust infrastructure.

When the TLS protocol was born in the 1990s, few people predicted that it would become the foundation of the entire digital economy. At that time, the internet was growing dynamically, but its structure was completely different than today: few dynamic applications, no mass virtualization, no cloud, and most websites were static, without the need for encryption. The first versions of SSL were created under the assumption that their main role would be to ensure confidentiality of communication between the browser and the web server. The structure of the X.509 certificate, adopted from earlier systems, was conservative and hierarchical: one public key, one signature, and trust built through a certificate chain whose superior element was the root CA. Despite this, the foundations created then proved surprisingly durable. X.509, in practically unchanged form, survived for over three decades – until 2025.

The essence of this durability lay in structural simplicity. The X.509 certificate was an ASN.1 object in which the subjectPublicKeyInfo field described exactly one algorithm and the public key it provided. This field, marked as a sequence, contained an algorithm identifier in the form of an OID and a raw public key encoded as a BIT STRING. In the 1990s, the algorithm identifier referred exclusively to RSA, because there was no real need to support anything else. RSA dominated because it represented a natural combination of security and ease of implementation: relatively simple mathematics, a clear security level resulting from the difficulty of factorization, and wide adoption in library implementations. As a result, the X.509 certificate became a single-algorithm format not because it was a conscious architectural choice, but because no one expected the need to place more than one key inside it.

The following decade brought dynamic internet development, but did not change the fundamental TLS architecture. The popularization of e-commerce, online banking, and SaaS services made SSL certificates indispensable, yet the certificate format itself remained static. Even the introduction of elliptic curves did not change its underlying structure: the SPKI field still stored a single public key. Changing the algorithm essentially consisted of replacing the OID and encoding a different BIT STRING, but the document’s structure remained unchanged. The ecosystem was evolving, but its foundations were inseparably tied to assumptions made before the cloud, IoT, and mobile internet era.

The problem that grew over the years was that X.509 – while solid – was not designed with resistance to an entirely new class of threats in mind. Quantum computers once existed only as theoretical constructs. Mathematicians and cryptographers knew that they could one day break RSA and ECDSA, but it had no practical significance. Only after the publication of concrete results relating to implementations of Shor’s algorithm on increasingly larger registers did people begin to understand that the threat was real. And if it is real, then every certificate issued today may become useless in the future. Worse, even if a quantum computer cannot yet break RSA, it can capture and store TLS traffic today to decrypt it in the future. This changed everything. The trust infrastructure was no longer resistant to a “harvest now, decrypt later” attack.

At the turn of 2018-2021, major organizations – from Google to Cloudflare – began to speak more strongly about the need to move to post-quantum algorithms. The problem was that migrating the entire X.509 structure to new algorithms was practically impossible. PQC support in browsers, mobile devices, IoT systems, and cryptographic libraries was, and still is, very limited. If browsers suddenly required PQC certificates or if CAs began issuing them by default, a large part of the internet would stop functioning. A solution had to be found that would provide resistance to quantum computers without breaking compatibility with an ecosystem that has evolved for three decades.

This is how the idea of hybrid certificates was born – a construction that does not replace RSA or ECDSA, but adds a second post-quantum public key alongside them. The two values form a single SPKI structure that represents two worlds of cryptography. A hybrid certificate is not yet a fully post-quantum certificate. It is a transitional certificate, a bridge between eras. It maintains compatibility with devices that understand only classical algorithms while allowing PQC-ready clients to securely establish sessions resistant to future quantum attacks. To understand why hybrid certificates are so fundamental, one must return to the architecture of X.509 itself. The entire trust system in TLS is based on the certificate chain. Each certificate is signed by a superior key, and the chain ends with a root certificate, anchored in the trusted store of the browser or operating system. This model, despite its simplicity, guarantees high flexibility: it allows classic EV, DV, OV chains, cross-signed certificates, cloud intermediates, and many other constructions. A hybrid certificate must operate in the same ecosystem as a classical certificate. Root CAs cannot be replaced – at least not quickly – because the ecosystem includes billions of devices and millions of applications. Therefore, the hybrid design is based on preserving and extending the classical X.509 structure, not replacing it.

The greatest challenge from the certificate construction perspective is that X.509 was not designed as a multi-algorithm container. When RFC 2459 was created in 1999, its authors did not anticipate that the SPKI field would ever need to store more than one key. The structure was sufficient for RSA, later ECDSA, and even EdDSA. But there was no anticipation that multiple algorithms would need to be encoded at the same time. This is why composite-SPKI is such a significant revolution: two independent public keys must be placed in one BIT STRING, and the OID must indicate that this structure is composite. This is the fundamental starting point for further parts of the article. For hybrid certificates to exist, a completely new public_key architecture, a new signature architecture, a new CSR architecture, a new TLS handshake mechanism, and a new CA validation model had to be created. This is not evolution – it is reconstruction. And yet it was achieved in a backward-compatible way, which is the greatest applied cryptography achievement of recent years.

The end of the RSA/ECDSA era: the crisis of classical cryptography and the reason hybrids were born

Asymmetric cryptography, which for three decades was the pillar of internet security, has entered a tipping point unprecedented in the history of security engineering. RSA and ECDSA algorithms, which since the 1990s have defined how TLS functions, turned out to be fundamentally non-resistant to the development of quantum computers. This is not about marginal weakening; it is about mathematical certainty – these algorithms will fall to Shor’s algorithm once quantum computers exceed several hundred logical qubits.

This introduced a concept that now defines the direction of the entire security world: “harvest now, decrypt later”. Attackers do not need quantum computers today to create a future threat. It is enough to intercept encrypted TLS traffic and store it. If a TLS session uses RSA or ECDSA, then when quantum computers arrive, its contents will become readable. The problem is therefore not an abstract threat on the horizon but the real necessity of protecting today’s sessions from future decryption.

To understand why RSA and ECDSA are particularly vulnerable to quantum attacks, one needs a brief overview of their mathematical foundations. RSA is based on the difficulty of factoring large numbers – a task that remains computationally infeasible for classical computers with 2048-bit keys. However, Shor’s algorithm reduces factoring to a quantum register search, drastically reducing the computation time to polynomial. ECDSA relies on the discrete logarithm problem on elliptic curves, also difficult for classical computers but equally vulnerable to Shor. In other words, the entire TLS architecture was based on assumptions that will no longer apply once quantum computers reach a certain scale.

Additionally, there is the issue of key length. Many administrators believe that increasing RSA key size solves the security problem. In practice, this is an illusion. RSA 4096 offers more resistance against classical attacks, but does not increase resistance to Shor’s algorithm even by a millisecond – RSA 4096 falls just like RSA 2048. Therefore, hybrid certificates are not an alternative to RSA 4096; they are the only real way to protect against future decryption.

This context led to the creation of post-quantum cryptography (PQC). Based largely on lattices, it is the most promising family of algorithms because it is not vulnerable to known quantum attacks. The most important ones are ML-KEM (formerly Kyber) and ML-DSA (formerly Dilithium), chosen by NIST as PQC standards. These algorithms introduce significant complications. PQC keys and signatures are many times larger than classical ones, and their use requires new formats and protocol adjustments.

And here we encounter the fundamental problem – PQC cannot simply be “inserted” into the existing certificate structure. X.509 did not anticipate embedding multiple keys simultaneously. SPKI was a single-algorithm structure containing only one algorithm + key pair. Therefore, the emergence of PQC forced a redefinition of the certificate model. Notably, this is the first time since the 1990s that the SPKI construction had to be radically rebuilt.

Before moving to composite-SPKI, one more aspect of the classical cryptography crisis must be addressed: increasing computational power and miniaturization. For decades, it was sufficient to increase key length or introduce new elliptic curves. But advances in computing power, hardware coprocessors, and research on quantum annealing showed that maintaining security by increasing classical parameters is becoming inefficient. A structural, not parametric, solution was needed.

Another important aspect is that PQC algorithms require significantly more memory and performance – not in terms of computational complexity as such, but in terms of data size. A public key of ML-KEM-768 exceeds 1 KB, and an ML-DSA signature may have 2–3 KB. From the certificate’s perspective, where a classical ECDSA key occupies 64 bytes, this is a giant leap. Embedding PQC alone in a certificate would result in certificates larger than many messages used during the TLS handshake. Many devices, especially IoT, would not be able to handle such certificates. Hybrids solve this problem, offering compatibility with devices that do not support PQC but can handle a certificate slightly larger than before.

It is also worth noting that migration to PQC cannot occur in a single step. CAs cannot stop issuing classical certificates overnight, because most devices will not accept them. Browsers cannot suddenly require PQC, as it would break backward compatibility. Therefore, hybrid certificates are the only solution that allows gradual migration. They enable PQC deployment in handshake protocols without requiring PQC support from CAs, browsers, and devices that are not yet ready.

Hybrid certificates were therefore not created as an experiment – they were created as a necessity. Maintaining the current X.509 model with one algorithm became impossible. Moving to pure PQC was also impossible. A composite model was required.

In the next part, we move to the place where hybrid engineering begins – the composite SPKI design. That is where the mechanics of encoding two keys in one ASN.1 structure appear, along with algorithm identifiers, compatibility issues with existing certificate structures, and practical challenges such as size and impact on transport protocols.

Composite SPKI design and architecture: a new form of public key in X.509

The revolution introduced by hybrid certificates is centered not in TLS, not in PQC, but in one of the most fundamental elements of the entire X.509 standard – the SubjectPublicKeyInfo (SPKI) field. It is this structure, which remained almost untouched for over three decades, that had to be radically redesigned to allow embedding both a classical and a post-quantum key in a single certificate. SPKI was not designed as a multi-algorithm container. RFC 5280 clearly assumed that a certificate describes exactly one public key. A hybrid certificate forces a break in this assumption – but it must do so in a way that does not break compatibility with existing infrastructure, libraries, ASN.1 parsers, browsers, CAs, and path validation mechanisms.

To understand how composite SPKI was created, one must first understand how classical SPKI is built. Its ASN.1 definition consists of two elements: algorithm and subjectPublicKey. The first contains the algorithm’s OID and optional parameters, the second contains the raw public key encoded as a BIT STRING. For RSA, the public key is a structure containing the modulus and exponent; for ECDSA, it is a point on the elliptic curve encoded in uncompressed or compressed format. SPKI always represents one value pair – and practically all ASN.1 parsers worldwide assume this uniqueness.

In the case of hybrid certificates, it was not possible to “attach” the PQC key in an X.509 extension, because most certificate interpreters ignore non-critical extensions during validation. If PQC were placed in an extension, PQC-ready clients could use it, but classical implementations would still interpret the certificate as classical – meaning the TLS handshake would remain vulnerable to quantum attacks.

A structure that modifies the core of the certificate was required, ensuring that the PQC key is part of SPKI. This ensures that every client, even PQC-unaware, sees it as a registered SPKI form, while modern clients interpret it as a composite of two keys.

For this purpose, the compositeSubjectPublicKeyInfo structure was designed, still located inside SPKI, but with content indicating that it represents two keys simultaneously. This is a layered construction.

The first layer is the algorithm identifier change – the OID no longer points to RSA, ECDSA, or ML-KEM, but to a composite algorithm. IETF drafts usually include an OID such as id-alg-composite or id-alg-hybrid, signaling that SPKI does not contain a single key. This is a key compatibility feature: if a library does not understand the composite-OID, it treats it as an unknown algorithm but, according to RFC 5280, does not break certificate validation as long as the certificate’s signature algorithm is classical and recognized. This allows maintaining browser compatibility.

The second layer of composite-SPKI is the encoding method for the two keys. ASN.1 requires the BIT STRING to contain exactly one bit representation of public_key. Composite-SPKI must therefore wrap both keys in a single sequence. A typical representation looks as follows: BIT STRING { SEQUENCE { publicKey1 BIT STRING, publicKey2 BIT STRING } }. Inside the sequence is the full structure of the classical key (e.g., ECDSA P-256) and the PQC key (e.g., ML-KEM-768). Both keys must include OID parameters, but these parameters do not appear in the SPKI algorithm; they appear within the composite layer.

In practice, this means composite-SPKI is a three-layer container: SPKI → BIT STRING → SEQUENCE → BIT STRING + BIT STRING. This requires ASN.1 parsers to be updated, as they previously assumed that public_key was always a raw modulus or point encoded in a single BIT STRING.

The biggest technical issue is size. A public key of ML-KEM-768 exceeds one kilobyte, and ML-KEM-1024 exceeds 1.5 KB. Adding an ECDSA P-384 key (approx. 97 bytes), the SPKI structure grows into several kilobytes. After ASN.1 headers, composite algorithm identifiers, and sequence wrappers are added, composite-SPKI may reach 2–10 KB. And that is only the SPKI. The certificate as a whole contains SPKI as one part of TBSCertificate, which also includes subject, validity, issuer, and extensions. A hybrid certificate naturally exceeds 10 KB, and in typical implementations is 13–17 KB.

This changes the TLS dynamics. In TLS handshake, the certificate must be transmitted in the Certificate message. TLS 1.2 and TLS 1.3 transport certificates differently, but both assume that a single TLS record can fit up to approx. 16 KB. A hybrid certificate of 17 KB does not fit and requires fragmentation across records. This is not a problem for most modern clients, but many IoT devices, routers, and load balancers use simplified TLS stacks that assume certificates fit into a single fragment. Composite-SPKI breaks this assumption – and this is one of the most significant deployment barriers.

Another aspect is CT Logs (Certificate Transparency). CT Logs require every certificate to be logged in a consistent format and within size constraints. Many CT implementations have hard size limits of around 16 KB. Composite-SPKI may exceed this limit, forcing log operators to update their software. CT is a critical element of the certificate ecosystem; its modification must be extremely cautious.

Semantically, composite-SPKI introduces another fundamental change: a hybrid certificate no longer represents a single cryptographic identity. It represents two identities – classical and post-quantum. There are two private keys and two public keys, and each of them can be used for cryptographic operations. In classical certificates, the TLS signature originates from the key corresponding to SPKI. In hybrid certificates, depending on the handshake algorithm, the TLS signature may originate from the classical key, the PQC key, or both combined. The latter is important: in full composite signature implementations, the certificate is signed by two signatures simultaneously – classical and PQC. This provides quantum resistance at the certificate level, not only during the handshake. Currently, however, classical signatures dominate because CAs are rooted in classical roots.

Another aspect is the interpretation of X.509 extensions. Extensions such as BasicConstraints, KeyUsage, and ExtendedKeyUsage must apply to both keys, not only the classical one. Validation mechanisms that previously interpreted these extensions unambiguously must now assume certificates may be used for both classical and PQC operations. This forces changes across CAs, libraries, and browsers.

Composite-SPKI is, in effect, a new certificate architecture, not a cosmetic extension. It changes key encoding, SPKI interpretation, validation methods, transport behavior, and CT publication. It is the “heart” of hybrid certificates – and the foundation without which nothing else could function.

ASN.1 and PQC in X.509: the anatomy of a hybrid certificate

If the composite SPKI is the heart of a hybrid certificate, then ASN.1, and more precisely its DER binary format, is the skeleton. ASN.1 dictates how PQC is encoded, defines sequences, sets lengths, and ensures compatibility with validation mechanisms. In classical X.509 certificates, most of these rules were practically invisible – the use of RSA and ECDSA was so predictable and stable that few people analyzed the TBSCertificate structure, lengths, offsets, and tag identifiers in detail. Hybrid certificates change all of that. To understand their internal architecture, one must look carefully at how ASN.1 encodes data inside X.509 structures.

An X.509 certificate consists of three basic elements: TBSCertificate, signatureAlgorithm, and signatureValue. TBSCertificate is the most important element, as it contains SPKI, subject, issuer, validity, and extensions. Hybrid certificates modify SPKI but the consequences affect all other TBSCertificate elements and even the certificate’s signature. TBSCertificate length changes, which in turn changes the offset of signatureValue, since the certificate is a continuous DER-encoded sequence. When SPKI occupies several kilobytes and TBSCertificate exceeds 10 KB, many implementations must handle offsets not previously encountered.

Before analyzing PQC in hybrid certificates, one must recall that X.509 certificates use DER – a deterministic form of BER. BER allowed flexible representation, but deterministic DER was adopted in TLS for unambiguous encoding. DER imposes rules by which all values must be encoded deterministically. The issue is that DER was not designed with large PQC structures in mind. This introduces technical difficulties requiring careful handling.

PQC appears in hybrid certificates in two locations: in SPKI as the public key and in the certificate signature as part of a composite signature (assuming CA supports hybrid signatures). The presence of two independent cryptographic structures in a single certificate forces changes at several ASN.1 layers. First, the TBSCertificate must include the composite algorithm identifier, and then a BIT STRING containing a sequence of two public keys. Encoding this sequence must be deterministic and conform to DER requirements. If a length exceeds 127 bytes, ASN.1 requires multi-byte length encoding – and this is a critical complication. Many DER libraries include optimizations assuming short lengths. Composite-SPKI breaks this assumption, requiring multi-byte lengths for large PQC sequences and forcing updates in ASN.1 parsers.

The second crucial part is encoding the PQC public key. The ML-KEM-768 key is simply a block of data – a byte array representing a vector in lattice space. ASN.1 treats it as a BIT STRING but must preserve DER rules, including the unused bits byte (usually 0x00). The PQC key must be wrapped in a sequence containing the algorithm’s OID and the encoded key. This results in an ASN.1 structure similar to that used for ECDSA but significantly larger. Composite-SPKI with two public keys must contain two such structures inside a single sequence.

One of the most challenging aspects is the certificate signature. Classical certificates use signatureAlgorithm and signatureValue to store the signature. Hybrid CAs may still use classical signatures only, but ultimately the standard requires composite signatures. Composite signatures are sequences containing two signatures encoded as BIT STRINGs. This required a new signature identifier – compositeSignature. The signatureValue must be encoded as a BIT STRING containing a sequence with two BIT STRINGs: one with the ECDSA signature and one with the ML-DSA signature. This is a major change relative to RFC 5280, which assumed a single signature. DER encoding adds another challenge: composite signatures are large. An ECDSA P-256 signature is 64 bytes, but an ML-DSA-2 signature can be approximately 2.7 KB. Together, the composite signature exceeds 2.8 KB. As a result, an entire certificate may exceed 20 KB. This significantly impacts TLS handshake and CT logs, which often have size limits.

In the CA context, PQC affects the validation process. CAs must recognize both public keys and validate them. Subject Distinguished Name (SDN), validity, and extensions remain unchanged – but CAs must determine whether both keys meet requirements. For example, ML-KEM-512 is too weak and cannot be used. CAs must also verify that both signatures in the composite signature are correct. Composite signature validation requires two independent verifications, and both must refer to the same DER structure. Any DER discrepancy causes validation failure.

ASN.1 imposes rules for path validation. RFC 5280 requires clients to validate signatureAlgorithm and signatureValue. Hybrid certificates have signatureAlgorithm pointing to composite-signature, and signatureValue contains two signatures. A PQC-aware client verifies both. A legacy client will use the classical signature if the CA signs the certificate with a classical algorithm. This ensures backward compatibility.

PQC affects X.509 extensions as well. EKU, KeyUsage, and BasicConstraints remain unchanged, but implementations must be aware that hybrid certificates can be used for both classical and PQC operations. CT logs must store hybrid certificates. PQC-ready clients interpret composite-SPKI as classical + PQC keys. Legacy clients see an unknown structure but do not fail validation as long as the signature is classical.

In summary, PQC changes X.509 more deeply than any update since the standard’s creation. ASN.1 must handle hybrid structures, DER must encode large fields, CAs must handle composite signatures, and clients must interpret composite-SPKI. This requires a thorough rebuild of the certificate ecosystem.

Hybrid CSR and composite signatures: what a certificate request looks like in 2025

If hybrid certificates change the nature of X.509, then the hybrid CSR changes the nature of the entire certificate creation process. In the classical model, CSR was an almost trivial document: one public key, subject data, extensions, and a signature created by the private key. In a hybrid model, none of this is sufficient. A CSR must describe two public keys, be signed with two signatures, and its ASN.1 structure must comply with RFC 2986 (PKCS#10) as well as upcoming PQC standards. This means it is no longer a single sequence of information – it becomes a composite, just like SPKI in the certificate.

To understand how revolutionary the change is, it is worth recalling what a CSR is in ASN.1 terms. PKCS#10 defines a CSR as a CertificationRequest, with certificationRequestInfo, signatureAlgorithm, and signature. The key part is certificationRequestInfo, which contains SPKI. In traditional CSRs, SPKI has a single structure: algorithm and public key. In hybrid CSRs, subjectPublicKeyInfo must reflect the new composite structure.

Hybrid CSR structurally modifies certificationRequestInfo

In its classical form, certificationRequestInfo is a deterministic sequence containing:

• subject
• subjectPublicKeyInfo
• attributes

With PQC and composite keys introduced, the public key is no longer a single value. A hybrid CSR must include:

1. A composite OID indicating that SPKI is a multi-algorithm container.
2. A sequence of two public_key values encoded as BIT STRING, including:
   • classical (RSA/ECDSA),
   • PQC (ML-KEM).
3. Algorithm parameters, which were optional in classical CSR but are mandatory now.

Technically, it looks like this:

subjectPublicKeyInfo :: = SEQUENCE {
   algorithm AlgorithmIdentifier {COMPOSITE-ALGORITHM},
   subjectPublicKey BIT STRING {
        SEQUENCE {
            BIT STRING -- classical key (ECDSA),
            BIT STRING -- PQC key (ML-KEM)
        }
   }
}

This is the first time in PKCS#10 history where subjectPublicKey is a sequence containing other sequences instead of a classical block of raw bits. There is no way to simplify this without breaking future PQC compatibility – therefore listing in this form is unavoidable.

The hybrid CSR must contain a composite signature

Here we reach the most invasive change. In classical CSRs:

• signatureAlgorithm specifies, for example, ecdsa-with-SHA256,
• signature is a single BIT STRING containing the signature.

In hybrid CSRs, this is not enough. Because certificationRequestInfo contains two keys (ECDSA and PQC), the CSR must be signed using both methods.

Thus, the structure becomes:

• signatureAlgorithm = compositeSignatureAlgorithm
• signature = BIT STRING containing a SEQUENCE of two signatures

Formally:

signature ::= BIT STRING {
    SEQUENCE {
       BIT STRING -- ECDSA signature,
       BIT STRING -- ML-DSA signature
    }
}

Why is this necessary?
Because without it, the CA would not have proof that the PQC key actually belongs to the requesting entity. In classical CSRs, the signature proves possession of the key. In hybrid CSRs, proof must exist for:

• the classical key,
• the PQC key.

A sequence of two signatures is the only construction consistent with DER rules that maintains binary integrity for the CA.

The hybrid CSR requires updated attributes and explicit algorithm declarations

In classical CSRs, the attributes field was used mostly for:

• challengePassword
• extensionRequest

In hybrid CSRs, attributes become essential because they may include:

• a declaration of PQC support on the client side,
• preferred PQC algorithms,
• parameters for hybrid handshake mechanisms.

In practice, a CA may require something in attributes that has never existed before:

pqcPreferences ::= SEQUENCE {
    kemAlgorithm OBJECT IDENTIFIER,
    signatureAlgorithm OBJECT IDENTIFIER
}

This means the client must explicitly declare which PQC combination it uses: ML-KEM-512, ML-KEM-768, ML-DSA-2, ML-DSA-3, etc.

And here lies a major compatibility problem. Many older PKCS#10 libraries ignore fields they do not understand – but they cannot affect the CSR signature, otherwise the CA will reject the request. Therefore, attributes in hybrid CSRs must be:

• strictly DER-encoded,
• unable to modify certificationRequestInfo after signing,
• ordered according to ASN.1 rules.

If attributes are encoded incorrectly, the CA will fail composite signature validation. This is a real practical issue in hybrid deployments.

Implementation challenges: generating hybrid CSR in OpenSSL 3.x

OpenSSL 1.x does not and will never support this.
OpenSSL 3.x offers partial composite support, but requires patches and additional providers.

To generate a hybrid CSR, the OpenSSL library must be configured to:

1. Load the classical provider (default).
2. Load the PQC provider (e.g. liboqs-openssl).
3. Create a composite key context:

   EVP_PKEY_CTX_new_from_name(NULL, "COMPOSITE", NULL)
   

4. Inject two keys:

   EVP_PKEY_set1_tls1_prf_key(key_ec)
   EVP_PKEY_set1_tls1_prf_key(key_pqc)
   

5. Generate the composite-SPKI structure.
6. Generate the CSR signed with a composite signature.

In most Linux distributions, this cannot be done without recompiling OpenSSL.

Hybrid CSR validation on the CA side

A CA must perform:

1. DER validation of the entire certificationRequestInfo,
2. validation of the classical key,
3. validation of the PQC key,
4. validation of both signatures in the composite signature.

These steps must occur in the correct sequence because composite signatures do not define key order – the CA must know the order from composite-SPKI. If the CA confuses the order, the CSR becomes invalid.

Additionally, the CA must check:

• compliance of PQC algorithms with the security profile (e.g., ML-KEM-512 not allowed),
• correct OID structure,
• absence of disallowed extensions or attributes,
• no mismatch between SPKI and declarations in attributes (if PQC-preferences are provided).

This is a difficult process. Modern CAs implement new pipelines for this – parallel to classical pipelines.

Hybrid CSR changes the concept of cryptographic identity

In a traditional CSR we have one key pair. In a hybrid CSR we have:

• two key pairs,
• two signatures,
• one document identifying the entity.

This fundamentally changes the concept of identity. A CSR is no longer proof of possession of one key – it is proof of possession of two keys of different mathematical classes. This is no longer classical PoP (Proof-of-Possession). It is dual-PoP.

For CAs, this means a completely new security model. If one of the keys is compromised, the hybrid certificate does not lose value – the handshake may still be executed using the other algorithm.

This is the highest level of cryptographic redundancy ever introduced in TLS.

Impact of Hybrid CSR on the future of ACME

ACME, the protocol for automated certificate issuance, requires CSR to be submitted as base64 DER. A hybrid CSR is 5–12× larger than a classical one, affecting:

• maximum payload sizes,
• CSR transmission mechanisms,
• fragmentation requirements,
• signature validation.

Hybrid CSR is one of the reasons behind ACME 2.0 / 3.0, which introduces:

• PQC support,
• hybrid algorithm declarations,
• possibly pre-negotiation mechanisms for PQC algorithms.

Hybrid TLS Handshake: full step-by-step cryptographic analysis.

Hybrid TLS handshake is the deepest modification of TLS since TLS 1.3. It is during key exchange, algorithm negotiation, and shared secret creation (joint secret) that one can see how significant the changes in the security architecture of the internet have become. Hybrid certificates are only containers – the handshake is the process that actually uses both keys: classical and post-quantum.

The most important point is understanding that TLS 1.3 was not designed for two parallel secret-generation mechanisms. The protocol had to be extended, but in a way that would not break compatibility with existing clients and servers.

The fundamental change is how the client sends ClientHello. In classical TLS 1.3, ClientHello contains a list of supported ECDHE groups and an ephemeral ECDH public key. In hybrids, ClientHello becomes a dual structure: it must contain the classical key_share (e.g. X25519) and the PQC-KEM component (e.g. ML-KEM-768). This increases ClientHello size, but the more important aspect is that both parts of the handshake must be synchronized. The client does not send two independent negotiation mechanisms – it sends one synergistic structure where PQC and ECDHE are logically linked.

To understand this more clearly, examine the hybrid ClientHello structure. The introduction of fields kem_ids and kem_public_key is necessary, but must be done so that non-PQC clients can ignore them. The mechanism resembles TLS extensions, but with much greater cryptographic significance. Hybrid ClientHello thus requires precise modeling of two key layers.

The most important elements of a hybrid ClientHello include:

• classical_key_share – ECDHE public key,
• kem_public_key – PQC public key,
• supported_kem_ids – list of supported PQC algorithms,
• cipher_suites – must reflect dual support while remaining TLS 1.3 compliant.

All these elements must be encoded so that legacy ECDHE-only libraries can ignore PQC fields. This ensures backward compatibility: if a client does not understand PQC, it still completes the handshake using classical ECDHE.

Hybrid TLS: two independent secrets generated in parallel

When the server receives a hybrid ClientHello, it must respond with a hybrid ServerHello. This means the server also provides two keys: classical ECDHE and PQC-KEM. Only at this stage does the cryptographic core of hybrid TLS become visible – two independent secret-generation mechanisms operate simultaneously.

In a classical handshake:

• the client generates point kG,
• the server generates dG,
• the shared secret is kdG,
• HKDF-Extract derives handshake_secret from it.

In a hybrid handshake, two processes occur simultaneously:

1. ECDHE:
   Classical Diffie–Hellman mechanism producing secret Z_classical.
2. ML-KEM:
   A PQC-KEM does not create the secret through algebraic structure.
   Instead, the client generates:
   • a random secret ss,
   • a ciphertext ct.
     The server decapsulates the ciphertext and recovers the same ss.

This is the critical concept: PQC-KEM provides a secret that does not depend on algebraic key properties. Even with a quantum computer and full handshake capture, the PQC secret cannot be reconstructed.

This combines two cryptographic worlds – algebraic and lattice-based – into a unified secret foundation.

Combining secrets: the heart of hybrid security

TLS 1.3 uses HKDF-Extract to derive handshake_secret. In hybrids, the mechanism is extended so that both secrets feed HKDF:

joint_secret = HKDF-Extract(
       salt = Z_classical,
       IKM  = Z_pqc
)

The classical secret becomes the “salt”, PQC becomes the input, and HKDF produces a new key combining both mathematical domains.

Why this design?

• If classical ECDHE is broken → PQC still protects the session.
• If PQC is broken in the future → the classical curve still protects the session.
• If traffic is intercepted today → PQC prevents future decryption.

This model is the foundation of “harvest now, decrypt later” resistance. Hybrid TLS is not simply two handshakes in one – it is one handshake whose security equals the sum of both algorithms’ security.

Interoperability issues: where hybrids break in real-world deployments

Although the hybrid model is clean in mathematical terms, its real-world implementations face significant challenges.

The biggest one is size. Hybrid ClientHello can be 4–10 KB larger. This causes:

• some servers to reject oversized handshake messages,
• IoT devices to overflow buffers,
• load balancers (especially older F5 models) to truncate ClientHello,
• middleboxes to treat large ClientHello as anomalies and drop connections.

Cloudflare documented that during PQC deployment, half of the issues were due to handshake size.

A second major issue is TLS record fragmentation. Hybrid certificates are large, and so is the handshake. TLS must fragment many messages, and some embedded implementations do not correctly process multiple fragments.

A third issue involves libraries unaware of PQC, which:

• ignore PQC keys,
• treat handshake fields as unknown extensions,
• fallback to ECDHE-only mode.

This fallback capability is the exact strength of hybrid design.

Finish of the handshake: deriving joint_secret and entering encrypted mode

Once joint_secret is derived, subsequent TLS 1.3 stages remain unchanged:

• handshake_secret → client and server derive handshake keys,
• handshake keys → protect CertificateVerify, Finished, and remaining handshake,
• master_secret → generates final session keys.

The main difference lies earlier: the secret is not from one algorithm but from a composite of two mathematical systems. This is what makes TLS sessions resistant to future quantum attacks while remaining compatible with today’s devices.

PQC and hybrid certificate implementations in practice: OpenSSL 3.x, Cloudflare, Google, CA/B Forum, and CT Logs

While hybrid TLS theory, composite-SPKI, and joint-secret mechanics define the future of internet security, the real burden of this revolution lies in practical implementations. It is in cryptographic libraries, certificate loaders, validation systems, and CT log modules where the depth and difficulty of changes become visible.

This part examines the key components of the ecosystem: OpenSSL 3.x as the foundational layer, Cloudflare and Google as production pioneers, CA/B Forum as the standardization authority, and Certificate Transparency logs, which must accept certificates even 10× larger than before.

First, it must be understood that switching TLS to PQC is not a mere library upgrade. It is a reconstruction of the entire security architecture, from low-level functions to complex certificate validation procedures. Many still-popular libraries do not correctly implement DER encoding for large key fields. Others have buffers too small to decode hybrid certificates. This makes hybrid certificates themselves a test of network infrastructure maturity.

OpenSSL 3.x is the first major version designed with PQC KEM support and future PQC signature algorithms in mind. Its provider architecture allows loading new algorithms as modules. This is essential for ML-KEM and ML-DSA, which cannot be added as simple crypto functions – they require dedicated key structures, specific entropy generation methods, and mathematical parameter sets.

OpenSSL 1.1.1 was fundamentally unsuitable for this. Its architecture was too tied to classical algorithms, and adding new OIDs and ASN.1 structures was limited. Hybrid certificates are therefore non-verifiable in OpenSSL 1.1.1 – not because of a bug, but because of architectural limitations.

Three critical features in OpenSSL 3.x enable hybrid X.509:

1. The provider model – allows PQC algorithms to be defined as modules,
2. A flexible ASN.1 layer – capable of handling PQC keys and composite structures,
3. Expanded buffers and limits – enabling decoding of certificates 10–25 KB in size.

These features allow hybrid certificates to be decoded without ASN1_TOO_LONG or INVALID_BITSTRING_LENGTH errors. Many older libraries (LibreSSL, older BoringSSL, Botan, mbedTLS) still have issues.

Cloudflare: real-world PQC deployment at global scale

Cloudflare operates ~20% of global HTTPS traffic – making it one of the best references for practical PQC deployment. Cloudflare deployed hybrid TLS in 2023, using Kyber + X25519 (X25519Kyber768Draft). Newer deployments include ML-KEM, enabled only with OpenSSL 3.x.

The most important aspect is the documentation of real-world failures:

• L7 firewalls trimming ClientHello,
• IoT devices rejecting handshake due to size,
• routers/modems misinterpreting key_share fields,
• Java libraries failing composite-OID decoding,
• older CDNs rejecting certs >10 KB,
• LTM load balancers (F5, Fortinet) failing to decode composite-SPKI.

Cloudflare had to deploy fallback to classical ECDHE for clients unable to handle hybrids. This is not a flaw – it is by design. Hybrid handshake ensures that PQC-unaware clients remain compatible.

Cloudflare emphasizes: the biggest PQC challenge is not cryptography but compatibility and structure sizes.

Google: hybrid QUIC, Android, Chrome, HNDL – PQC at the scale of billions

Google advanced even further. Implementing PQC in Chrome means hybrid TLS is already used daily by billions of users without their knowledge.

Google performed unprecedented global PQC experiments:

• Handshake failure rate increased only by ~0.1%.
• Most issues occurred on mobile networks and consumer modems.
• QUIC handled larger hybrid structures significantly better than TLS over TCP.

Google discovered thousands of devices that allowed classical TLS but rejected large PQC hybrid handshakes, particularly in regions with older infrastructure.

This led to the definition of HNDL – Hybrid Now, Decrypt Later, describing PQC deployment aimed at preventing future decryption of intercepted traffic.

CA/B Forum: standardization of hybrid certificates

The CA/B Forum sets SSL/TLS certificate standards. PQC introduction required updating:

• SPKI formats,
• composite OIDs,
• validation rules,
• certificate encoding models,
• CT log requirements.

The key document is the draft Composite Keys and Signatures, defining coexistence of ECDSA and ML-DSA in SPKI and fallback for legacy clients.

CT Logs: next-generation logs for certificates >20 KB

Certificate Transparency requires all public certificates to be logged. But CT logs were designed when certificates were 1–3 KB. Hybrid certificates of 15–25 KB caused:

• “entry too large” errors,
• ASN.1 parsing failures,
• rejection of composite-OID certificates,
• excessive storage strain.

CT logs had to be redesigned into PQC-friendly logs.

Forecast 2025-2030 and implementation recommendations: preparing for the post-quantum TLS era

The direction of the next decade in internet security is no abstraction – it is a concrete trajectory shaped by three forces:

1. regulatory and institutional pressure,
2. real risk of interception and future decryption,
3. pace of PQC adoption by major internet operators.

We are entering an era where network infrastructure must not only be secure today but remain secure against attacks feasible in 5, 10, or more years. Hybrid certificates and hybrid TLS handshake are not – contrary to many companies’ beliefs – “experimental options”. They are the natural evolutionary step of the ecosystem, just like the move from SSL 3.0 to TLS 1.2 or from SHA-1 to SHA-256. The difference is that this time the change impacts the mathematical structure underlying the entire protocol.

The biggest shift guiding future years is the acceptance of NIST’s final PQC algorithms. ML-KEM (Kyber) and ML-DSA (Dilithium) went from proposals to standards to be implemented in libraries worldwide. This means all institutions must migrate. In practice, migration is not singular – it requires several stages across libraries (OpenSSL 3.x+), certificates, handshakes, and automation (ACME, DevOps, CI/CD). PQC cannot be deployed “from the end” or partially – it requires a solid foundation of cryptographic libraries supporting new algorithms and composite-OID.

Long-term projections must also be considered. Years 2025–2026 will see widespread hybrid certificate deployment by CAs. In 2027, most internet services will begin shifting to hybrid TLS handshake. The key point is 2028, when government, financial, and critical infrastructure sectors will require PQC-ready certificates as a security standard. By 2030, classical algorithms will be classified as “legacy”, just like RSA 1024 or SHA-1 today.

This means companies must view their infrastructure differently. Risk analysis must assume that data encrypted today may not be safe in a decade. In the post-quantum adversary model, delayed attacks are real: traffic is intercepted today and can be decrypted years later. This changes everything – algorithm selection, certificate lifetime, and rotation strategies.

Leading to practical recommendations – not shallow advice like “install OpenSSL 3”, but real steps to build hybrid TLS-ready infrastructure.

First recommendation: audit TLS libraries and stacks.
Many assume that using NGINX or Apache makes them “secure”. This is false. Cryptographic heart lies not in the HTTP server but in the crypto library it uses. Running OpenSSL 1.1.1 means not PQC-ready and never will be. Running OpenSSL 3.x but without provider support means the same. The first step is identifying the library behind each system component.

Enterprise environments must check dozens of elements:

• load balancers (F5, Citrix, HAProxy),
• reverse proxies,
• application servers (Tomcat, Jetty),
• JVM, mTLS libraries,
• IoT systems, embedded devices,
• operator gateways,
• mail servers.

Thus, PQC audits reach deeper than typical enterprise assessments.

Second recommendation: phased deployment of hybrid certificates.
This begins in staging environments. Hybrid certificates differ in size, OID structure, ASN.1 encoding, and validation behavior. They serve as natural “filters”: anything incompatible with PQC becomes visible immediately.

Third recommendation: adopt hybrid TLS on critical services.
Services requiring long-term confidentiality (finance, medical, personal data, government systems) must adopt hybrid TLS quickly. These data are most sensitive to harvest-now-decrypt-later attacks. With ML-KEM, captured traffic remains secure even against future quantum computers. Classical ECDHE lacks this.

Fourth recommendation: prepare ACME and DevOps for PQC.
Automation must be rebuilt to generate hybrid CSRs (composite SPKI) and store dual-key material. CI/CD systems require updates to generate and rotate hybrid certificates. Automation fails if its components cannot encode new ASN.1 structures.

Fifth recommendation: understand that hybrids are transitional.
The end goal is full post-quantum TLS – certificates containing only ML-DSA and handshakes using only PQC-KEM. This becomes possible only when all client TLS implementations are PQC-ready. Years 2025–2030 are the hybrid migration era. Early adopters solve compatibility issues gradually. Late adopters (2028-2029) will rush migrations under pressure.

Thus the final recommendation is clear: PQC is not optional – it is inevitable. The sooner infrastructure switches to hybrid mode, the smoother the transition to full PQC will be.

Hybrid certificates and hybrid TLS handshake are not mere technologies. They are the future foundation of system resilience against emerging attack models. Implementing them now is the only way to avoid waking up in a world where classical cryptography no longer provides real security.

FAQ – Hybrid Certificates 2025: How does TLS with ECDSA + PQC actually work?

What exactly is a hybrid X.509 certificate?

A hybrid X.509 certificate contains two independent public keys: a classical one (most often ECDSA P-256/P-384) and a post-quantum one (ML-DSA from the NIST PQC family). Both keys are placed in a shared composite SPKI structure, enabling the certificate to operate in classical environments while providing resistance to future quantum attacks.

How does a hybrid ECDSA + PQC signature work in a certificate?

A hybrid signature consists of two independent signatures made by the same entity:

• ECDSA signs the certificate’s TBS (to-be-signed) structure,
• ML-DSA signs the same TBS.

This yields a “compositeSignature” structure, which clients can verify in two ways:

1. Classical verification: the client ignores PQC and verifies ECDSA.
2. PQC verification: the client ignores ECDSA and verifies ML-DSA.

A dual-capable client may verify both.

Are hybrid certificates compatible with today’s browsers?

Yes. If a browser does not support PQC, it simply ignores the composite structure and uses ECDSA as in a classical certificate. As a result, backward compatibility is preserved.

How does a CA verify a hybrid CSR?

The CA must support:

• composite SPKI,
• composite OIDs,
• dual signatures in CSR,
• PQC providers in backend libraries (e.g. OpenSSL 3.x + PQC module).

The CA validates both signatures in the CSR but may require that at least one method is cryptographically strong (usually ECDSA).

Do hybrid certificates change the TLS handshake?

Yes – the handshake becomes hybrid:

• Classical part uses ECDHE,
• PQC part uses KEM (typically ML-KEM).

Both secrets (classical + PQC) are combined via HKDF into a joint_secret. This ensures that even if one algorithm fails, the session remains secure.

Do hybrid certificates increase handshake size?

Yes – significantly.

• A classical ECDSA certificate is typically 1–3 KB,
• A hybrid certificate may be 10–25 KB or more.

This may affect:

• older TLS stacks,
• IoT devices with small buffers,
• servers with MTU limits,
• embedded systems with limited memory.

In standard environments, it is not an issue.

Will hybrid certificates become mandatory?

Not immediately, but they will be de facto required in:

• 2026-2027 – government and critical infrastructure,
• 2027-2028 – financial sector,
• 2028+ – mainstream commercial environments.

Standards such as NSA CNSA 2.0 and EU requirements (NIS2, CRA) will classify classical cryptography as legacy.

Can we still use pure ECDSA certificates?

Yes, but:

• they do not protect against “harvest now, decrypt later”,
• will be insufficient for high-sensitivity data,
• will be treated as temporary/legacy starting in 2028.

ECDSA will remain as a fallback, not the primary mechanism.

Are hybrid certificates harder to deploy?

Yes, especially in backend infrastructure. Typical problem areas include:

• load balancers (F5, Citrix, HAProxy),
• older OpenSSL versions,
• IoT/embedded TLS stacks,
• mTLS libraries (Java, Go, Python),
• CT logs (large cert sizes).

In modern environments (OpenSSL 3.x, up-to-date TLS libraries) deployment is stable.

Does ACME support hybrid certificates?

Currently only experimentally. ACME v3.0 will introduce:

• composite CSR,
• dual-key support,
• new PQC OIDs,
• forward/backward compatibility mechanisms.

Organizations using certificate automation must prepare CI/CD pipelines for new CSR types.

How does a browser verify a hybrid signature?

The mechanism is straightforward:

• if the client supports PQC, it verifies both signatures (ECDSA + ML-DSA),
• if not, it ignores PQC and verifies ECDSA.

Thus the certificate works in both new and old environments.

Are hybrid signatures more secure than classical ones?

Yes – because an attacker must break both algorithms simultaneously (practically impossible for many years). ECDSA protects today → PQC protects tomorrow.

HEXSSL Insight is a series of expert analyses dedicated to the future of TLS, PKI, certificate automation, and cryptographic security. The goal of the series is to deliver knowledge about trends, technologies, and regulatory changes affecting Internet Security.