Automating certificates has been for years a relatively stable and predictable part of the TLS ecosystem. ACME – the protocol originally introduced by Let’s Encrypt – has become the de facto standard for automated renewals and certificate issuance. Its architecture was built around a simple model: key generation, CSR creation, domain validation, certificate retrieval. In 2025 this model stops being sufficient. With the arrival of PQC (Post-Quantum Cryptography), hybrid certificates, OpenSSL 3.x and increasingly strict CA/B Forum policies, automated certificate environments are facing the biggest change in two decades.

Migration to hybrid TLS means that ACME must handle an entirely new class of operations: generating two keys, building a CSR that merges classical and post-quantum algorithms, processing large SPKI structures, and managing certificates whose size and parameters exceed previous boundaries. ACME 3.0, although not formally named yet, is a necessity – not an option.

1. Certificate automation in the world of two parallel cryptographies.

The most important change is that the certificate stops being a monolith. In the post-quantum world it exists in a hybrid form: an ECDSA part ensuring compatibility with existing clients, and a PQC part (Kyber, Dilithium or their successors) forming the foundation of future quantum-resistant security. This means that ACME must stop being a one-key and one-CSR system.

In hybrid TLS, the relay of two algorithms affects every stage:

• key generation,
• CSR construction,
• structure validation,
• handshake negotiation,
• CA-side validation,
• renewals,
• key rotation within the DevOps pipeline.

In classical ACME the entire process was linear. A hybrid certificate forces a new architecture in which the ACME client becomes a tool orchestrating multiple cryptographic operations simultaneously. This is the biggest revolution in the TLS ecosystem since the transition from SHA-1 to SHA-256.

2. Why ACME in its current form cannot handle PQC?

There are several reasons – and none of them is trivial. The current ACME protocol was created at a time when the certificate was lightweight, the CSR had a few hundred bytes, and RSA 2048 was the standard. In 2025 that standard becomes an anachronism.

The first problem is the size of cryptographic structures. Kyber generates keys that are an order of magnitude larger than ECDSA. Hybrid SPKI can be several times heavier than classical structures. A CSR containing two algorithms and two signature structures has a size that not long ago would have been treated as an error.

The second problem is support for KEM (Key Encapsulation Mechanism). Unlike classical asymmetric cryptography, PQC requires encapsulation operations that generate input material for session keys. Embedding this into a hybrid handshake means that ACME must generate and validate additional elements of the structure.

The third problem is tool compatibility. Most ACME clients have operated for years on OpenSSL 1.0.x and 1.1.x. PQC is not compatible with these libraries – and never will be. This means that practically the entire ACME tool ecosystem must be rebuilt: Certbot, acme.sh, LEGO, Posh-ACME, win-acme and dozens of implementations in K8s controllers.

The fourth problem is verification. ACME was designed for domain validation, not for validating hybrid algorithm structures. A CA must confirm the correctness of both key sets, compliance with CP/CPS policy, and the internal integrity of the hybrid CSR. This changes the CA architecture and the processes that ACME must support.

3. Hybrid CSR: the new center of gravity for automation

In the PQC era, the CSR becomes the most problematic element of automation. In the classical world, a single key and a single Subject Public Key Info field were sufficient. Today a CSR must include:

• a classical key (ECDSA),
• a PQC key (Kyber or another NIST finalist),
• a combined SPKI structure,
• encoded PQC extensions,
• parameters indicating the type of signature,
• potential PQC-specific OIDs.

This is no longer a lightweight text file – it is a complex structure requiring libraries capable of generating and validating the new format. ACME must therefore be extended with processes for creating, signing, validating and serializing a hybrid CSR. If automation does not account for this, a hybrid certificate will not be issued – or worse, it will be rejected only during handshake, producing difficult-to-debug errors.

4. Domain validation in the PQC world – more than a trivial challenge

PQC also introduces new risks into the validation process. ACME was designed with the assumption that domain validation is a simple operation: HTTP-01, DNS-01 or TLS-ALPN-01. However, the new handshake model and the large number of implementation errors in PQC clients mean that ACME must become more precise in detecting:

• incorrect SPKI structures,
• incompatible PQC KEM implementations,
• hybrid certificates generated out of spec,
• incomplete PQC extensions.

Domain validation remains the same – but CSR validation becomes a completely new operational area, at a level ACME 1.x and 2.x were not designed to handle.

5. Key rotation in the DevOps pipeline: automation under pressure

The biggest challenge will not be the handshake. It will not be the CA either. The biggest issue will be automatic certificate renewals. Every 60-90 days automation cycle – something that was trivial for years – suddenly becomes one of the most complex processes in DevOps.

The CI/CD pipeline must perform:

1. Generation of the ECDSA key.
2. Generation of the PQC key (e.g., Kyber 768).
3. Combining them into a hybrid key structure.
4. Creation of a CSR compliant with CA policy.
5. Sending it via ACME.
6. Handling previously unknown errors (e.g., oversized payload).
7. Server-side verification that the handshake works.
8. Replacing certificates on production servers.
9. Replacing certificates on edge, CDN, API gateway, MQTT, IoT.

This is a completely different world from classical “certbot renew”. In practice, many companies will discover only in 2025-2027 that they have hundreds of places where keys and certificates are distributed – and that each of them must be adapted to the new reality.

6. Handshake size and the impact on edge, CDN and load balancers

Hybrid TLS generates larger handshake packets, which will trigger a cascade of issues:

• IoT devices having insufficient buffer sizes,
• legacy load balancers treating large ClientHello as suspicious,
• some WAF systems blocking PQC handshakes as “anomalies”,
• CDNs needing to support larger key footprints.

ACME in its classical form did not account for this. With PQC it must become not only a certificate automation protocol, but also a tool ensuring consistency of the entire certificate distribution chain in edge environments.

7. ACME 3.0 – what will it look like?

Although the specification has not been published yet, a number of patterns emerge from CA activities and TLS vendors. ACME 3.0 will likely include:

• support for multi-algorithm CSR,
• standardization of SPKI structures for PQC,
• PQC algorithm validation mechanisms,
• larger payload limits,
• new transport methods (HTTP/2, HTTP/3),
• native integration with DevOps pipelines,
• pre-checking of hybrid certificates before issuance,
• additional PQC OID structures.

The most important difference is another one: ACME will become a protocol of continuous compliance, not a one-time domain validation.

8. Are companies ready for post-PQC ACME?

No. The vast majority of organizations do not have:

• up-to-date cryptographic libraries,
• modernized DevOps pipelines,
• compatible K8s controllers,
• updated edge devices,
• HSM resources supporting PQC.

The coming years will be the period of the greatest technical transformation in the history of TLS certificates.

9. Conclusions: ACME is no longer a “certificate tool”. It is the foundation of infrastructure security.

The PQC era makes certificate automation a high-risk technical area. Companies that do not adapt ACME to support hybrid algorithms will experience:

• renewal errors,
• failing handshakes,
• environment inconsistencies,
• incompatible certificates,
• CDN region issues,
• IoT and edge incidents,
• non-compliance with CA/B Forum policies.

In 2025, ACME undergoes a transformation of unprecedented scale. What for years was a technical detail is becoming one of the key elements of resilience for the post-quantum era.