Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

[Itzhak Daniel]

This practice seem to go back to Apr 2014.

Link: https://crt.sh/?dNSName=testslsslfeb20.me

[Itzhak Daniel]

I talked with Ofer from Incapsula, he said the domain exist at some point; Someone have access to domain tools or other tool to verify this matter? Based on domaintools I can say the domain did exist but I can't tell when it cease to exist.

https://research.domaintools.com/research/whois-history/search/?q=testslsslfeb20.me

There are several other domains, maybe someone can compose a better list:

https://censys.io/certificates?q=parsed.subject.common_name%3A+incapsula.com+and+parsed.extensions.subject_alt_name.dns_names%3A+test*ssl*%28jan%7Cfeb%7Cmar%7Capr%7Cmay%7Cjun%7Cjul%7Caug%7Csep%7Coct%7Cnov%7Cdec%29

[Gervase Markham]

On 26/02/17 00:50, Itzhak Daniel wrote:
> I talked with Ofer from Incapsula, he said the domain exist at some
> point; Someone have access to domain tools or other tool to verify
> this matter? Based on domaintools I can say the domain did exist but
> I can't tell when it cease to exist.

I think that without more evidence we must assume that GlobalSign
validated this domain correctly at a time when it existed.

Gerv

[Itzhak Daniel]

On Tuesday, February 28, 2017 at 1:38:25 PM UTC+2, Gervase Markham wrote:
> I think that without more evidence we must assume that GlobalSign
> validated this domain correctly at a time when it existed.

There are many more test*.* domains, non of those (about 10) I checked exist. I will compose a full list and reply.

I also would like to have an official reply from GlobalSign saying that "on the date they issue the certificate the domain exists".

[douglas...@gmail.com]

On the date that the certificate was issued it was verified in accordance with the Domain Verification requirements in the BRs.

Doug Beattie
GlobalSign

[Andrew Ayer]

On Tue, 28 Feb 2017 04:29:20 -0800 (PST)
Itzhak Daniel via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> I also would like to have an official reply from GlobalSign saying
> that "on the date they issue the certificate the domain exists".

Note that the BRs do not require a domain to exist when a CA issues a
DV/OV certificate for it. The BRs only require that the CA validated
the domain at some point in the 39 months prior to issuance.

I hope this can be changed, since it doesn't seem right that someone can
validate a domain once and still have a valid certificate for it 6.5
years later, even if the domain registration lapsed or changed hands.

Regards,
Andrew

[Nick Lamb]

On Tuesday, 28 February 2017 12:29:30 UTC, Itzhak Daniel wrote:
> I also would like to have an official reply from GlobalSign saying that "on the date they issue the certificate the domain exists".

Doug/ GlobalSign has responded but I'll mention here that lists of recently abandoned domain names (often used by speculators to pick up names that may get residual traffic or interest) include some of these names. This is useful independent evidence that (at least some of) the names did exist at one time.

e.g. http://domaingraveyard.com/list/2016-05-10.txt

[Nick Lamb]

On Tuesday, 28 February 2017 16:00:47 UTC, Nick Lamb wrote:
> e.g. http://domaingraveyard.com/list/2016-05-10.txt

Typical, I posted that and then I checked from another browser and it now gives an access error. Anyway, there are others of the same ilk out there, these names (at least some of them) existed, meaning there's reason to suppose mis-issuance.

[Itzhak Daniel]

On Tuesday, February 28, 2017 at 5:49:32 PM UTC+2, Andrew Ayer wrote:
> Note that the BRs do not require a domain to exist when a CA issues a
> DV/OV certificate for it. The BRs only require that the CA validated
> the domain at some point in the 39 months prior to issuance.

Sad to know. Pasting the ballot for future reference:
---
3.2.2.4. Validation of Domain Authorization or Control
The CA SHALL confirm that, as of the date the Certificate issues, either the CA
or a Delegated Third Party has validated each Fully‐Qualified Domain Name (FQDN)
listed in the Certificate using at least one of the methods listed below.

