Vous avez peut-être vu des rapports sur un problème qui affecte plusieurs autorités de certification, notamment Apple, Google, GoDaddy et (malheureusement) SSL.com. La plupart de ces entreprises utilisent un programme appelé EJBCA (Enterprise Java Beans Certificate Authority) pour une gamme d'activités CA. Comme l'a noté Fotis Loukos, directeur de l'architecture de sécurité de SSL.com:
"La méthode de génération des numéros de série d'EJBCA a conduit à un écart entre le comportement et la sortie attendus et réels, de sorte que toute autorité de certification utilisant EJBCA avec les paramètres par défaut rencontrera ce problème (et sera donc en violation de BR 7.1)."
«BR 7.1» fait référence à la section 7.1 des exigences de base du forum CA / B, qui stipule:
"À compter du 30 septembre 2016, les autorités de certification DOIVENT générer des numéros de série de certificats non séquentiels supérieurs à zéro (0) contenant au moins 64 bits de sortie d'un CSPRNG."
CSPRNG est l'abréviation de «générateur de nombres pseudo-aléatoires cryptographiquement sécurisé» et est le mécanisme utilisé pour générer des nombres avec un caractère aléatoire suffisant (ou «entropie») pour garantir qu'ils sont sécurisés et uniques. Cependant, la méthode choisie par EJBCA lors de la génération des numéros de série met automatiquement le bit initial à zéro - ce qui signifie que dans une chaîne de 64 bits, le numéro de série ne contiendra que 63 bits de sortie du CSPRNG.
L'impact réel de ce problème sur la sécurité est extrêmement faible, mais même si la différence entre 63 et 64 bits d'entropie ne met pas les internautes en danger, elle est toujours en violation des exigences de SSL.com et de tous les autres Les CA observent. C'est pourquoi SSL.com révoque tous les certificats concernés et émet des certificats de remplacement pour tous les clients concernés.
Les certificats de remplacement seront du même type que les certificats révoqués et contiendront les mêmes noms DNS. De plus, la durée de vie de ces certificats de remplacement sera de durée totale du certificat acheté à l'origine. Cela signifie que même si vous avez acheté un certificat d'un an il y a quatre mois, votre nouveau certificat de remplacement sera valide pour une année complète à compter de sa date d'émission, vous donnant un total de 16 mois.
Enfin, ce problème s'applique uniquement au SSL de SSL.com /TLS certificats (Basic, Premium, High Assurance, Enterprise EV, Wildcard et Multi-domain). Autres types de certificats, y compris S/MIME, NAESB et la signature de code ne sont en aucun cas affectés.
