[conspire] Cert debacle involving a billion certs

[Rick Moen]

Quoting Dire Red (deirdre at deirdre.net):

> https://arstechnica.com/information-technology/2019/03/godaddy-apple-and-google-goof-results-in-1-million-misissued-certificates/
> 
> "The snafu is the result of the companies' misconfiguration of the
> open source EJBCA software package that many browser-trusted
> authorities use to generate certificates that secure websites, encrypt
> email, and digitally sign code. By default, EJBCA generated
> certificates with 64-bit serial numbers, in keeping, it seemed, with
> an industry mandate that serial numbers contain 64 bits of output from
> a secure pseudo-random number generator. Upon further scrutiny,
> engineers discovered that one of the 64 bits must be a fixed value to
> ensure the serial number is a positive integer. As a result, the EJBCA
> default produced a serial number with 63 bits of entropy.”
> 
> Deirdre’s note: unsigned ints are a thing y’all.

They can't (well, shouldn't).  Quoting RFC5280 section 4.1.1.1:

   The serial number MUST be a positive integer assigned by the CA to
   each certificate.

https://www.ietf.org/rfc/rfc5280.txt

Two paragraphs further on, the above gets slightly qualified:

  Note: Non-conforming CAs may issue certificates with serial numbers
  that are negative or zero.  Certificate users SHOULD be prepared to
  gracefully handle such certificates.

Looks like the real problem was that EJBCA defaults to using 63 bits
with a leading zero, and it took a while before someone realised that
this outcome failed to comply with CA Baseline Requirements Section 7.1:

  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.

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf

Arguably, EJBCA just should have padded S/Ns with an extra byte just to
be cautious, but presumably (not bearing in mind RFC5280 stealing a bit) 
they didn't realise they were shaving too close.  (The Ars Technica
article says Apple has now reconfigured its EJBCA to generate S/Ns with
with 16 octets.  Yeah, that'll do it.  The RFC specifies in the same
section that 'Certificate users MUST be able to handle serialNumber
values up to 20 octets', so Apple is making a reasonable and compatible
move.)

In context, this was not a catastrophic failure, just a minor one,
because loss of one bit of entropy wasn't enough to put certs in real
jeopardy.  If the MD5 hash algorithm were still in use to identify
certs, as it was in 2008 when that stunt of using 200 PS3 playstations
to generate certs with hash collisions and thus do believable forgeries,
there would have been an immediate problem because the hash collisions 
effectively stole additional bits of entropy.  But, these days, SHA256
hashing is used instead, and it lacks any such known weaknesses.

I was initially tempted to make some mocking comment about building a
Certificate Authority using Enterprise Java Beans ('EJBCA'), but, on
reflection, this is probably a suitable application for Java object
code, isn't it?

Schneier has very basic coverage of the story, but obviously hasn't had
time to say much:
https://www.schneier.com/blog/archives/2019/03/cas_reissue_ove.html