Möglicherweise haben Sie Berichte über ein Problem gesehen, das mehrere Zertifizierungsstellen betrifft, darunter Apple, Google, GoDaddy und (leider) SSL.com. Die meisten dieser Unternehmen verwenden ein Programm namens EJBCA (Enterprise Java Beans Certificate Authority) für eine Reihe von CA-Aktivitäten. Wie der Direktor für Sicherheitsarchitektur von SSL.com, Fotis Loukos, festgestellt hat:
"Die Methode von EJBCA zum Generieren von Seriennummern hat zu einer Diskrepanz zwischen erwartetem und tatsächlichem Verhalten und Ausgabe geführt, sodass jede Zertifizierungsstelle, die EJBCA mit den Standardeinstellungen verwendet, auf dieses Problem stößt (und daher gegen BR 7.1 verstößt)."
"BR 7.1" bezieht sich auf Abschnitt 7.1 der CA / B-Forum-Basisanforderungen, in dem es heißt:
"Ab dem 30. September 2016 MÜSSEN Zertifizierungsstellen nicht sequentielle Zertifikatseriennummern größer als Null (0) generieren, die mindestens 64 Bit Ausgabe von einem CSPRNG enthalten."
CSPRNG ist die Abkürzung für "kryptografisch sicherer Pseudozufallszahlengenerator" und der Mechanismus, mit dem Zahlen mit ausreichender Zufälligkeit (oder "Entropie") generiert werden, um sicherzustellen, dass sie sicher und eindeutig sind. Die Methode, die EJBCA beim Generieren von Seriennummern gewählt hat, setzt das Anfangsbit jedoch automatisch auf Null. Dies bedeutet, dass in einer 64 Bit langen Zeichenfolge die Seriennummer nur 63 Bit Ausgabe vom CSPRNG enthält.
Die realen Auswirkungen dieses Problems auf die Sicherheit sind verschwindend gering, aber selbst wenn der Unterschied zwischen 63 und 64 Bit Entropie die Internetnutzer nicht gefährdet, verstößt es dennoch gegen die Anforderungen, die SSL.com und alle anderen seriösen Personen erfüllen CAs beobachten. Aus diesem Grund widerruft SSL.com alle betroffenen Zertifikate und stellt Ersatzzertifikate für alle betroffenen Kunden aus.
Die Ersatzzertifikate sind vom gleichen Typ wie die widerrufenen und enthalten dieselben DNS-Namen. Darüber hinaus beträgt die Lebensdauer dieser Ersatzzertifikate die volle Dauer des ursprünglich gekauften Zertifikats. Das heißt, selbst wenn Sie vor vier Monaten ein Einjahreszertifikat gekauft haben, ist Ihr neues Ersatzzertifikat ab dem Ausstellungsdatum ein ganzes Jahr lang gültig, sodass Sie insgesamt 16 Monate Zeit haben.
Schließlich gilt dieses Problem einzige zu SSL.coms SSL /TLS Zertifikate (Basic, Premium, High Assurance, Enterprise EV, Wildcard und Multi-Domain). Andere Arten von Zertifikaten, einschließlich S/MIME, NAESB und Codesignatur sind in keiner Weise betroffen.