Completed confirmations of Applicant authority may be valid for the issuance of
multiple certificates over time. In all cases, the confirmation must have been
initiated within the time period specified in the relevant requirement (such as
Section 3.3.1 of this document) prior to certificate issuance. For purposes of
domain validation, the term Applicant includes the Applicant's Parent Company,
Subsidiary Company, or Affiliate.
---
3.3.1. Identification and Authentication for Routine Re‐key
Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY
use the documents and data provided in Section 3.2 to verify certificate information,
provided that the CA obtained the data or document from a source specified under
Section 3.2 no more than thirty‐nine (39) months prior to issuing the Certificate.

[Itzhak Daniel]

On Tuesday, February 28, 2017 at 6:00:47 PM UTC+2, Nick Lamb wrote:
> This is useful independent evidence that (at least some of) the names did exist at one time.

The problem is that they're "re-keying" certificates for domains that are no longer in control of their subscribers (as Andrew Ayer brought up, they're allowed to do that). I reviewed 4 certificates, out of the 38 domains I checked, 1 is alive and using Incapsula+GlobalSign cert (testslsslmay15.com).

https://crt.sh/?id=96720534:
Validity:
- Not Before: Feb 23 16:11:07 2017 GMT
- Not After : Aug 1 10:08:40 2017 GMT
X509v3 Subject Alternative Name:
- DNS:test-ssldomnew.com
- DNS:test02dec.com
- DNS:testmacsldec2.net
- DNS:testmacsldec2.org
- DNS:testmltdmnov28.net
- DNS:testmltdmslupslnov27.com
- DNS:testnov28.com
- DNS:testslsslnov26.mobi
- DNS:testyu6788.net

https://crt.sh/?id=97019485:
Validity:
- Not Before: Feb 24 16:19:16 2017 GMT
- Not After : Jul 18 07:58:51 2017 GMT
X509v3 Subject Alternative Name:
- DNS:testbetaslsslmay14.info
- DNS:testbetaslsslmay14.me
- DNS:testbetaslsslmay14.mobi
- DNS:testnovemberssl.com
- DNS:testslsslmay15.biz
- DNS:testslsslmay15.co
+ DNS:testslsslmay15.com
- DNS:testslsslmay15.info
- DNS:testssl2may22.com
- DNS:testsslonaug12.com

https://crt.sh/?id=97260721:
Validity:
- Not Before: Feb 25 09:39:46 2017 GMT
- Not After : Sep 26 06:39:49 2017 GMT
X509v3 Subject Alternative Name:
- DNS:mar28sitelocktesting.biz
- DNS:waftestingforsni.info
- DNS:sslonwafdomain.me
- DNS:testbetaslsslmay14.co
- DNS:testlpssl.com
- DNS:testslsslfeb20.org
- DNS:testslsslmay15.me

https://crt.sh/?id=97257790:
Validity:
- Not Before: Feb 25 19:32:50 2017 GMT
- Not After : Oct 3 13:53:31 2017 GMT
X509v3 Subject Alternative Name:
- DNS:slsslfeb17.com
- DNS:sslonwafdomain.biz
- DNS:sslonwafdomain.co
- DNS:testdiyaguru20131002b.com
- DNS:testdomainforwaf.mobi
- DNS:testregrroct6.org
- DNS:testslsslapr7.com
- DNS:testslsslfeb17.co
- DNS:testslsslfeb17.com
- DNS:testslsslfeb17.org
- DNS:testssllaunchmay23.info
- DNS:testssllivemay23.org

[Peter Kurrasch]

Would it be possible to get a more precise answer other than "in accordance with"? I am left to assume that in fact no verification was performed because the previous verification was in the 39 month window.


  Original Message  
From: douglas.beattie--- via dev-security-policy
Sent: Tuesday, February 28, 2017 6:46 AM‎

...snip...
‎

> I also would like to have an official reply from GlobalSign saying that "on the date they issue the certificate the domain exists".

On the date that the certificate was issued it was verified in accordance with the Domain Verification requirements in the BRs.

Doug Beattie
GlobalSign

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[douglas...@gmail.com]

On Wednesday, March 1, 2017 at 8:26:34 AM UTC-5, Peter Kurrasch wrote:
> Would it be possible to get a more precise answer other than "in accordance with"? I am left to assume that in fact no verification was performed because the previous verification was in the 39 month window.

