OVHcloud launches SSL certificates with quantum randomness: what’s changing for web security (and what’s not)

OVHcloud, a leading European provider, has announced that they are elevating the security of the sites they host by incorporating quantum entropy into TLS/SSL certificate generation. The company has redesigned the key creation process by leveraging a quantum random number generator (QRNG) running on a Quandela quantum computer they acquired, and claims to become the first global player to integrate quantum computing to enhance secure web access. This innovation applies to certificates issued automatically by Let’s Encrypt for the group’s hosting plans and requires no changes from browsers or users.

OVHcloud frames this move within its collaboration with the Internet Security Research Group (ISRG), the parent organization of Let’s Encrypt, and presents the improvement as a way to strengthen the reliability of signing keys that encrypt communications, reducing risks associated with biased or predictable sources of randomness. The initiative is based on a patented innovation by the group, called “certifiable hazard”, and will be deployed at no cost to web hosting customers: almost five million sites hosted by OVHcloud will benefit from QRNG by the end of October 2025.


What does “quantum randomness” mean in a certificate?

To establish a secure TLS connection, the web server needs a pair of cryptographic keys (public/private). The security of that pair depends, among other factors, on the quality of the randomness used during their generation. Traditionally, operating systems combine PRNG/DRBG (deterministic generators seeded with entropy) and, when available, hardware RNG (physical noise) to seed the process. In extreme cases—due to design flaws or operational failures—this randomness can degrade (biases) or become predictable, weakening the outcome.

A quantum random number generator (QRNG) produces bits from an intrinsically random quantum phenomenon. OVHcloud highlights in its announcement the use of photon entanglement to generate bits that are fundamentally unpredictable. In their design, this quantum entropy feeds the generation of keys for the certificates issued by Let’s Encrypt on their hosting platforms. The goal is straightforward: further reduce the likelihood of an attacker being able to model or guess internal states of the generator, thereby enhancing the robustness of the resulting keys.

Key idea: this does not change the certificate standards or how browsers establish TLS; it changes the randomness used to forge the keys.


What it offers (and why it might matter)

  • A stronger entropy source. Quantum physics sidesteps the long-term biases that can accumulate in some classical electronic sources.
  • Mitigation of “rare but real” failures. Security history is sprinkled with incidents of poor randomness (e.g., seed bugs or DRBG controversies). Using QRNG reduces the attack surface for such errors.
  • Operational continuity. There’s no need to update browsers or change servers: certificates remain compatible with the current ecosystem.
  • At no additional cost: OVHcloud states that deployment is free for hosting clients, integrated into Let’s Encrypt’s automatic issuance circuit. Nearly five million sites hosted by OVHcloud will benefit from QRNG before October 2025.

For administrators and developers in managed hosting (shared plans, provider’s web PaaS), the change is transparent. Those generating keys on their own infrastructure (dedicated servers, K8s, self-managed cloud instances) are unaffected unless they use OVHcloud’s web hosting issuance circuit.


What it doesn’t do: this is not post-quantum cryptography

It’s important to distinguish two concepts often confused:

  1. Quantum entropy (QRNG): enhances the quality of randomness used for generating keys with classical algorithms (RSA, ECDSA).
  2. Post-quantum cryptography (PQC): replaces susceptible algorithms to be broken by quantum computers (via Shor / Grover) with resistant schemes based on lattices, codes, etc.

OVHcloud refers to QRNG for strengthening key generation but makes no mention of changes to post-quantum algorithms in certificates (still evolving at the web standard level for compatibility). In other words: it doesn’t turn your website into “quantum-proof” against future quantum computers capable of factoring RSA or breaking ECDSA; it does reduce risks associated with faulty entropy today.


How it fits with Let’s Encrypt and the ecosystem

OVHcloud is a member of ISRG and uses Let’s Encrypt to issue free and automated certificates for hosted sites. The trust chain, signing algorithms, and browser compatibility remain unchanged. The change is in the key generation phase: on platforms where the provider generates and manages this key pair (e.g., fully managed ACME shared hosting), the process injects quantum entropy.

  • For end users: no friction—renewals and deployments stay the same.
  • For browsers: see a standard certificate (e.g., ECDSA P-256/384 or RSA per policy), with no special support needed.
  • For third parties: transparency remains (Certificate Transparency logs), but the source of entropy is not exposed in the certificate; it’s an operational detail of the issuer/manager.

