Following an internal request for an OV SSL certificate our RA operators started the issuance procedure by creating a Pre-certificate. Due to a bug on the update of the CA software recently applied, the automatic verification of the certificate profile Policies field was skipped by the pre issuance technical control mechanisms and the pre-certificate was issued. The second verification post issuance revealed the error, and the pre-certificate was revoked within 24 hours from issuance. When we received the email for the mis issuance of the pre-certificate we were in the analysis of the causes and solutions to prevent this type of event.
This bug filing encompasses CAs managed by Certsign S.A., which includes the Intermediate CA: certSIGN Enterprise CA Class 3 G2
- How your CA first became aware of the problem, and the time and date.
The problem had been identified by certSIGN operators on March 30, 2022, immediately after the issuance of the certificate
- A timeline of the actions your CA took in response.
Note: Times are listed in EEST time zone
• March 30, 2022 17:24 – the certificate for OV SSL was issued with error
• March 30, 2022 18:00 - Internal incident created
• March 31, 2022 10:00 – Internal investigation started
• March 31, 2022 12:53 – the certificate was revoked
• April 1st, 2022 10:00 - analysis on the improvement of the process started
• April 2nd, 2022 13:25 – Issue reported by email@example.com as Bugzilla bug 1762707 - certSIGN: Subscriber precertificate without Certificate Policies.
• April 4th, 2022 18:00 – Update rollback to the previous configuration
• April 5th, 2022 14:10 - certificate misissued acknowledged and response sent to firstname.lastname@example.org
- Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.
Our initial investigation confirmed that the root cause was a bug in the CA update that was immediately corrected and verified. There was only one certificate issued with the mentioned problem. See next.
- 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.
There was only one certificate issued with the mentioned problem. See next.
- The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
The known impacted certificates were already provided as crt.sh link with ID 6442253524 for the pre-certificate.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
An update was applied on March 30, 2022 to the CA software application in order to improve the response time for certificate issuance. The first SSL certificate to be issued was the pre-certificate 6442253524. The CA software update had an issue on a new introduced routine which wasn’t caught during the testing on the staging/testing environment. The exception handling of the linting process in the application was faulty, not implementing a catch-all condition, rendering the process of issuance of the certificate prone to failure of linting process if the connection to the linting engine was not available or the response was not successful. Subsequently the linting call for the final certificate also failed with the same condition. After a preliminary investigation we have determined that the update on the linting component in the CA software introduced an erroneous configuration of the linting endpoint hence activating the bug in the software. However, we have subsequently determined that also there is a technical issue with the linter warnings allowing bypassing the technical control and relying on the operator for the final decision, assumption which is not correct.
- 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.
As first steps, we have updated the corrected configuration for the linting endpoint. A new update for the CA will be performed with a catch-all condition for the exception handling, treating also this scenario where the endpoint responded but with a wrong type of response. All warnings will be treated as exceptions. We will have this update in production until 31st of May 2022, taking enough time to test thoroughly a new set of test cases which arise from this incident.