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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
