GlobalSign misissuance: 4 certificates with invalid CN

[Doug Beattie]

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



In summary, 4 certificate were issued from an API that had been depreciated,
but not functionally disabled. All customers were migrated from this API
but the API was not disabled. One of our custom on-premise applications was
misconfigured to use this old API.



The CN of the certificates is: "madmin's macboo.int.mlsel.com" They were
immediately revoked.



Additional detail and ongoing status will be posted in the Mozilla incident.

[Nick Lamb]

On Fri, 17 May 2019 21:11:41 +0000
Doug Beattie via dev-security-policy

<dev-secur...@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.

[Richard Moore]

On Friday, May 17, 2019 at 10:11:55 PM UTC+1, Doug Beattie wrote:
> All customers were migrated from this API
> but the API was not disabled.
>One of our custom on-premise applications was
> misconfigured to use this old API.
>

This text in your mail seems to imply that customers were migrated away and that the remaining application was an internal application that was part of your estate. This is contradicted by the details in your bug report that states the application while provided by yourselves was used by a 3rd party and allowed them to issue certificates with unvalidated common names.

1. If it was possible for the customer to issue certificates with no technical control on the CN then what guarantees do you have that other certificates issued by this API were correctly validated? For example have you revalidated all such certificates?

2. What failures in process allowed an API that issues unvalidated certificates to be left in a usable state? How will these be addressed?

3. Do you have other deprecated but still usable APIs that allow issuance?
(this is partly addressed by your comments in the ticket).

Rich

[Doug Beattie]

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