OVHcloud lance des certificats SSL avec aléatoire quantique : quels changements pour la sécurité web (et quels ne changent pas)

OVHcloud révolutionne la gestion des applications avec son nouveau service Managed Rancher

OVHcloud, fournisseur européen de référence, annonce avoir renforcé la sécurité des sites qu’il héberge en intégrant de l’entropie quantique dans la génération de certificats TLS/SSL. La société a repensé le processus de création des clés en utilisant un générateur quantique de nombres aléatoires (QRNG) opéré via un ordinateur quantique de Quandela, récemment acquis. Elle affirme ainsi devenir le premier acteur mondial à intégrer le calcul quantique pour améliorer l’accès sécurisé aux sites web. Cette avancée concerne les certificats délivrés automatiquement par Let’s Encrypt pour les plans d’hébergement du groupe, sans nécessité de modification de la part des navigateurs ni des utilisateurs.

OVHcloud inscrit cette initiative dans le cadre de sa collaboration avec le Internet Security Research Group (ISRG), la structure porteuse de Let’s Encrypt, en présentant cette innovation comme un moyen de renforcer la fiabilité des clés chiffrant les communications, en réduisant notamment les risques liés à des sources d’entropie biaisées ou prévisibles. La démarche s’appuie sur une innovation propriétaire, dénommée “hazard certifiable”, qui sera déployée gratuitement pour les utilisateurs d’hébergement web : près de cinq millions de sites hébergés par OVHcloud bénéficieront du QRNG avant la fin octobre 2025.


Que signifie “aléa quantique” dans un certificat ?

Pour établir une connexion TLS sécurisée, le serveur web doit disposer d’une paire de clés cryptographiques (publique/privée). La sécurité de cette paire dépend, entre autres, de la qualité de l’entropie utilisée lors de sa génération. Traditionnellement, les systèmes d’exploitation combinent des PRNG/DRBG (générateurs déterministes alimentés par de l’entropie) et, si disponible, un hardware RNG (bruit physique) pour alimenter le processus. En cas de défaillance – que ce soit par conception défectueuse ou mauvais fonctionnement – cet aléa peut s’altérer (introduire des biais) ou devenir prévisible, affaiblissant la sécurité.

Un générateur quantique de nombres aléatoires (QRNG) produit des bits à partir d’un phénomène intrinsèquement aléatoire de la mécanique quantique. OVHcloud évoque, dans son annonce, l’utilisation de l’intrication de photons pour générer des bits fondamentalement imprévisibles. Dans son architecture, cette entropie quantique sert à fabriquer les clés des certificats délivrés par Let’s Encrypt. L’objectif est clair : réduire encore la probabilité qu’un attaquant puisse prédire ou modéliser les états internes du générateur de nombres, améliorant ainsi la robustesse des clés.

Idée centrale : cela ne modifie pas le standard des certificats ni la manière dont les navigateurs gèrent TLS ;
mais cela change l’aléa avec lequel les clés sont forgées.


Quels avantages (et pourquoi cela peut compter)

  • Une source d’entropie renforcée. La physique quantique évite les biais à long terme que peuvent accumuler certaines sources électroniques classiques.
  • Une mitigation des “failles rares mais réelles”. L’histoire de la sécurité a montré que des défaillances d’entropie (p. ex., bugs de seed ou controverses autour des DRBG) existent : utiliser un QRNG réduit la surface d’attaque.
  • Continuité opérationnelle. Pas besoin de mettre à jour les navigateurs ni de changer les serveurs : les certificats restent compatibles avec l’écosystème actuel.
  • Sans coût supplémentaire : OVHcloud précise que le déploiement est gratuit pour ses clients, grâce à l’intégration dans le circuit automatique de Let’s Encrypt. Plusieurs millions de sites hébergés bénéficieront de cette évolution au plus tard fin 2025.

