IdenTrust: Unauthorized OCSP response on a Timestamp certificate
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: roots, Assigned: roots)
Details
(Whiteboard: [ca-compliance] [ocsp-failure])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
Steps to reproduce:
Preliminary Incident Report
Summary
On June 27, 2024, via our daily monitor of sslmate’s OCSP watch, we discovered that one of our CA’s issued certificates was flagged with an “unauthorized” OCSP response error.
This is a violation of our CPS Section 9.6.1 CA Representations and Warranties:
… Maintaining an online 24x7 publicly accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates…
Our initial investigation revealed that this was a leaf timestamping certificate missing in the OCSP Database. The certificate was immediately added to the Database and the issue was corrected.
We are still investigating the root cause and will provide a full incident report no later than July12, 2024.
|
||
Updated•1 year ago
|
Full Incident Report
Summary
On June 27, 2024, via our daily monitor of SSLMate’s OCSP watch website [https://sslmate.com/labs/ocsp_watch/], we discovered that one of our CA’s issued certificates was flagged with an “unauthorized” OCSP response error.
This is a violation of our CPS Section 9.6.1 CA Representations and Warranties:
… Maintaining an online 24x7 publicly accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates…
Our initial investigation revealed that this was a leaf Timestamping certificate missing in the OCSP database. The certificate was immediately added to the database and the issue was corrected.
Impact
All OCSP checks for this timestamping certificate have been returning an error message: "error parsing OCSP response: ocsp: error from server: unauthorized
Timeline
Times in UTC
2023-07-26 14:44 Timestamping certificate created
2024-06-27 12:34 Flagged in error by SSLMate alert
2024-06-27 12:39 Program Management alerted System Operations of the issue as seen on the SSLMate OCSP watch website.
2024-06-27 13:56 Operations Manager responded that team began investigation
2024-06-27 18:38: PKI Operations imported the certificate into the OCSP database
2024-06-27 18:39 OCSP checks for the certificate were successful and the OCSP alert cleared from the SSLMate website
Root Cause Analysis
The generation of the Timestamping certificate usually follows a well-established protocol. However, during this certification ceremony, we inadvertently omitted an important step: we failed to add the certificate for OCSP verification into the database.
The certificate was signed directly using the CSR from the issuing CA.
This method significantly differs from our usual end-entity certificate creation process:
- Typically, all other end-entity certificates are generated via a profile in the CA Production interface.
- This conventional method automatically adds new certificates to the database, which the OCSP depends on for certificate status validation.
The non-standard creation method resulted in several issues:
- The newly created certificate was not instantly added to the database causing a delay in its OCSP status validation.
- The absence of the certificate in the database led to failures in OCSP checks which are crucial for verifying the certificate’s validity.
This analysis highlights the need for a more robust system that can accommodate all certificate types within the standard creation and database integration process.
Lessons Learned
What went well
The issue was promptly resolved once it was identified
What didn't go well
We overlooked a critical step in our process: the addition of the certificate for OCSP into the database. This oversight needs to be addressed to prevent similar issues in the future.
Action Items
| Action Item | | Kind | | Due Date |
| Add this certificate type to the OCSP validation checking process in place for other certificates | Prevent | | 2024-10-24 upon expiration/replacement of the current Timestamping certificate. |
Appendix
Details of affected certificates
|
||
Comment 2•1 year ago
|
||
Add this certificate type to the OCSP validation checking process in place for other certificates
This action item sounds to me like it is aimed at detecting future instances of this problem, where a timestamping certificate is issued but does not have corresponding OCSP responses.
Does IdenTrust plan to take any actions to prevent this situation in the future, such as automating the process of creating timestamping certificates so that it is impossible for one to be created without being added to the OCSP database?
(In reply to Aaron Gable from comment #2)
This specific certificate type requires a unique creation process since it is essentially an end-user certificate generated within a Hardware Security Module (HSM). Consequently, we cannot utilize our usual standardized procedures that would have automatically positioned it correctly. To prevent this issue from happening again, we are incorporating a validation step to ensure successful OCSP validation as expected.
As an update: We are on track to complete the action item noted in the full incident report by 2024-10-24. Our next update is scheduled for August 31, 2024.
|
|
||
Updated•1 year ago
|
We are still on track to complete the action item noted in the full incident report by 2024-10-24.
We will provide another update by 2024-09-30.
Same as above, we are on track to complete the action item noted in the full incident report by 2024-10-24.
|
|
||
Updated•1 year ago
|
We have successfully integrated this specific certificate type into our existing OCSP (Online Certificate Status Protocol) validation process. This process was already in place for other certificate types, and we have now confirmed that the issue has been fully resolved by extending the validation to include this new certificate type as well.
|
|
||
Updated•1 year ago
|
There are no outstanding items that need remediation at this time. Unless there are further questions from the community, we would appreciate closing this issue.
|
|
||
Comment 9•1 year ago
|
||
I will take a look at closing this on Wed. 6-Nov-2024, unless there are issues to discuss.
|
|
||
Updated•1 year ago
|
Description
•