For this SSL product, customers place orders which are vetted to the OV level with normally just a single SAN. Once the order has been approved they can add SANs by verifying domain control via DNS or File based verificaton options. Over time they add and remove SANs as their customer base changes. They can re-issue the certificate which keeps the expiration date and the subject DN the same, but they add and remove SANs.

In this case they did not remove SAN which are clearly not functional and are for domains which have expired. The reissueance process does not require the re-verification of the domain control, thus the certificate was reissued with these SANs.

Subscribers are required to tell us when the certificate contents is no-longer accurate so appropriate action can be taken, but clearly this customer did not inform us. We'll be talking with them about this to find out why.

Doug

[Ryan Sleevi]

On Wed, Mar 1, 2017 at 12:12 PM, douglas.beattie--- via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> On Wednesday, March 1, 2017 at 8:26:34 AM UTC-5, Peter Kurrasch wrote:

> > Would it be possible to get a more precise answer other than "in
> accordance with"? I am left to assume that in fact no verification was
> performed because the previous verification was in the 39 month window.
>

> For this SSL product, customers place orders which are vetted to the OV
> level with normally just a single SAN. Once the order has been approved
> they can add SANs by verifying domain control via DNS or File based
> verificaton options. Over time they add and remove SANs as their customer
> base changes. They can re-issue the certificate which keeps the expiration
> date and the subject DN the same, but they add and remove SANs.
>
> In this case they did not remove SAN which are clearly not functional and
> are for domains which have expired. The reissueance process does not
> require the re-verification of the domain control, thus the certificate was
> reissued with these SANs.
>
> Subscribers are required to tell us when the certificate contents is
> no-longer accurate so appropriate action can be taken, but clearly this
> customer did not inform us. We'll be talking with them about this to find
> out why.
>

Doug,

A few follow-ups:

This description is somewhat concerning in its omission - namely, whether
or not GlobalSign revalidates this information on the 39 month period
required by the Baseline Requirements.
Q1) Can you confirm that this system ensures that all domains are
revalidated if the validation occurred more than 39 months prior, as per
the Baseline Requirements, v1.4.2, Section 4.2.1
Q2) If, in the process of confirming a, deficiencies are noted in the
enforcement of this, can you provide details as to how many certificates
this issue might affect?

The Baseline Requirements, v1.4.2, Section 9.6.3 details obligations with
respect to the Subscriber Agreements that CAs SHALL require. As part of
this, Item 5, (b) notes that the Subscriber Agreement includes "An
obligation and warranty to: ... (b) promptly request revocation of the
Certificate, and cease using it, if any information in the Certificate is
or becomes incorrect or inaccurate." Per Section 4.9.1.1 of the Baseline
Requirements, "The CA SHALL revoke a Certificate within 24 hours if one or
more of the following occurs:" ... "The CA is made aware that a Subscriber
has violated one or more of its material obligations under the Subscriber
Agreement or Terms of Use".

Given that GlobalSign has acknowledged that the Subscriber has failed to
abide by the required Subscriber Agreement, and given that GlobalSign
acknowledged this at Tue, 28 Feb 2017 04:46:25 -0800 (PST), it would appear
that this certificate is not revoked, however, my attempts at confirming
with your OCSP server seem to at least produce issues on the several
Windows devices I tried.

Q3) Can you confirm that this certificate (and all related certificates)
are revoked, as per Section 4.9.1.1 of the Baseline Requirements?
Q4) Can you confirm that your OCSP responder is properly available? For
your ease of diagnostic, the Windows command is "certutil -f -urlfetch
-verify [certificatefile]", which other CAs' revoked and unrevoked
certificates are working fine with.

[Jakob Bohm]

I read his previous answer as saying that the system will in no case
extend the validity of a validation beyond the duration of the
certificate in which it was originally listed (that duration being
clearly visible in the certificates in question).

The only corner cases seemingly not answered are these:

Does GlobalSign allow (for this product) that initial inclusion of a SAN
within a subscription period to be accepted based on a previous
validation occurring more than 39 months before the last permitted
certificate reissuance with added/removed SANs?

Does GlobalSign allow other certificate products that can be freely
reissued within their validity period to be based on validation data
that could exceed the 39 month age limit before the certificate and its
reissuance option expires?