Pour les administrateurs et développeurs en hébergement managé (plans partagés, PaaS web), le changement est transparent. Ceux qui génèrent leurs clés en dehors de l’écosystème OVHcloud (serveurs dédiés, K8s ou instances cloud autogérées) n’est pas impactés, sauf s’ils utilisent directement le circuit d’émission d’OVH.


Ce que cela ne fait pas : ce n’est pas de la cryptographie post-qubit

Il est utile de distinguer deux notions souvent confondues :

  1. Entropie quantique (QRNG) : améliore la qualité de l’aléa utilisé pour générer des clés via des algorithmes classiques (RSA, ECDSA).
  2. Cryptographie post-qubit (PQC) : remplace des algorithmes vulnérables face à des ordinateurs quantiques (via Shor ou Grover) par des schémas résistants à de tels attaques (basés sur des réseaux, codes, etc.).

OVHcloud parle ici de QRNG pour renforcer la robustesse des clés, sans annoncer d’évolution vers des algorithmes post-quantiques. Autrement dit, cela n’en fait pas une solution “résistante à la puissance quantique” pour la web, ni une migration vers des cryptos post-quantiques. Cela limite les risques d’entropie faible aujourd’hui, mais ne sécurise pas les futurs ordinateurs quantiques capables de casser RSA ou ECDSA.


Comment cela s’intègre-t-il à Let’s Encrypt et à l’écosystème ?

OVHcloud est membre de ISRG et utilise Let’s Encrypt pour délivrer des certificats gratuit et automatisés aux sites hébergés. La chaîne de confiance, les algorithmes de signature et la compatibilité sont inchangés. La modification concerne la phase de mise en place: dans les plateformes où OVH/
gère la génération et la gestion des clés (ex. hébergement mutualisé avec ACME entièrement automatisé), l’intégration de l’entropie quantique se fait automatiquement.

  • En résumé : pour l’utilisateur final, pas de changement – les renouvellements et déploiements restent identiques.
  • Dans le navigateur : le certificat apparaît comme standard (ex : ECDSA P-256/384 ou RSA selon la politique d’émission), sans support spécifique requis.
  • Pour les tiers : la transparence est conservée (logs de Certificate Transparency), mais la source de l’entropie n’est pas affichée dans le certificat, cela reste un détail opérationnel contrôlé par l’émetteur.

Raisons de cette démarche (et exemples historiques)

  • Biais accumulés dans les RNG électroniques qui dégradent la pureté de l’aléa avec le temps (chaleur, vieillissement, bruit ambiant).
  • Erreurs d’implémentation : bugs de mise en route ou mauvaises graines qui réduisent l’espace clé disponible.
  • Évènements rares : incidents comme une « seed » constante ou une liste réduite de clés, qui ont déjà été observés dans diverses bibliothèques et systèmes.

Il ne s’agit pas d’un couteau suisse infaillible : si un site filtres sa clé privée ou exploite des vulnérabilités comme un compromis au niveau logiciel ou de sauvegarde, cela ne sera pas corrigé par QRNG. L’entropie renforcée ne sécurise que l’étape de création de la clé.


Déploiement et portée

  • Statut : opérationnel.
  • Couverte : certificats Let’s Encrypt pour les sites hébergés par OVHcloud (hébergement managé).
  • Compatibilité : totale avec les navigateurs modernes (pas de changement dans l’établissement du TLS handshake).
  • Coût : gratuit pour les clients hébergeurs.
  • Objectif : environ 5 millions de sites équipés de QRNG d’ici fin 2025, selon OVHcloud.

