You might have seen reports about an issue that’s impacting multiple certificate authorities, including Apple, Google, GoDaddy, and (unfortunately) SSL.com. Most of these companies use a program called EJBCA (Enterprise Java Beans Certificate Authority) for a range of CA activities. As SSL.com’s Director of Security Architecture Fotis Loukos has noted:
“EJBCA’s method of generating serial numbers has led to a discrepancy between expected and actual behavior and output, such that any CA using EJBCA with the default settings will encounter this issue (and be therefore in violation of BR 7.1).”
“BR 7.1” refers to Section 7.1 of the CA/B Forum Baseline Requirements, which states:
“Effective September 30, 2016, CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.”
CSPRNG is short for “cryptographically secure pseudo-random number generator” and is the mechanism used to generate numbers with sufficient randomness (or “entropy”) to guarantee they are secure and unique. The method EJBCA chose to use when generating serial numbers, however, automatically sets the initial bit to zero – which means that in a 64 bit long string, the serial number will contain only 63 bits of output from the CSPRNG.
The real-world impact of this issue on security is vanishingly small, but even if the difference between 63 and 64 bits of entropy doesn’t put Internet users at risk it is still in violation of the requirements which SSL.com and all other reputable CAs observe. This is why SSL.com is revoking all impacted certificates and issuing replacement certificates for all affected customers.
The replacement certificates will be of the same type as the revoked ones, and will contain the same DNS names. Furthermore, the lifetime of these replacement certificates will be of the full duration of the originally-purchased certificate. That means that even if you bought a one-year certificate four months ago, your new replacement certificate will be valid for a full year from its date of issue, giving you a total of 16 months.
Finally, this issue applies only to SSL.com’s SSL/TLS certificates (Basic, Premium, High Assurance, Enterprise EV, Wildcard, and Multi-domain). Other types of certificates, including S/MIME, NAESB, and code signing, are not affected in any way.