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
Sent: Saturday, May 18, 2019 3:02 AM
To: dev-security-policy@lists.mozilla.org
Cc: Doug Beattie
Subject: Re: GlobalSign misissuance: 4 certificates with invalid CN
On Fri, 17 May 2019 21:11:41 +
Doug Beattie via dev-security-policy
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