Implications pour administrateurs et développeurs

  1. Vous n’avez rien à faire si votre site est hébergé chez OVHcloud avec certificats automatiques : la mise à jour se fait automatiquement.
  2. Si vous gérez vos propres serveurs (VPS, dédiés, K8s) et générez vous-même vos CSR et clés, cette annonce ne vous concerne pas directement. Vous pouvez continuer à utiliser vos politiques (HSM, RNG système, modules TRNG) ou envisager à l’avenir si OVH propose un service QRNG dédié.
  3. Surveillez vos clés et certificats comme d’habitude : caducité, renouvellements ACME, chaînes intermédiaires, logs CT, suites de chiffrement, OCSP stapling. La technologie QRNG n’altère pas ces processus.
  4. Clarifiez auprès de votre équipe : ceci n’est pas une cryptographie post-quântico, mais une amélioration de l’entropie ; pas de promesses exagérées.

Limitations et questions ouvertes

  • Traçabilité publique : les certificats n’indiquent pas leur source d’aléa ; la vérification repose sur des processus internes et d’éventuelles audits.
  • Portée : le QRNG concerne les clés générées par OVH pour leur infrastructure d’hébergement. Les certificats client restent sous leur gestion.
  • Modèle de menace : QRNG renforce la prévisibilité des clés, pas la protection contre malware, fuite de backups, vulnérabilités applicatives ou erreurs de permissions.
  • PQC : l’adoption d’algorithmes résistants à l’informatique quantique (post-qubits) est un autre chantier, encore en cours de standardisation et de test. QRNG ne remplace pas cette évolution.

Intérêt pour l’industrie (au-delà d’OVHcloud)

  • Un signal que les fournisseurs peuvent dès aujourd’hui utiliser la puissance quantique pour améliorer la cybersécurité, tout en restant compatibles.
  • Voie progressive d’adoption : utiliser le quantum pour renforcer l’entropie constitue une étape raisonnable avant des migrations plus complexes vers des algorithmes post-quantiques.
  • Effet d’entraînement : si cette démarche se déploie à grande échelle (millions de sites), d’autres opérateurs pourront suivre avec des QRNG certifiés ou des services managés similaires.

Conclusion

Le choix d’OVHcloud d’intégrer de l’aléa quantique dans la génération de clés de certificats Let’s Encrypt est une avancée technique prudente : cela ne modifie rien de fondamental, mais cela **renforce une étape critique** (l’entropie), tout en apportant une valeur immédiate à un niveau où l’on cherche à limiter la faiblesse des clés, sans changer immédiatement la compatibilité. Cela ne fait pas de votre site un “résistant à la puissance quantique”, mais réduit nettement le risque d’utilisation de clés faibles, une étape cohérente face à l’imminence des ordinateurs quantiques. Si la déploiement à grande échelle est confirmé, cela constituera une étape opérationnelle importante, intégrant la puissance de la mécanique quantique dans le quotidien web.


Foire aux questions

Dois-je modifier quelque chose sur mon site pour utiliser ces certificats “quantique” ?
Non. Si votre site est hébergé chez OVHcloud et utilise des certificats automatiques de Let’s Encrypt, la mise à jour est automatique, sans ajustement requis côté client ou navigateur.

Est-ce que cela rend mon site “résistant aux ordinateurs quantiques” ?
Pas directement. Cette initiative améliore la qualité de l’aléa dans la génération des clés classiques (RSA, ECDSA). La résistance aux ordinateurs quantiques nécessite des algorithmes post-quantiques, qui ne sont pas concernés ici.

Puis-je vérifier si mon certificat a été généré avec QRNG ?
Le certificat X.509 n’indique pas explicitement la source d’entropie. OVHcloud intègre cependant cette génération de manière interne, et la transparence publique (via CT logs) est maintenue : aucun détail précis de l’aléa n’est affiché dans le certificat.

Est-ce que cela impacte la performance TLS ou la compatibilité navigateurs ?
Non. La négociation TLS, les algorithmes et la chaîne de certification restent inchangés. Les navigateurs fonctionnent de la même façon. La technologie QRNG intervient simplement dans la façon dont la clé est générée côté serveur.


Source : Communiqué officiel d’OVHcloud — “OVHcloud, le premier acteur mondial à améliorer la sécurité d’accès aux sites web avec un ordinateur quantique” (23 septembre 2025).

le dernier