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

[douglas.beattie--- via dev-security-policy]

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 

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

[Gervase Markham via dev-security-policy]

On 03/03/17 20:59, douglas.beat...@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[douglas.beattie--- via dev-security-policy]

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

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

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

[Nick Lamb via dev-security-policy]

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

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

[Ryan Sleevi via dev-security-policy]

Hi Jakob,


On Thu, Mar 2, 2017 at 9:14 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@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); "
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

On 02/03/2017 00:59, Ryan Sleevi wrote:

On Wed, Mar 1, 2017 at 12:12 PM, douglas.beattie--- via dev-security-policy
 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


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, 

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

[douglas.beattie--- via dev-security-policy]

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

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

[Peter Kurrasch via dev-security-policy]

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

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

[Itzhak Daniel via dev-security-policy]

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

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

[Nick Lamb via dev-security-policy]

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

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

[Nick Lamb via dev-security-policy]

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

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

[douglas.beattie--- via dev-security-policy]

On Tuesday, February 28, 2017 at 7:29:30 AM UTC-5, Itzhak Daniel wrote:
> 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".

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

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

[Itzhak Daniel via dev-security-policy]

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

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

[Gervase Markham via dev-security-policy]

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

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

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

[Itzhak Daniel via dev-security-policy]

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