Certificates with reserved IP addresses

[Jonathan Rudenberg]

Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from containing IANA reserved IP addresses and any certificates containing them should have been revoked by 2016-10-01.

There are seven unexpired unrevoked certificates that are known to CT and trusted by NSS containing reserved IP addresses.

The full list can be found at: https://misissued.com/batch/7/

DigiCert
TI Trust Technologies Global CA (5)
Cybertrust Japan Public CA G2 (1)

PROCERT
PSCProcert (1)

It’s also worth noting that three of the "TI Trust Technologies” certificates contain dnsNames with internal names, which are prohibited under the same BR section.

Jonathan

[Ben Wilson]

Thanks. We've sent an email to the operators of the first two CAs (TI Trust Technologies and Cybertrust Japan) that they need to revoke those certificates.
Thanks again,
Ben

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

[Peter Bowen]

Congratulations on finding something not caught by certlint. It turns
out that cabtlint does zero checks for reserved IPs. Something else
for my TODO list.

[Jeremy Rowley]

The CTJ one was issued in 2013 and is a five year cert (which was also prohibited under the BRs at that time_. It should have been revoked much earlier, of course.

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Saturday, August 12, 2017 7:53 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Certificates with reserved IP addresses

[Ryan Sleevi]

Do you have an estimate on when you can provide an explanation to the
community about how/why this happened, how many certificates it affected,
and what steps DigiCert is taking to prevent these issues in the future? Do
you have details about why DigiCert failed to detect these, and what steps
DigiCert has in place to ensure compliance from its subordinate CAs?

On Sat, Aug 12, 2017 at 10:19 PM, Ben Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Thanks. We've sent an email to the operators of the first two CAs (TI
> Trust Technologies and Cybertrust Japan) that they need to revoke those
> certificates.
> Thanks again,
> Ben
>

[Ben Wilson]

We’ll look into these on Monday and get back to you.

From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Saturday, August 12, 2017 8:56 PM
To: Ben Wilson <ben.w...@digicert.com>
Cc: Jonathan Rudenberg <jona...@titanous.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificates with reserved IP addresses



Do you have an estimate on when you can provide an explanation to the community about how/why this happened, how many certificates it affected, and what steps DigiCert is taking to prevent these issues in the future? Do you have details about why DigiCert failed to detect these, and what steps DigiCert has in place to ensure compliance from its subordinate CAs?

On Sat, Aug 12, 2017 at 10:19 PM, Ben Wilson via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:

Thanks. We've sent an email to the operators of the first two CAs (TI Trust Technologies and Cybertrust Japan) that they need to revoke those certificates.
Thanks again,
Ben


-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+ben <mailto:dev-security-policy-bounces%2Bben> =digice...@lists.mozilla.org <mailto:digice...@lists.mozilla.org> ] On Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Saturday, August 12, 2017 7:53 PM
To: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Certificates with reserved IP addresses

Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from containing IANA reserved IP addresses and any certificates containing them should have been revoked by 2016-10-01.

There are seven unexpired unrevoked certificates that are known to CT and trusted by NSS containing reserved IP addresses.

The full list can be found at: https://misissued.com/batch/7/

DigiCert
TI Trust Technologies Global CA (5)
Cybertrust Japan Public CA G2 (1)

PROCERT
PSCProcert (1)

It’s also worth noting that three of the "TI Trust Technologies” certificates contain dnsNames with internal names, which are prohibited under the same BR section.

Jonathan
_______________________________________________
dev-security-policy mailing list

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

https://lists.mozilla.org/listinfo/dev-security-policy


_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Ben Wilson]

Dear Ryan,



Here is an initial, interim response to your email as it relates to certificates issued by the TI Trust Technologies Global CA. (Jeremy Rowley or I will be sending you a separate email shortly that reports on this issue with regard to Cybertrust Japan.) I will supplement this response as more information becomes available.



