[cabfpub] Incident report: Internal names in certs expiring after 1st November 2015

[Rob Stradling]

SUMMARY:
The BRs, since v1.0, have stated this requirement:
   "Also as of the Effective Date, the CA SHALL NOT issue a certificate
    with an Expiry Date later than 1 November 2015 with a
    subjectAlternativeName extension or Subject commonName field
    containing a Reserved IP Address or Internal Server Name."

On 5th November 2015, as part of our ongoing efforts to ensure 
compliance with the BRs, we conducted a search for any certificates with 
notBefore >= 2nd November 2015 that chain to publicly trusted roots and 
include any Internal Names or Reserved IP Addresses.  We found a few 
such certs that were issued by Comodo's CA system.

DETAILED DESCRIPTION OF IMPACT:
We immediately set about investigating and found that there was a subtle 
bug in a code change that we had deployed to our CA system on 30th 
October 2015.  The intent of this code change was to help ease the pain 
of the 1st November 2015 transition, by automatically deleting all 
Internal Names and Reserved IP Addresses from a certificate request just 
prior to issuing the certificate.  (We'd come to the conclusion that 
customers would probably rather have a cert containing a subset of the 
names they'd asked for than have no cert at all).
Prior to the 30th October 2015 code change, our CA system had correctly 
limited the notAfter date (to no later than 1st November 2015) for all 
certs we issued that contain Internal Names or Reserved IP Addresses. 
The code change removed that notAfter limiting behaviour, since it 
should no longer have been necessary given that the Internal Names and 
Reserved IP Addresses were being deleted prior to issuance.

ROOT CAUSE:
The nature of the bug is that our certificate issuance code still saw 
the "deleted" names.  (The developer had not realized that our 
certificate issuance code runs in a separate SQL context, and so it was 
necessary to commit the deletions immediately).
Despite our code review and QA processes, this bug still made it into 
production code.

REMEDIATION:
We prepared a hotfix for this problem, which we deployed within a couple 
of hours of our initial discovery of the bug.
The affected customers have been contacted and the affected certificates 
have been revoked.

PREVENTION:
We regret that our implementation of this important and long-trailed 
policy change fell below the standards that are expected of us and that 
we expect of ourselves.
We will further improve the Quality Control measures in our change 
control process around functions of our CA as policy changes are 
implemented.

TRANSPARENCY:
After we'd deployed the hotfix, we searched our CA database to find all 
the certificates we'd issued that, due to the bug, are not compliant 
with the BRs.  We found a total of 8, of which 2 were already known to 
CT.  In the interest of full transparency, we submitted the other 6 to 
CT on 5th November.  You can view them all via crt.sh:

https://crt.sh/?id=10518413
https://crt.sh/?id=10529867
https://crt.sh/?id=10555427
https://crt.sh/?id=10555441
https://crt.sh/?id=10555442
https://crt.sh/?id=10555446
https://crt.sh/?id=10556437
https://crt.sh/?id=10565225

OTHER CAs:
We widened our investigation to look for certificates with notBefore >= 
2nd November 2014 that chain to publicly trusted roots and include any 
Internal Names or Reserved IP Addresses.  We found non-compliant 
certificates issued by quite a number of other CAs, but I'll document 
these in another post.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online