Thank you for the incident report. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1535873 to track this issue.
- Wayne On Wed, Mar 13, 2019 at 1:35 PM Doug Beattie via dev-security-policy < [email protected]> wrote: > 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) > > > > 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. > > When performing self-compliance check on our Trusted Root customers based > on > emails to mdsp list with similar issues. > > 2. 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. > > > 3. 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. > > 4. 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 > > 5. 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. > > 6. 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 > > 7. 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. > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
