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