NETLOCK: Pre-certificates revoked with certificateHold reason
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: mathew.hodson, Assigned: horvath.tamas2)
Details
(Whiteboard: [ca-compliance])
(In reply to Rob Stradling from bug 1824435 comment #3)
The first of these precertificates is revoked with the revocation reason "certificateHold", which is forbidden by BR 7.2.2. You'll need to create an incident bug for that. Are you affected by the same EJBCA bug that WISeKey and Actalis both created incident bugs for a few hours ago?
NETLOCK was notified in bug 1824435 that one of their certificates was revoked with the incorrect certificateHold reason. They haven't posted an incident report as requested, so I created this bug for them to respond.
Updated•1 year ago
|
Comment 1•1 year ago
|
||
MRSP section 2.4 incorporates the Responding To An Incident wiki page, which contains an Incident Report section that incorporates the CCADB incident reporting requirements, which state the following expectations regarding the timeliness of incident reports (emphasis mine):
"Each incident should result in an incident report written as soon as the problem is fully diagnosed and (temporary or permanent) measures have been put in place to ensure it will not reoccur. If the permanent fix will take significant time to implement, you should not wait until this is done before issuing the report. Incident reports should be published as soon as possible, and certainly within two weeks of the initial issue being reported."
This bug's "initial issue" was reported (by me, in bug 1824435 comment #3) nearly six weeks ago, so ISTM that NETLOCK now also needs to create an additional incident bug to explain why the "certainly within two weeks" requirement was not met.
Assignee | ||
Comment 2•1 year ago
|
||
Netlock incident report – Pre-certificates revoked with certificateHold reason
How your CA first became aware of the problem (e.g/via a problem report submitted to your Problem Reporting Mechanism, a discussion in the MDSP mailing list, a Bugzilla bug, or internal self-audit), and the time and date.
We got a notification at 21. 03. 2023. 12:46 from one of our customers about their certificate is gives an error under Chrome.
https://crt.sh/?id=8901405844
We opened a bug on the manner (https://bugzilla.mozilla.org/show_bug.cgi?id=1824435) where Mr. Rob Stradling notified us the precerts were revoked under the reason "certificateHold"
A timeline of the actions your CA took in response/A timeline is a date-and-time-stamped sequence of all relevant events/This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was performed.
Date Action taken
26/03/2023 IT was notified of the problem, investigation started.
27/03/2023 The problem was identified, NETLOCK’s customer facing online TLS administration interface had the revocation option “certificateHold”, and it was the default reason for the customers.
27/03/2023 The revocation reason was withdrawn from the live site.
28/03/2023 New software version was planned for release.
11/05/2023 New onlinessl interface was released which does not include the named reason.
Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident/A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.
The reason code was withdrawn from the live site as soon as the issue arised, so NETLOCK didn’t stop the issuance of certificates.
In a case involving certificates, a summary of the problematic certificates/For each problem: the number of certificates, and the date the first and last certificates with that problem were issued/In other incidents that do not involve enumerating the affected certificates (e.g/OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified/This will help us measure the severity of each problem.
The case was not involving certificates.
In a case involving TLS server certificates, 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/It is also recommended that you use this form in your list "https://crt.sh/?sha256=[sha256-hash]", unless circumstances dictate otherwise/When the incident being reported involves an SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate/In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
All affected certificates: 12
First issued TLS certificate: 16/03/2023.
Last issued TLS certificate: 16/03/2023.
CRT
https://crt.sh/?id=8901405844
https://crt.sh/?id=8902129125
https://crt.sh/?id=8902129073
https://crt.sh/?id=8902140765
https://crt.sh/?id=8902141083
https://crt.sh/?id=8902199068
https://crt.sh/?id=8902618610
https://crt.sh/?id=8901284503
https://crt.sh/?id=8901388427
https://crt.sh/?id=8902379322
https://crt.sh/?id=8902398277
https://crt.sh/?id=8902447886
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The changes in the regulation was not followed up during the development and change processes. As there were no revocation through the admin panel of the onlinessl interface, it went undetected until now.
List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future/The steps should include the action(s) for resolving the issue, the status of each action, and the date each action will be completed.
We have implemented new processes between the compliance team and the development team where the compliance team is responsible creating the tickets for changes in the regulation, and those changes will be discussed in detail to avoid not implementing the technical and/or procedural changes.
Assignee | ||
Comment 3•1 year ago
|
||
Hello!
I would like to update the timeline presented previously. On 27/04/2023 we had a system update. The certificateHold option from the onlinsessl interface got removed and we implemented new revocation reasons for the customers. As a result, the client can choose between other reasons and the withdrawal of a TLS certificate can’t be certificateHold automatically applied by a customer anymore.
The related CT certificates are still under inspection, we would update this ticket.
Tamas
Assignee | ||
Comment 4•1 year ago
|
||
Hello All!
The new onlinessl version was released where the certificateOnhold reason was removed from the site.
Changes in the internal processes was introduced and the colleagues was trained.
If there is no further questions I believe we can close the ticket.
Thanks! Tamas
Comment 5•1 year ago
|
||
I'll close this ticket next week to see if there are any other comments.
Updated•1 year ago
|
Description
•