1426249 - Trustis: Non-Br-Compliant OCSP Responder

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

The OCSP responders for the Trustis FPS FF Issuing Authority and Trustis Healthcare TT Issuing Authority 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

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

[Blake Morgan]

We are investigating this and will respond with a compliant incident report once investigations are complete.

Comment 2

[Blake Morgan]

After investigating we have found that the current software does not properly support the requirement. Mitigation will include the discontinuance of the issuing of End Entity certs off that issuing CA and as part the Trustis infrastructure acquisition process the OCSP service will be migrated to the current Entrust Datacard infrastructure. Work to be completed by end of March 2018.

Comment 3

[Wayne Thayer]

Thank you for the response. Will you be providing a complete incident report, including an explanation of how and why this happened and steps you are taking to prevent similar problems in the future as described at the link above?

Comment 4

[Wayne Thayer]

Blake: please provide a complete incident report in the format described at https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Also, please confirm that you will have this resolved by the end of March 2018.

Comment 5

[Blake Morgan]

Wayne, we are working towards a solution to this and once this is agreed a full incident report will be provided.  I can confirm this will be resolved by the end of March 2018.

Comment 6

[Firefox Bug Husbandry Bot]

Changing QA contact per https://bugzilla.mozilla.org/show_bug.cgi?id=1438254

Comment 7

[Blake Morgan]

Wayne,  we have completed the investigation and remediation of this issue and I have compiled a report based upon the recommended template for you below. I trust this information is sufficient and we are now able to close this bug? Should you need any further information, please do not hesitate to get back to me:

1.    How your CA first became aware of the problem
 
Entrust Datacard first became aware of the OCSP issue through an email initiated by this bug report on 19th December 2017.

2.    A timeline of the actions your CA took in response
 
19th Dec 2017 – Received Bugzilla notice
20th Dec 2017 – Started working on solution plan
7th Jan 2018 - Stopped issuing certificates
2nd Mar 2018 – OCSP fix tested and confirmed as 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. However, no certificates were issued after 7th January 24, 2018.
 
4.    A summary of the problematic certificates

There are no problematic certificates issued. However, the number of non-expired certificates is 378 (at the time of this posting).
 
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.
 
It was a mis-understanding by the Policy Authority.  It was believed that the BR 4.9.10 requirement was only relevant for new CA's created after the effective date of 1st August 2013. This issue avoided detection as it was not tested due to the policy position.
 
7.    List of steps your CA is taking to resolve the situation:
 
OCSP responses for the following CA's will be transferred from the legacy Trustis FPS CA responder to the Entrust Datacard CA responder. The new OCSP responses will meet the requirements of BR 4.9.10.
https://crt.sh/?caID=2112
 
The following CA's no longer issue certificates, but are not technically constrained by EKU. The CA certificates for these CA's will be revoked after end entity certificates have expired.
https://crt.sh/?caID=674
https://crt.sh/?caid=920
https://crt.sh/?caid=929

Comment 8

[Wayne Thayer]

(In reply to Blake Morgan from comment #7)
> Wayne,  we have completed the investigation and remediation of this issue
> and I have compiled a report based upon the recommended template for you
> below. I trust this information is sufficient and we are now able to close
> this bug? Should you need any further information, please do not hesitate to
> get back to me:

Thank you for providing this incident report.
> 
> 1.    How your CA first became aware of the problem
>  
> Entrust Datacard first became aware of the OCSP issue through an email
> initiated by this bug report on 19th December 2017.
> 
> 2.    A timeline of the actions your CA took in response
>  
> 19th Dec 2017 – Received Bugzilla notice
> 20th Dec 2017 – Started working on solution plan
> 7th Jan 2018 - Stopped issuing certificates
> 2nd Mar 2018 – OCSP fix tested and confirmed as completed
>  
I've confirmed that Trustis is no longer on the crt.sh list of non-compliant responders

> 3.    Confirmation that your CA has stopped issuing TLS/SSL certificates
> with the problem
>  
> There are no non-complaint certificates relating to this bug. However, no
> certificates were issued after 7th January 24, 2018.
>  
> 4.    A summary of the problematic certificates
> 
> There are no problematic certificates issued. However, the number of
> non-expired certificates is 378 (at the time of this posting).
>  
> 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.
>  
> It was a mis-understanding by the Policy Authority.  It was believed that
> the BR 4.9.10 requirement was only relevant for new CA's created after the
> effective date of 1st August 2013. This issue avoided detection as it was
> not tested due to the policy position.
>  
> 7.    List of steps your CA is taking to resolve the situation:
>  
> OCSP responses for the following CA's will be transferred from the legacy
> Trustis FPS CA responder to the Entrust Datacard CA responder. The new OCSP
> responses will meet the requirements of BR 4.9.10.
> https://crt.sh/?caID=2112
>  
> The following CA's no longer issue certificates, but are not technically
> constrained by EKU. The CA certificates for these CA's will be revoked after
> end entity certificates have expired.
> https://crt.sh/?caID=674
> https://crt.sh/?caid=920
> https://crt.sh/?caid=929

If there are active certificates relying on the old OCSP infrastructure, then this problem has not been resolved. When will the last of these end-entity certificates expire so that these CAs can be revoked?

Please also explain what steps are being taken to ensure that a similar incident does not occur in the future.

Comment 9

[Blake Morgan]

Hi Wayne,

I can confirm that there are no active certificates relying on the old OCSP infrastucture.

Our Root CA is being withdrawn from service and no longer issues certificates.  The CA will be maintained in accordance with the Baseline Requirements until the last certificate expires (January 2021).  The OCSP responder is managed by Entrust Datacard colleagues who will ensure ongoing compliance for OCSP srvices for these certificates.

I hope this is now sufficient information to close the bug.

Thanks,
Blake

Comment 10

[Wayne Thayer]

(In reply to Blake Morgan from comment #9)
> Hi Wayne,
> 
> I can confirm that there are no active certificates relying on the old OCSP
> infrastucture.
> 
I've verified that all known certs under these CAs are either expired, revoked, or do not contain an OCSP pointer. Marking this resolved.