Closed Bug 1530718 Opened 3 years ago Closed 2 years ago

T-Systems: Invalid SAN Entries


(NSS :: CA Certificate Compliance, task)

Not set


(Not tracked)



(Reporter: wthayer, Assigned: Arnold.Essing)


(Whiteboard: [ca-compliance])

Michael Lebihan posted the following information to the list:

While looking at CT logs, I noticed multiple certificates issued by T-Systems that have SANs that seem invalid. The first certificate I noticed is,cablint,zlint The DNS name has a leading /. That certificate was revoked, but I didn't see any report about this on this list. Other certificates I noticed are,zlint where the CN has a leading whitespace and the SAN is double. This one has also been revoked.

Other certificates that seem mississued are:,zlint,zlint

They are all revoked.

Please provide an incident report, as described here:
The incident report should be posted to the forum and added to this bug.

  1. How your CA first became aware of the problem, and the time and date.
    a) 12/20/2018 12:27 GMT Test certificate. The error occured while testing.
    b) 12/20/2018 13:45 GMT Test certificate. The error occured while testing.
    c) 12/20/2018 12:26 GMT Test certificate. The error occured while testing.
    d) 01/24/2019 10:22 GMT Test certificate. The error occured while testing.
    e) 12/05/2018 13:00 GMT The error was detected during our post issuing linting process.
    f) 09/14/2017 It does not concern a server certificate.

  2. A timeline of the actions your CA took in response.
    a) 12/20/2018 13:18 GMT The test certificate was blocked immediately after it was created.
    b) 12/20/2018 13:47 GMT The test certificate was blocked immediately after it was created.
    c) 12/20/2018 13:22 GMT The test certificate was blocked immediately after it was created.
    d) 01/24/2019 10:25 GMT The test certificate was blocked immediately after it was created.
    e) 12/05/2018 16:22 GMT The certificate was blocked shortly after the error was detected.

  3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
    Issuance of certificates with these problems has been stopped.

  4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
    a) Creation of test certificate with forbidden characters in DNS names.
    b) Creation of test certificate with invalid TLD.
    c) Creation of test certificate with DNSName not as FQDN.
    d) Creation of test certificate without keyIdentifer field.
    e) Certificate with leading space in CN.

  5. The complete certificate data for the problematic certificates.

  6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
    a-c) Intentionally failed test certificates were issued during the module tests of our pre-issuing linting service. Therefore the linting service was inadvertently not activated.
    d) In the framework of quality assurance, an erroneous certificate was created and immediately blocked during commissioning tests. The reason was a not fully described test procedure.
    e) While creating the certificate, the registration staff accidentally entered a space in front of the CN. The existing field validation methods did not recognize this error. That is why the bug was first detected through our post issuing linting process.

  7. List of steps CA is taking to resolve the situation and ensure it will not be repeated.
    With the commissioning of our pre-issuing process linting on 24/01/2019 14:00 GMT these errors can no longer occur.
    The field validation methods for DNSnames have been improved.

Why was a-d done on the production environment and not in the test environment?

Arnold: I would also ask that you provide more information on the testing process:

  • Why was testing performed in production?
  • Why were these misissuances not reported?
Flags: needinfo?(Arnold.Essing)

For technical reasons, the respective configuration of the production and test environments must be different. In accordance with our binding ITIL processes, testing in both the test and production environments is necessary.
We were not aware that an Incident Report should be submitted for certificates which are not in circulation or will ever be used. We have broadened our work instructions and trained our staff accordingly.

Flags: needinfo?(Arnold.Essing)
Assignee: bernd.nakonzer → Arnold.Essing
Flags: needinfo?(wthayer)

It appears that all questions have been answered and remediation is complete.

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