Conversely there are questions about what the BRs requires in such
corner cases:

Do the BRs require the 39 month age limit to be satisfied when a
certificate is reissued with unchanged subject data and expiry date,
(but with new serial and public key), thus expiring less than the BR
permitted maximum validity duration after an original issuance date
within that 39 month limit?

If the BRs do not require that, do they require this if a certificate
is reissued with unchanged expiry date and unchanged data for the
subject in question, but with changes for other subjects?

> Q2) If, in the process of confirming a, deficiencies are noted in the
> enforcement of this, can you provide details as to how many certificates
> this issue might affect?
>
> The Baseline Requirements, v1.4.2, Section 9.6.3 details obligations with
> respect to the Subscriber Agreements that CAs SHALL require. As part of
> this, Item 5, (b) notes that the Subscriber Agreement includes "An
> obligation and warranty to: ... (b) promptly request revocation of the
> Certificate, and cease using it, if any information in the Certificate is
> or becomes incorrect or inaccurate." Per Section 4.9.1.1 of the Baseline
> Requirements, "The CA SHALL revoke a Certificate within 24 hours if one or
> more of the following occurs:" ... "The CA is made aware that a Subscriber
> has violated one or more of its material obligations under the Subscriber
> Agreement or Terms of Use".
>
> Given that GlobalSign has acknowledged that the Subscriber has failed to
> abide by the required Subscriber Agreement, and given that GlobalSign
> acknowledged this at Tue, 28 Feb 2017 04:46:25 -0800 (PST), it would appear
> that this certificate is not revoked, however, my attempts at confirming
> with your OCSP server seem to at least produce issues on the several
> Windows devices I tried.

That's a bit harsh on the subscriber (for a simple failure to notify),
but probably within the legal requirements of the BRs.

>
> Q3) Can you confirm that this certificate (and all related certificates)
> are revoked, as per Section 4.9.1.1 of the Baseline Requirements?
> Q4) Can you confirm that your OCSP responder is properly available? For
> your ease of diagnostic, the Windows command is "certutil -f -urlfetch
> -verify [certificatefile]", which other CAs' revoked and unrevoked
> certificates are working fine with.
>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Ryan Sleevi]

Hi Jakob,

On Thu, Mar 2, 2017 at 9:14 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> I read his previous answer as saying that the system will in no case
> extend the validity of a validation beyond the duration of the
> certificate in which it was originally listed (that duration being
> clearly visible in the certificates in question).
>

For the avoidance of doubt or confusion, I suspect it would be best for
Doug to be able to answer the questions posed to Doug :)

> The only corner cases seemingly not answered are these:
>
> Does GlobalSign allow (for this product) that initial inclusion of a SAN
> within a subscription period to be accepted based on a previous
> validation occurring more than 39 months before the last permitted
> certificate reissuance with added/removed SANs?
>

I'm having trouble understanding what you're asking here. While I may be
the only one confused, perhaps you can reword this question?

> Does GlobalSign allow other certificate products that can be freely
> reissued within their validity period to be based on validation data
> that could exceed the 39 month age limit before the certificate and its
> reissuance option expires?
>

This is a similar question which I personally find confusingly worded, so
perhaps you can expand.

> Conversely there are questions about what the BRs requires in such
> corner cases:
>
> Do the BRs require the 39 month age limit to be satisfied when a
> certificate is reissued with unchanged subject data and expiry date,
> (but with new serial and public key), thus expiring less than the BR
> permitted maximum validity duration after an original issuance date
> within that 39 month limit?
>

The Baseline Requirements do not define reissue. Every certificate is new
issuance. There is no such thing as "reissue", even if two certificates are
markedly similar in various aspects.

