Hi
This is an incident report for two intermediate certificates issued by Buypass
in December 2016 noncompliant with BR 7.1.
===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.
We were following a discussion on mozilla.dev.security.policy (MDSP). On March
18th a list of CAs noncompliant with the entropy requirement in BR 7.1 was
published and two Root CAs from Buypass was included. We became aware of this
on March 21st and sent immediately a Pre-Incident Report to MDSP [1].
===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.
We did some analyses and identified that we had issued two intermediate CA
certificates on December 2nd 2016 without the required entropy in the
certificate serial number. At this point in time, the application software on
our offline Root CA system did not support the inclusion of random values in
the certificate serial number.
===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.
The application software on our offline Root CA system was later updated with
support for random values in certificate serial numbers. No more intermediate
certificates was issued in the meantime and we have since then not issued any
certificates noncompliant with BR 7.1 on the offline Root CA system.
===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.
Two intermediate certificates were issued December 2nd 2016. The intermediate
certificates are used for CAs issuing TLS certificates, i.e. Buypass Class 2 CA
2 and Buypass Class 3 CA 2.
===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.
The two certificates are:
- Buypass Class 2 CA 2 - https://crt.sh/?id=76748940
- Buypass Class 2 CA 3 - https://crt.sh/?id=76740810
===Explanation about how and why the mistakes were made or bugs introduced, and
how they avoided detection until now.
This entropy requirement was effective from September 30th 2016. At this point
in time we were not very concerned about the risk of using certificate serial
numbers with low entropy in certificates issued in our Root CA system [2]. The
Root CA system is operated offline/airgapped in a strictly controlled
environment by three security officers. Therefore, we focused on implementing
support for the entropy requirement in Subscriber certificates. At the time we
issued the intermediate certificates, in December 2016, our Root CA system did
not yet support random values in the certificate serial number.
===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.
The following actions has been taken:
- On March 25th we issued two new intermediate certificates for the
affected CAs with certificate serial numbers compliant with BR 7.1 on the
offline Root CA system
- These certificates replaces the two affected intermediate
certificates and are distributed to our customers together with all new TLS
certificates issued after March 25th
We have identified the next actions to be taken:
- We will communicate with existing customers and advise them to
replace the affected intermediate certificates with the new intermediates
- We will revoke the affected intermediate certificates when the risk
of introducing any main issues to our customers are considered to be acceptable
The offline Root CA system used has been updated and it will not be possible to
issue certificates noncompliant with BR 7.1 in the future.
Regards
Mads
[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/n1_sDXBmF_A/yQEz_kQ6BwAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/9MV5b2zGAQAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy