Hi Nick, I updated our Mozilla ticket this this info and I wanted to also supply it here because it answers your questions also https://bugzilla.mozilla.org/show_bug.cgi?id=1552586
Here is an update to this incident: 5/20: After further analysis of the issue, it was determined that the cause was not the V1 API in general, but that there was a missing check for CN/SAN validation which was being skipped in a certain scenario. Specifically, when the "AEG" product code was being used, this check was skipped. Typically the AEG product code is used for non-public SSL certificates, and we found that the conditional CN/SAN check for the publicly trust thread was not being executed. 5/21: We rolled out updated code that now properly checks the CN and SAN values for the AEG product code. We also rolled back the V1 support to permit continued use of that API. While it's not being used for certificate issuance, it was being used for some other functions that impacted customer operations for the prior few days. We reviewed all certificates issued via this product code and found that these were the only 4 that didn't comply. Others have asked if we had skipped any other checks, like CAA, when following this AEG product thread. Over the past few days we've reviewed the code and threads and have determined that no other required checks or validations were skipped. Organization and Domain validation is done via our Enterprise model and these certificate requests all were subject to those constraints. We're continuing to inspect the AEG thread to double and triple check that no other required validation steps were missed and will report back if we find anything new to report, but at this point I believe that we can close this incident. Doug -----Original Message----- From: Nick Lamb <n...@tlrmx.org> Sent: Saturday, May 18, 2019 3:02 AM To: dev-security-policy@lists.mozilla.org Cc: Doug Beattie <doug.beat...@globalsign.com> Subject: Re: GlobalSign misissuance: 4 certificates with invalid CN On Fri, 17 May 2019 21:11:41 +0000 Doug Beattie via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > Today our post issuance checker notified us of 4 certificates were > issued with invalid CN values this afternoon. > > > > We posted our incident report here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1552586 Thanks Doug, I have two questions that seem relevant to this incident, because it is reminiscent of problems we had with the sprawl of issuance systems under Symantec 1. I have examined one of the certificates and I see it contains a bogus SAN dnsName matching the CN. Please let us know which constraints that should be in place weren't in place for this API, for example could the customer have successfully obtained a certificate for a FQDN which has CAA policy saying GlobalSign should not issue ? 2. The API is described as "deprecated" but I'd like more details to understand what that means from a practical standpoint. A subscriber was able (and by the sound of things continues to be able) to cause issuance through this API - was there already a specific date after which GlobalSign had announced (to such customers) that the API would cease availability? Is an equivalent, but so far as you understand compliant, replacement API for these customers already available ? How should a GlobalSign customer have known this API (or software using it) was deprecated and when they needed to stop using it? "In coordination with the customer, we are assured that no more non-compliant certificates will be issued" certainly reads to me like you know this API could issue more non-compliant certs right now, but you're content to let a subscriber pinky swear not to do so. I don't think that's what Mozilla has in mind with the phrase "a pledge to the community" but perhaps Wayne disagrees. Nick.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