The Baseline Requirements allow you to validate at T=0, issue at T=38 for
L=39, where T means 'time' (and 38 just means 'one second before 39
months') and L means lifetime.

However, if a new certificate is issued - with new serial and public key,
at T=40, the Baseline Requirements require this information be revalidated.

> That's a bit harsh on the subscriber (for a simple failure to notify),
> but probably within the legal requirements of the BRs.

Why is it harsh? CAs are required to revoke such certificates. The fact
that the Subscriber Agreement was simply one way of describing the
Revocation Requirements. GlobalSign is equally obligated to revoke under
4.9.1.1, Item 6, which states

"6. The CA is made aware of any circumstance indicating that use of a
Fully-Qualified Domain Name or IP
address in the Certificate is no longer legally permitted (e.g. a court or
arbitrator has revoked a Domain Name
Registrant’s right to use the Domain Name, a relevant licensing or services
agreement between the Domain
Name Registrant and the Applicant has terminated, or the Domain Name
Registrant has failed to renew the
Domain Name); "

[Jakob Bohm]

On 03/03/2017 06:44, Ryan Sleevi wrote:
> Hi Jakob,
>
>
> On Thu, Mar 2, 2017 at 9:14 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>>
>> I read his previous answer as saying that the system will in no case
>> extend the validity of a validation beyond the duration of the
>> certificate in which it was originally listed (that duration being
>> clearly visible in the certificates in question).
>>
>
> For the avoidance of doubt or confusion, I suspect it would be best for
> Doug to be able to answer the questions posed to Doug :)
>

Of cause, I was trying to help the process along by separating that
which seems obvious from previous answers (but might need trivial
confirmation) from that which remains truly open questions.

>
>> The only corner cases seemingly not answered are these:
>>
>> Does GlobalSign allow (for this product) that initial inclusion of a SAN
>> within a subscription period to be accepted based on a previous
>> validation occurring more than 39 months before the last permitted
>> certificate reissuance with added/removed SANs?
>>
>
> I'm having trouble understanding what you're asking here. While I may be
> the only one confused, perhaps you can reword this question?

Suppose that at T1=x, a subscriber to this GlobalSign product obtained
a certificate with lifertime L=y, with permission to add/remove from
the list of included SANs until T3=x+y, each time keeping the cert
expiry value at T3=x+y. (This is what GlobalSign described in their
previous answer).

Suppose also, that when such updates are done at T2 < x+y, GlobalSign
does not revalidate those SANs that are not changed at time T2 (this
also seems to be what GlobalSign described in their previous answer,
but is less clear).

Now does GlobalSign ensure, at time T1=x that the validation data that
can be thus reused until time T3=x+y was obtained on or after T0=x+y-39,
thereby ensuring that it will be less than 39 months old at any time T2
permitted by the above assumptions?

>
>
>> Does GlobalSign allow other certificate products that can be freely
>> reissued within their validity period to be based on validation data
>> that could exceed the 39 month age limit before the certificate and its
>> reissuance option expires?
>>
>
> This is a similar question which I personally find confusingly worded, so
> perhaps you can expand.
>

A number of GlobalSign's certificate products (perhaps most of them)
allow the certificate holder to request a reissuance with a new public
key and serial number at any time until expiry.

Question is if GlobalSign ensures that the validation data used at
issuance time T1=x with lifetime/reissuance permission L=y was obtained
on or after T0=x+y-39, as is required according to your interpretation
of the BRs.

