1451950 - DigiCert: Intermediate Cert(s) not disclosed in CCADB

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

The DigiCert CA has one or more intermediate certs that are not disclosed in the Common CA Database (CCADB).

https://crt.sh/mozilla-disclosures#undisclosed

Mozilla's Root Store Policy:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#publicly-disclosed-and-audited
"All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly or transitively chain to a certificate included in Mozilla’s root program MUST be audited in accordance with Mozilla’s Root Store Policy and MUST be publicly disclosed in the CCADB by the CA that has their certificate included in Mozilla’s root program."

How to disclose intermediate certs in the CCADB:
https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data

Comment 1

[Jeremy Rowley]

Isn't the due date to upload existing client cert ICAs April 15th? None of these are new ICAs.

Comment 2

[Jeremy Rowley]

Per the January 2018 communication: "ACTION 3: Disclose All Non-Technically-Constrained Subordinate CA Certificates Sections 5.3.1 and 5.3.2 of Mozilla Root Store Policy version 2.5 require CAs to publicly disclose (via CCADB) all subordinate CA certificates including those used to issue email S/MIME certificates by 15-January unless they are technically constrained via both EKU and Name Constraints to a set of validated domains. We have since changed the compliance deadline to 15-April 2018. Certificate monitors have detected over 200 certificates that currently do not comply with this new policy. Please ensure that your CA is in compliance before 15-April 2018. Please select the correct response for your CA:"

Comment 3

[Wayne Thayer]

The deadline is for S/MIME intermediates. The report says this one (SCEE) is enabled for serverAuth.

Comment 4

[Jeremy Rowley]

Which one? I'm not seeing one on the links posted.

Comment 5

[Ryan Sleevi]

https://crt.sh/?sha256=28cad66d2c81d77b177a021561f0e34d7899f4331d61336f435107ca220d0aa7&opt=mozilladisclosure

Comment 6

[Ben Wilson]

I have uploaded these two CAs to the CCADB.

Comment 7

[Wayne Thayer]

They are still showing under "additional disclosure required". Looks like you need to fill out the audit & CP/CPS info.

Comment 8

[Vitor Castro]

I'm member of the Portuguese Mint that manage and operate this two certification authorities.

This two certification authorities don't issue SSL/TLS certificates, they just issue certificates for authentication and digital signing of documents, both enrolled inside the chip of the eID smartcard that are issued for all the Portuguese Citizens.

This CA https://crt.sh/?id=341674988, just issue the certificates of the subordinate certification authorities of the Portuguese eID.

This CA https://crt.sh/?id=341674989, it's a subordinate ceritification authority that issue the authentication certificates for the eID card. The authentication certificates are used JUST for authentication in the governmental websites, to access and use public services.

None of this certification authorities issued SSL/TLS certificates and they are under SCEE because SCEE it's the Root certification authority for the electronic Portuguese civil identification.

The PKI of the Portuguese eID card are audited once per year under the eIDAS regulation. It's mandatory.

Can one of the members explain to me why any of this certification authorities have problems as mentioned previously?

Thank you.

Comment 9

[Wayne Thayer]

(In reply to Vitor Castro from comment #8)
> Can one of the members explain to me why any of this certification
> authorities have problems as mentioned previously?
> 
Mozilla policy section 5.3 requires subordinate CA certificates to be technically constrained or disclosed and audited. Even though these certificates are not used for TLS, they are capable of issuing TLS and email certificates, so Mozilla policy applies (refer to section 1.1 Scope).

Comment 10

[Ben Wilson]

The ECCE/SCEE (Portugal) and its auditor were unfamiliar with CA/Browser Forum and Mozilla Policy requirements. Their recent audit report (https://bug1433326.bmoattachments.org/attachment.cgi?id=8966451) only specifically identifies the CA "ECCE 01" because that is the only CA that issues SSL/TLS certificates.  They misunderstood that the Mozilla Policy requires that all CAs, whether they are in use or not, need to be disclosed in the CCADB and be audited with a report that identifies them with SHA2 hashes. DigiCert is now working with ECCE/SCEE to bring everything into compliance.  Censys.IO indicates that there are 403 certificates issued by ECCE 01. DigiCert will work to replace those certificates so that the parent CA, ECRaizEstado, can be put on OneCRL.(See https://bugzilla.mozilla.org/show_bug.cgi?id=1432608).  Also, we will have to work with ECCE/SCEE to transition the Portuguese national ID card system to issuing CAs that are EKU-constrained to clientAuth only, to remove them from the scope of Mozilla Policy 2.5.

Comment 11

[Wayne Thayer]

Ben: when do you expect to have those 403 certificates replaced?

Comment 12

[Steve Medin]

ECCE will replace the certificates beginning June 29 and have informed us that they intend to complete replacement and revocation on July 4.

Comment 13

[Steve Medin]

Wayne, with the fixed/resolved status of https://bugzilla.mozilla.org/show_bug.cgi?id=1436173 due to our revocations for the four ECRaizEstado cross certificates yesterday, these certificates and their CAs are no longer in Mozilla trust scope.