Risks mitigated (with historical examples)

  • Accumulated biases in electronic RNGs that degrade randomness over time (heat, aging, environmental noise).
  • Implementation errors: seed bugs or flawed initialization can reduce effective key space.
  • Rare events: incidents like “constant seed” or “limited key list” that occurred in various libraries over the years.

It’s not a total shield: if a site filters the private key due to misconfiguration, exposed backup, or application-layer attack, the source of randomness used to generate that key won’t save it. QRNG fortifies a specific link in the chain (key creation).


Deployment and scope

  • Status: ongoing.
  • Coverage: Let’s Encrypt certificates for sites hosted by OVHcloud (managed hosting).
  • Compatibility: full with current browsers (no changes in TLS handshake).
  • Cost: free for hosting clients.
  • Goal: ~5 million sites with QRNG by October 2025 (per announcement).

Practical implications for admins and developers

  1. You don’t need to do anything if your website is on OVHcloud web hosting with automatic certificates: you’ll get the improvement automatically.
  2. If you manage your own servers (VPS, dedicated, Kubernetes) and generate your CSR/private key, this doesn’t directly affect you. You can continue with your policies (HSM, OS RNG, TRNG modules) or explore, in the future, if OVHcloud offers QRNG as a consumable service.
  3. Monitor as usual: expiration dates, ACME renewals, intermediate chains, OCSP stapling, cipher suites, CT logs. QRNG does not change these workflows.
  4. Communicate clearly to your business: this is not post-quantum; it’s an entropy improvement. Avoid overpromising.

Limitations and open questions

  • Public traceability: certificates don’t indicate their entropy source; verification depends on internal processes of the provider and – if applicable – audits.
  • Scope: QRNG applies to keys generated by the provider for their hosting. Certificates managed by the client are not included.
  • Threat model: QRNG enhances key unpredictability; it does not prevent compromises via malware, backup leaks, application vulnerabilities, or permission errors.
  • PQ: moving to post-quantum algorithms at web scale is another project (standards, compatibility, performance). QRNG does not replace this.

Why is this interesting for the industry (beyond OVHcloud)

  • Signal: providers can leverage current quantum resources to enhance cybersecurity without breaking compatibility.
  • Adoption path: using quantum for entropy is a reasonable incremental step before tackling complex migrations to PQC.
  • Ripple effect: if successful at scale (~5 million sites), other operators might replicate the pattern with certified QRNGs or managed services.

Conclusion

OVHcloud’s move to inject quantum randomness into certificate key generation of Let’s Encrypt is a sensible technical step: it doesn’t break anything, strengthens a critical link (entropy), and brings a quantum advantage into the day-to-day web without requiring user or browser changes. It does not make sites “post-quantum,” but it reduces the risks of weak keys caused by faulty randomness sources. If it fulfills its promise at scale—~5 million websites by the end of October—it will be an important operational milestone: quantum adding immediate value where breaking compatibility is most painful.


Frequently Asked Questions

Do I need to change anything on my website to use these “quantum” certificates?
No. If your site is hosted on OVHcloud and receives automatic certificates from Let’s Encrypt, this improvement applies automatically. Browsers and TLS clients don’t require adjustments.

Does this make my website “resistant to quantum computers”?
No. QRNG improves the entropy used for current key generation (RSA/ECDSA). Achieving post-quantum resistance involves other algorithms (PQC) which are not part of this announcement.

Can I verify that my certificate was generated with QRNG?
The X.509 certificate does not expose its entropy source. OVHcloud manages it operationally during issuance; public transparency remains via logs (CT logs), but details about the randomness source aren’t included in the certificate.

Does this affect TLS performance or browser compatibility?
No. The TLS handshake, algorithms, and the trust chain from Let’s Encrypt remain unchanged. Browsers work exactly the same. QRNG only influences how the server manages key creation.


Source: Official OVHcloud release — “OVHcloud, the first global player to improve website access security with a quantum computer” (September 23, 2025).

Scroll to Top