>
>> Conversely there are questions about what the BRs requires in such
>> corner cases:
>>
>> Do the BRs require the 39 month age limit to be satisfied when a
>> certificate is reissued with unchanged subject data and expiry date,
>> (but with new serial and public key), thus expiring less than the BR
>> permitted maximum validity duration after an original issuance date
>> within that 39 month limit?
>>
>
> The Baseline Requirements do not define reissue. Every certificate is new
> issuance. There is no such thing as "reissue", even if two certificates are
> markedly similar in various aspects.
>
> The Baseline Requirements allow you to validate at T=0, issue at T=38 for
> L=39, where T means 'time' (and 38 just means 'one second before 39
> months') and L means lifetime.
>
> However, if a new certificate is issued - with new serial and public key,
> at T=40, the Baseline Requirements require this information be revalidated.
>

But is this stated explicitly, or simply an interpretation?

>
>> That's a bit harsh on the subscriber (for a simple failure to notify),
>> but probably within the legal requirements of the BRs.
>
>
> Why is it harsh? CAs are required to revoke such certificates. The fact
> that the Subscriber Agreement was simply one way of describing the
> Revocation Requirements. GlobalSign is equally obligated to revoke under
> 4.9.1.1, Item 6, which states
>
> "6. The CA is made aware of any circumstance indicating that use of a
> Fully-Qualified Domain Name or IP
> address in the Certificate is no longer legally permitted (e.g. a court or
> arbitrator has revoked a Domain Name
> Registrant’s right to use the Domain Name, a relevant licensing or services
> agreement between the Domain
> Name Registrant and the Applicant has terminated, or the Domain Name
> Registrant has failed to renew the
> Domain Name); "
>

As this seems to be a multi-SAN certificate for some kind of hosting
provider (based on the descriptions of the how the "product" works),
quickly and suddenly revoking the certificate for all the currently
hosted domains because the hosting provider was late in reporting that
some other domain names should be removed from the shared certificate
would be disruptive to those other domains.

Noting that the potential for abuse would be limited to this supposedly
legitimate hosting provider participating in an attack that would
redirect a formerly hosted domain name to a server with access to the
hosting providers private key and a willingness to provide content for
that domain name (rather than a "no longer hosted here" or
"unconfigured domain" error page).

Hence my suggestion that a more cooperative (but slower) procedure for
replacing the certificate with one that contains only currently
permitted domains might be acceptable.

[Ryan Sleevi]

On Thu, Mar 2, 2017 at 11:03 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> But is this stated explicitly, or simply an interpretation?
>

Yes. Section 4.2.1

> As this seems to be a multi-SAN certificate for some kind of hosting
> provider (based on the descriptions of the how the "product" works),
> quickly and suddenly revoking the certificate for all the currently
> hosted domains because the hosting provider was late in reporting that
> some other domain names should be removed from the shared certificate
> would be disruptive to those other domains.
>

That's explicitly what the Baseline Requirements require. Multiple
different ways. Within 24 hours.

I can understand the desire to "not be disruptive". The Baseline
Requirements have instead optimized for "Be accurate representations of the
domain binding".

Hence my suggestion that a more cooperative (but slower) procedure for
> replacing the certificate with one that contains only currently
> permitted domains might be acceptable.

It is not acceptable. It's explicitly prohibited multiple ways to allow
more than 24 hours when such situations are brought to the CAs' attention.

[Nick Lamb]

On Friday, 3 March 2017 07:49:28 UTC, Ryan Sleevi wrote:
> It is not acceptable. It's explicitly prohibited multiple ways to allow
> more than 24 hours when such situations are brought to the CAs' attention.

I'm sympathetic to the idea, here and in all cases where we have no reason to suppose the initial issuance was fraudulent, that the CA ought to reach out to the subscriber to give them a chance to minimise the impact of necessary revocations.

However, CAs have indicated elsewhere, as you know, that their customers may need up to three months to act, hence the 39 rather than 36 month limit on certificate lifetimes. It's not practical to wait for that, and even the implication that you _might_ wait actually slows down the response from most subscribers, because emergency changes are subject to less inertia.

[douglas...@gmail.com]

I wanted to send out a short update of were we are on looking into the reported Incapusla/testslsslfeb20.me certificate and the thread of comments and questions above.

In this specific case the domain was verified within 39 months of issuance/reissuance (no difference as Ryan pointed out).

In general, when we receive new orders and issue certificates, the vetting is done just prior to issuance time which permits the certificate to be replaced up until expiration. We're looking into cases where new "orders" may have used certificate data that was done prior and then verifying that the domains (and enterprise data on the subject DN) are re-verified at the applicable intervals.

I'll send out an update as soon I have more information.

Doug

[Gervase Markham]

On 03/03/17 20:59, douglas...@gmail.com wrote:
> In general, when we receive new orders and issue certificates, the
> vetting is done just prior to issuance time which permits the
> certificate to be replaced up until expiration. We're looking into
> cases where new "orders" may have used certificate data that was done
> prior and then verifying that the domains (and enterprise data on the
> subject DN) are re-verified at the applicable intervals.
>
> I'll send out an update as soon I have more information.

Hi Doug,

Any update? Once you report back, if nothing terrible is found, I think
we can consider this matter resolved.

Gerv

[douglas...@gmail.com]

Misissuance Report

On February 25th 2017, we received a report that there was a SAN in an Incapsula OV certificate (specifically an OV certificate issued via the GlobalSign CloudSSL product) for a domain that is no longer registered (testsslfeb20.me).


1) GlobalSign CloudSSL product description

