Doug Beattie posted the following incident report to the mozilla.dev.security.policy mailing list on 13-March:
When the serial number issue was first disclosed we reviewed all GlobalSign
certificates issued from our systems and found no issues wrt serial number
length. While all GlobalSign systems are compliant, one of our customers
running an on-premise CA that chains to a GlobalSign root, AT&T, uses EJBCA
and has been using the default configuration. They have been notified to
immediately stop issuance, update their configurations, replace and then
revoke all affected certificates.
Their Intermediate CA is: https://crt.sh/?caid=10154
Under that CA they have 3 CAs, and here is the estimated number of
non-compliant active certificates:
https://crt.sh/?caid=10155 (fewer than 200 active certificates)
https://crt.sh/?caid=12658 (14 active 10-day certificates)
https://crt.sh/?caid=10157 (4 active certificates)
- How your CA first became aware of the problem (e.g. via a problem report
submitted to your Problem Reporting Mechanism, a discussion in
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and
the time and date.
When performing self-compliance check on our Trusted Root customers based on
emails to mdsp list with similar issues.
- A timeline of the actions your CA took in response. A timeline is a
date-and-time-stamped sequence of all relevant events. This may include
events before the incident was reported, such as when a particular
requirement became applicable, or a document changed, or a bug was
introduced, or an audit was done.
3/1/2019: GlobalSign self-assessment on certificates issued from our data
center. All certificates are compliant as we had set sufficient serial
number lengths prior to the CABF requirement to move to 64 bits of entropy.
3/13/2019: GlobalSign initiated and completed assessment of SSL certificates
issued by our 3 remaining customers that have CAs chaining to GlobalSign
roots. We observed that one of these customers, AT&T, uses EJBCA with the
default serial number settings.
- Whether your CA has stopped, or has not yet stopped, issuing certificates
with the problem. A statement that you have will be considered a pledge to
the community; a statement that you have not requires an explanation.
We have informed AT&T to stop issuance and will confirm that this is the
case tomorrow morning.
- A summary of the problematic certificates. For each problem: number of
certs, and the date the first and last certs with that problem were issued.
Initial reporting indicates there are fewer than 200 active certificates.
The links above can be used to identify the detailed list of certificates
and we will compile a complete list based on input from AT&T
- The complete certificate data for the problematic certificates. The
recommended way to provide this is to ensure each certificate is logged to
CT and then list the fingerprints or crt.sh IDs, either in the report or as
an attached spreadsheet, with one list per distinct problem.
We will compute a report shortly, but currently the scope is limited to the
3 CAs are listed above. Every active certificate under these CAs has serial
numbers that contain fewer than 64 bits of entropy.
- Explanation about how and why the mistakes were made or bugs introduced,
and how they avoided detection until now.
We will collect this information from AT&T in the coming days
- List of steps your CA is taking to resolve the situation and ensure such
issuance will not be repeated in the future, accompanied with a timeline of
when your CA expects to accomplish these things.
We are working with AT&T to correct this problem. Our plans to revoke these
CAs and to terminate all Trusted Root SSL CAs is on track for August.