1426009 - T-Systems: Non-BR-Compliant OCSP Responders

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

The OCSP responder for the Deutsche Telekom Root CA 2 is returning a good response for an invalid serial number as reported here: https://crt.sh/ocsp-responders?randomserial=Good&trustedBy=Mozilla&trustedFor=Server%20Authentication&trustedExclude=constrained,expired,onecrl&randomserial=Good&sort=2&dir=v

As per section 4.9.10 of the BRs, OCSP responders MUST NOT respond with a “good” status for unissued certificates. The effective date for this requirement was 2013-08-01.

Please provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 1

[Wayne Thayer]

The same problem is also reported for the T-TeleSec GlobalRoot Class 2 and T-TeleSec GlobalRoot Class 3 OCSP responders.

Comment 2

[Bernd]

Hi Wayne,

we fixed the Problem. Please find enclosed the incident report.

Regards,
Bernd

###

1.	How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date. 

We became aware via an email from Rob Stradling via dev-security-policy notified via discussion in mozilla.dev.security.policy on December 11, 2017.

2.	A timeline of the actions your CA took in response. 

2017-12-12 Evaluation about the problem
2017-12-13 Initiate investigation about the OCSP countermeasures with the vendor.
2017-12-19 Obtain a new version of the OCSP software
2017-12-20 Testing of new OCSP version in staging environment completed
2017-12-21 and 2017-12-22 Emergency changes to implement the new OCSP version on all OCSP instances. 
           The problem is fixed now. 

3.	Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem. 

As of 2017-12-22 T-Systems International GmbH has stopped sending OCSP responses in violation of BR 4.9.10. for the following Root certificates:
Deutsche Telekom Root CA 2	https://crt.sh/?caid=81
T-TeleSec GlobalRoot Class 2	https://crt.sh/?caID=6068
T-TeleSec GlobalRoot Class 3	https://crt.sh/?caid=814 

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. 

Not applicable. Problem was with OCSP response.

5.	The complete certificate data for the problematic certificates. 

Not applicable. Problem was with OCSP response.

6.	Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. 

Due to a software bug, our Root CA's OCSP were responding on a 'POST request for a Random Serial' with the response 'GOOD'. 
Our internal audit measures were missing this specific OCSP check.

7.	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.

We implemented a new OCSP software. 
The quality check task after maintenance or implementing a new OCSP instance was extended. The internal audit was extended to check the OCSP behavior.

Comment 3

[Wayne Thayer]

Thanks Bernd. I've confirmed that these errors are no longer occurring, so am marking this issue as resolved.