To help clarify what we mean by GlobalSign CloudSSL product we wanted to describe the different operations CloudSSL customers can perform. CloudSSL supports New, Update, Reissue and Renew operations which all result in a new certificate being created.

* New: We perform a manual organization validation on the initial CloudSSL OV certificate and CommonName. We assign a new OrderID.

* Update: Customers can request the addition and removal of SANs. When a SAN is added, it is validated (in accordance with one of the approved domain validation methods) and then when the Update command is called, a new certificate with the requested changes is issued. The issued certificate has the same Subject DN, expiration date and OrderID.

* Renew: When a CloudSSL order is renewed, it retains the same OrderID and Subject DN but the validity period is extended by 1-2 years.

* Reissue: When a CloudSSL certificate is Reissued, it receives a new OrderID, but contains the same Subject DN, cert expiration date and SANs.

* Revocation: The GlobalSign CA performs revocation by OrderID. This revokes all certificates in the Order which could be hundreds for CloudSSL orders.
CloudSSL is the only GlobalSign SSL product where multiple certificates are issued against the same OrderID.

In general, CloudSSL customers need large multi-domain SSL certificates which have SANs added and removed to support their changing customer needs. As such, updating certificates is a more frequent activity that with any other GlobalSign SSL products.


2) Incapsula certificates issued with testslsslfeb20.me

We investigated this order and determined that this domain was verified when the certificate was first issued on 3/31/2014. While this order was issued and subsequently updated and reissued a number of times without breaking the 39 month certificate data re-use period, it’s clear that based on this report the domain is no longer controlled by Incapsula. At the conclusion of this analysis we revoked two OrderIDs that contained this SAN which resulted in the revocation of 26 certificates with this SAN.

All unexpired certificates with this SAN are now revoked as can be seen on the page:
https://crt.sh/?dNSName=testslsslfeb20.me


3) Research to verify all domains are being validated every 39 months

After this initial review, we further investigated the time between the initial SAN approval and inclusion of the SAN in future certificates. We found that not all SANs have been validated within the prior 39 months due to a product bug. CloudSSL was not updated in February 2015 when the 39 month certificate data re-use policy was added to the BRs, thus domains were being included in reissued certificates without having updated domain verification checks performed. This product was launched in late 2011, so some SANs had reached their 39 month limit in February 2015, and some of those continued to be included in certificates through March 2017.


4) Resolution

As soon as this was discovered, the system was patched on 3/16 to prevent additional certificates from being issued with SANs not validated within the prior 39 months.


5) Follow-up tasks

The reporting interface and capabilities of the CA system to identify and revoke the impacted certificates was inadequate to properly locate impacted customers and OrderIDs which we needed to process. While some of them were identified and revoked relatively quickly, it took several weeks to set up a new database and reporting infrastructure which could be used to load and then correlate all of the certificates and SANs with the SAN approval dates and then notify customers and perform the revocations. Several rounds of reporting uploads, reporting and customer revocation updates were needed to completely capture the list of non-compliant certificates and revoke them.

In summary the following are the final statistics:

* 7 customers
* 79 OrderIDs had certificates revoked
* 945 unique SANs were included in certificates where the domain was not verified within the prior 39 months.
* 905 Certificates were issued containing one or more SANs that has not been verified within the prior 39 months. These SANs were either removed from future certificates or they were re-validated.

We've been actively working with 17 customers on 146 Orders and about 4000 SANs which expired on April 22 in order to comply with the 825 day data reuse policy. Checks were put in place to prevent certificates from being issued that contain SANs not validated within the prior 825 days prior to April 20th effective date.


6) Future Mitigation plans

While we've put checks in place to prevent SANs from being included if they were verified more than 825 days ago, we plan to end of life this product platform within the next 12 months. As part of this change, we will require CloudSSL customers to verify domains every 15 months to further limit the inclusion of SANs that should no-longer being included in certificates and to catch domains like testslsslfeb20.me that become unregistered.