Mogelijk hebt u rapporten gezien over een probleem dat van invloed is op meerdere certificaatautoriteiten, waaronder Apple, Google, GoDaddy en (helaas) SSL.com. De meeste van deze bedrijven gebruiken een programma genaamd EJBCA (Enterprise Java Beans Certificate Authority) voor een reeks CA-activiteiten. Zoals SSL.com's Director of Security Architecture Fotis Loukos heeft opgemerkt:
"De methode van EJBCA om serienummers te genereren heeft geleid tot een discrepantie tussen verwacht en werkelijk gedrag en output, zodat elke CA die EJBCA gebruikt met de standaardinstellingen dit probleem zal tegenkomen (en daarom in strijd is met BR 7.1)."
"BR 7.1" verwijst naar Paragraaf 7.1 van de CA / B Forum Baseline Requirements, waarin staat:
"Met ingang van 30 september 2016 MOETEN CA's niet-opeenvolgende certificaatserienummers genereren die groter zijn dan nul (0) met ten minste 64 bits uitvoer van een CSPRNG."
CSPRNG is een afkorting van "cryptografisch beveiligde pseudo-willekeurige nummergenerator" en is het mechanisme dat wordt gebruikt om getallen te genereren met voldoende willekeur (of "entropie") om te garanderen dat ze veilig en uniek zijn. De methode die EJBCA koos om te gebruiken bij het genereren van serienummers, stelt echter automatisch de eerste bit in op nul - wat betekent dat in een 64 bit lange string het serienummer slechts 63 bits uitvoer van de CSPRNG zal bevatten.
De werkelijke impact van dit probleem op de beveiliging is verbluffend klein, maar zelfs als het verschil tussen 63 en 64 bits entropie internetgebruikers niet in gevaar brengt, is het nog steeds in strijd met de vereisten die SSL.com en alle andere gerenommeerde CA's observeren. Daarom trekt SSL.com alle betrokken certificaten in en geeft het vervangende certificaten uit voor alle betrokken klanten.
De vervangende certificaten zijn van hetzelfde type als de ingetrokken certificaten en bevatten dezelfde DNS-namen. Bovendien zal de levensduur van deze vervangende certificaten van de volledige duur van het oorspronkelijk aangeschafte certificaat. Dat betekent dat zelfs als u vier maanden geleden een jaarcertificaat heeft gekocht, uw nieuwe vervangingscertificaat een heel jaar geldig is vanaf de datum van uitgifte, wat u in totaal 16 maanden geeft.
Ten slotte is dit probleem van toepassing Slechts naar SSL.com's SSL /TLS certificaten (Basic, Premium, High Assurance, Enterprise EV, Wildcard en Multi-domain). Andere soorten certificaten, waaronder S/MIME, NAESB en codeondertekening worden op geen enkele manier beïnvloed.
