[cabfpub] Incident report: Internal names in certs expiring after 1st November 2015
rob.stradling at comodo.com
Mon Nov 9 02:12:02 MST 2015
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.
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
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.
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
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:
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.
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the Public