Closed Bug 1530718 Opened 6 years ago Closed 5 years ago

T-Systems: Invalid SAN Entries

Categories

(CA Program :: CA Certificate Compliance, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wthayer, Assigned: Arnold.Essing)

Details

(Whiteboard: [ca-compliance] [ov-misissuance])

Michael Lebihan posted the following information to the mozilla.dev.security.policy 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 https://crt.sh/?id=1044575692&opt=ocsp,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 https://crt.sh/?id=1003197184&opt=cablint,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:
https://crt.sh/?id=1044697381&opt=cablint,zlint
https://crt.sh/?id=282646160&opt=cablint,zlint

They are all revoked.

Please provide an incident report, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
The incident report should be posted to the mozilla.dev.security.policy forum and added to this bug.

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

  2. A timeline of the actions your CA took in response.
    a) https://crt.sh/?id=1044575692 12/20/2018 13:18 GMT The test certificate was blocked immediately after it was created.
    b) https://crt.sh/?id=1044697381 12/20/2018 13:47 GMT The test certificate was blocked immediately after it was created.
    c) https://crt.sh/?id=1044572218 12/20/2018 13:22 GMT The test certificate was blocked immediately after it was created.
    d) https://crt.sh/?id=1140061318 01/24/2019 10:25 GMT The test certificate was blocked immediately after it was created.
    e) https://crt.sh/?id=1003197184 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) https://crt.sh/?id=1044575692 Creation of test certificate with forbidden characters in DNS names.
    b) https://crt.sh/?id=1044697381 Creation of test certificate with invalid TLD.
    c) https://crt.sh/?id=1044572218 Creation of test certificate with DNSName not as FQDN.
    d) https://crt.sh/?id=1140061318 Creation of test certificate without keyIdentifer field.
    e) https://crt.sh/?id=1003197184 Certificate with leading space in CN.

  5. The complete certificate data for the problematic certificates.
    a) https://crt.sh/?id=1044575692
    b) https://crt.sh/?id=1044697381
    c) https://crt.sh/?id=1044572218
    d) https://crt.sh/?id=1140061318
    e) https://crt.sh/?id=1003197184

  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.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(wthayer)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ov-misissuance]
You need to log in before you can comment on or make changes to this bug.