Closed Bug 1401486 Opened 2 years ago Closed 2 years ago

T-Systems/DFN-PKI cablint findings, follow up to T-Systems Bug 1391074


(NSS :: CA Certificate Compliance, task)

Not set


(Not tracked)



(Reporter: brauckmann, Assigned: Lothar.Eickholt)



(Whiteboard: [ca-compliance])


(4 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36

Actual results:

When handling our part of, we performed a cablint scan of all not expired, not revoked server certificates of the PKI hierarchies under the following two Sub CA certificates: CN=DFN-Verein PCA Global - G01 CN=DFN-Verein Certification Authority 2

The following issues were found. Our Root CA T-Systems is informed of these findings and agreed that we publish this report ourselves.

Issue A: Metadata in OU
A set of further 61 certificates was detected. Those certificates are already handled in bug 1391074.

Issue B: rfc822Name, otherName, uniformResourceIdentifier in server certificate

12045 certificates which were issued up to 12/2014 are still valid, not revoked and contain at least one subject alternative name of the type rfc822Name. 97 of those contain two rfc822Names.

56 certificates which were issued up to 12/2014 are still valid, not revoked and contain a subject alternative name of the type otherName.

34 certificates which were issued up to 12/2014 are still valid, not revoked and contain at least one subject alternative name of the type uniformResourceIdentifier.

Issue C: DNSName is not in preferred syntax (trailing dot)
4 further certificates contain DNSName subject alternative names with trailing dots. One of those certificates contains three DNSNames with this error, the others each only one.  Those certificates are already handled in bug 1391074.

Issue D: Invalid Padding in RFC822Name
1 certificate contains an RFC822Name with a mail address with a trailing dot.

Issue E: DuplicateSANEntry
130 certificates contain at least one duplicate SAN entries. All duplicate SAN entries are of type DNSName, and are only duplicates if case is ignored (e.g. and DNS:www.dfn.DE).

1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in, or via this Bugzilla Bug), and the date.

When handling, we performed a cablint scan of all not expired, not revoked server certificates. The scan was done on 2017-08-17, evaluating the results took some time.

2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.

Most issues are "legacy" problems and issuing such defective certificates has stopped way back in the past.

Fix for simple cases of "Issue A: Metadata in OU" and for "Issue E: Duplicate SAN Entries" was installed on 2017/08/28

3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or IDs, with one list per distinct problem.

We will provide a issuer-dn/serial/fingerprint csv list.

4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.

Certificates with these issues were issued since before BRs came into effect. 

Issue A: 61, last issued: notBefore=Jun 22 05:42:27 2017 GMT

Issue B: 12135, last issued: notBefore=Dec  2 14:47:08 2014 GMT

Issue C: 4, last issued: notBefore=Mar 24 15:49:12 2015 GMT

Issue D: 1, last issued: notBefore=May 30 07:40:13 2014 GMT

Issue E: 130, last issued: notBefore=Aug 10 13:11:28 2017 GMT

5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.

See "Root causes and remediations" of attached PDF.

6) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

- For Issues A and E: Enhance syntax checking on certificate requests (done in 08/2017)
- We will implement a pre-issuance cablint test. Timeline: 3 months

7) Regular updates to confirm when those steps have been completed.
Assignee: kwilson → Lothar.Eickholt
Summary: DFN-PKI cablint findings, follow up to T-Systems Bug 1391074 → T-Systems/DFN-PKI cablint findings, follow up to T-Systems Bug 1391074
Whiteboard: [ca-compliance]
List of certificates affected by Issue B
List of certificates affected by Issue D
List of certificates affected by Issue E
The BRs require revocation of BR non-compliant certificates within 24 hours of discovery; Mozilla provides more leeway at , but of course you may need to discuss this with other root programs.

Given the fact that issue B was fixed 3 years ago, and the numbers involved, and the low risk profile of the error, Mozilla does not require the revocation of all 12,000 certificates in that case. They may expire normally. However, please revoke and replace all of the other problematic certificates as soon as possible. 

Thanks for your feedback. We are working on revoking those certificates since Monday.

Status: 142 certificates are revoked, 2 expired. 52 certificates need more time. 

Of those 52, there are 2 from Issue A (metadata in OU), 1 from Issue C (DNSName is not in preferred syntax) and 49 from Issue E (DuplicateSANEntry).

Those certificates are mainly used for large VMWare installations, for Cisco IDS and for Cisco UCM and we are getting feedback that they cannot be replaced in a short timeframe. Actually, certificate holders of those systems are frightened to touch them and are seeing certificate replacement as a major undertaking. As far as we can see it, this results from the mostly broken certificate management functions of many "enterprise" devices which introduce unpredictable change risks.

We are urging certificate holders to get them replaced ASAP. One party already told us that they need time till the end of december (yes, I know how this sounds).

I will give further updates... .

Status update:

1. We integrated cablint into our toolchain. cablint is run automatically as a pre-flight-check before every real issuance. It is run on a certificate created with the real data but signed by a "snakeoil CA". The "real" certificate is only issued iff. cablint does not issue any ERRORs.

2. From the 194 certificates which were to be revoked 38 are still valid. Those are all from "Issue E: Duplicate SAN Entry".

We based our assessment from august/september regarding duplicate SAN-entries on a cablint-run on all valid certificates. Back than we decided to handle all cablint errors as Findings, though already then we were not aware of any standard that prohibits duplicate SANs. In the meantime, a new cablint version has been released and introduced in our toolchain and duplicate SAN entries are not considered as ERRORs any more but only as a WARNINGs. We will thus not force our customer to replace the last 38 affected certificates.

From our point of view, all affected certificates discussed in this bug are now handled in accordance to Mozilla's responses here.

Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.