Explanation to the community about how/why this happened: Apparently Telecom Italia Trust Technologies does not have adequate Baseline-Requirements filters in place to catch these.



How many certificates it affected: Only the 5 listed at <https://misissued.com/batch/7/> https://misissued.com/batch/7/, as far as we know.



What steps DigiCert is taking to prevent these issues in the future?: As a result of this and other recent issues, DigiCert is bringing certificate issuance for TI Trust Technologies in-house. We will be revoking CA certificate serial no. ‎07279ca7 issued to TI Trust Technologies Global CA. The key ceremony to create a new in-house CA is scheduled for Wednesday, 23 August, 2017.



Do you have details about why DigiCert failed to detect these, and what steps DigiCert has in place to ensure compliance from its subordinate CAs? DigiCert uses some of the same tools used by others to monitor and detect mis-issuance by external, cross-certified CAs. These include crt.sh, cablint, and Censys.IO. As illustrated in this case, external CAs may be revoked if they do not comply. Whenever DigiCert is made aware of the non-compliance of an external CA, it contacts the operator of that CA and requests that non-compliant certificates be revoked, that the CA scan its records for other certificates with the same infirmity, and that it patch its systems so that the issue does not recur. On a proactive basis, DigiCert regularly advises external CAs of new requirements in the Baseline Requirements or browser root programs and asks these external CAs to ensure their ongoing compliance. Contracts with such entities also require compliance with the requirements.



Sincerely yours,



Ben



Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678

[Jeremy Rowley]

Hey Ryan,

Here's the report from CTJ:

Number of affected certificates:
One. After receiving the revocation request from DigiCert, CTJ scanned their certificate database for additional certificates. This is the only active certificate with a reserved IP. CTJ issued the g2-sanfull01.ctjssl.info for its own use.

Cause of missing the revocation:
This certificate was identified as requiring revocation back in February 2016. When this issued, they had already blocked all renewals and issuance of certificates with internal names/IP addresses. Although the certificate was scheduled for revocation after CTJ moved away using the IP address, they forgot to revoke this last cert. Because it was one certificate, CTJ did not automate the revocation, making it subject to human error and forgetfulness.

Remediation actions:
CTJ is revoking this cert. CTJ is also implementing a CABLint-like process to check all certificates each time industry standards change. They are scanning crt.sh daily to verify the compliance of all new certs.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Saturday, August 12, 2017 8:56 PM
To: Ben Wilson <ben.w...@digicert.com>
Cc: Jonathan Rudenberg <jona...@titanous.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificates with reserved IP addresses

Do you have an estimate on when you can provide an explanation to the community about how/why this happened, how many certificates it affected, and what steps DigiCert is taking to prevent these issues in the future? Do you have details about why DigiCert failed to detect these, and what steps DigiCert has in place to ensure compliance from its subordinate CAs?

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

https://lists.mozilla.org/listinfo/dev-security-policy

[Gervase Markham]

On 14/08/17 21:32, Ben Wilson wrote:
> What steps DigiCert is taking to prevent these issues in the future?:
> As a result of this and other recent issues, DigiCert is bringing
> certificate issuance for TI Trust Technologies in-house. We will be
> revoking CA certificate serial no. ‎07279ca7 issued to TI Trust
> Technologies Global CA. The key ceremony to create a new in-house CA
> is scheduled for Wednesday, 23 August, 2017.

TI Trust Technologies has two intermediate certificates in the CCADB -
the one mentioned above:

https://ccadb.my.salesforce.com/001o000000cdd4t

and this one, serial number 0727bfc4:

https://ccadb.my.salesforce.com/001o000000cdd61

Is the plan to revoke that one also?

For the information of the group, here is the WebTrust audit for this
subCA, done by Ernst and Young:
https://cert.webtrust.org/SealFile?seal=2206&file=pdf

Gerv

[Ben Wilson]

Gerv,

Yes. We'll be revoking both of those. A date is yet to be determined.

Ben