1428891 - Entrust: Non-BR-Compliant OCSP Responder

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

The OCSP responders for the Entrust Class 1 Client CA and Entrust Class 2 Client CA intermediates are 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

The most recently issued versions of these certificates are technically constrained to email and client auth, but there are a total of 6 non-revoked certificates that are not constrained:
- https://crt.sh/?caID=12557
- https://crt.sh/?caID=12549

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.

Either the OCSP responder should be brought into compliance or these 6 non-constrained certificates should be revoked.

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

Comment 1

[Bruce Morton]

1.    How your CA first became aware of the problem

Entrust first became aware of the OCSP issue through an email initiated by this bug report on January 8, 2018.
 
2.    A timeline of the actions your CA took in response

Jan 8, 2018 – Received Bugzilla notice
Jan 9, 2018 – Started working on solution plan
Jan 26, 2018 – target date for fix to be completed

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

There are no non-complaint certificates relating to this bug. As such, we will continue to issue certificates as stopping issuance will not correct or mitigate the OCSP issue.

4.    A summary of the problematic certificates

There are no problematic certificates issued.

5.    The complete certificate data for the problematic certificates

There are no problematic certificates issued.

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

Although Mozilla policy 1.1(2) does state that CAs which are not technically constrained or are used for SSL or S/MIME are in scope, we did not consider that Mozilla policy 2.3 imposed the BRs on S/MIME CAs. The reason is 2.3 appears to be applied to “CA operations relating to issuance of certificates capable of being used for SSL-enabled servers.”

We do understand that since the CA certificates are not technically constrained by having an EKU in the CA certificates, then the CAs could issue an SSL certificate which is in scope. Please note that this issue is mitigated as these CAs are not configured with SSL certificate profiles.

Through our analysis we have confirmed that the two CAs listed in the bug have certificates which are not technically constrained. We have also discovered that there is a code signing CA which is also not technically constrained. Please note that the code signing CA no longer issues certificates, but still supports revocation, CRL and OCSP.

We will address this issue for the following CAs:
- https://crt.sh/?caID=12557
- https://crt.sh/?caID=12549
- https://crt.sh/?caid=13284

7.    List of steps your CA is taking to resolve the situation

The CAs will be updated to provide the list of serial numbers to the OCSP Responders.
The OCSP Responders will be updated to only respond with “good” status for certificates with known serial numbers and have not been revoked.

Please note that since the end of 2014, all new Entrust issuing CA certificates have been technically constrained with EKUs, so this problem should be mitigated for future occurrences.

The OCSP system is planned to be corrected by January 26, 2018.

Comment 2

[Gervase Markham [:gerv]]

Wayne can correct me if I'm wrong, but the unconstrained versions of these certs, as they are capable of issuing for SSL, either need to be disclosed and properly audited as any SSL intermediate, or added to OneCRL (which is an option for legacy certificates with deficient constraints).

Gerv

Comment 3

[Bruce Morton]

These CAs are fully disclosed in CCADB and are annually audited to WebTrust for CA. The CAs are configured not to issue SSL certificates and the annual audit confirms that no SSL certificates were issued.

Comment 4

[Ryan Sleevi]

(In reply to Bruce Morton from comment #1)
> 3.    Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem
> 
> There are no non-complaint certificates relating to this bug. As such, we will continue to issue certificates as stopping
> issuance will not correct or mitigate the OCSP issue.

Are you issuing certificates that point to these responders? If so, then you are potentially issuing TLS/SSL certificates with the problem.

> 4.    A summary of the problematic certificates
> 
> There are no problematic certificates issued.

To clarify: Are you saying no certificates were issued by the "Entrust Class 1 Client CA" OCSP responder and the "Entrust Class 2 Client CA" responder?

Otherwise, can you clarify how many certificates point to these responders? When an OCSP responder violates the norms and expectations, the effect is on every certificate issued under that CA. While it may be that resolving the responder allows these certificates to continue to be used without issue, that's not always the case - and thus, bears relevance to the discussion.

Comment 5

[Bruce Morton]

Yes, Class 1 and Class 2 CAs issued certificates which point to these responders. For the period of 1 Feb 2016 to 30 Nov 2017 the numbers were 23259 S/MIME certificates issued. For the code signing CA reported, there were 0 code signing certificates issued as this is a SHA-1 issuing CA and we have stopped issuing SHA-1 code signing certificates. For all CAs discussed, there were 0 TLS/SSL certificates issued.

Comment 6

[Bruce Morton]

The OCSP system has been corrected today.

Thanks, Bruce.

Comment 7

[Wayne Thayer]

I confirmed that these OCSP responders are no longer being reported as non-compliant by crt.sh. Resolving this bug.