Certigna: Certificate issued with validity period greater than 398-days
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: j.allemandou, Assigned: j.allemandou)
References
Details
(Whiteboard: [ca-compliance] [ov-misissuance])
Steps to reproduce:
We create this ticket in connection with the identification of one certificate issued on June 12, 2022 for which the period validity was 400 days instead of the maximum 398 days allowed.
The ticket for reporting this non-compliance is available at this address https://bugzilla.mozilla.org/show_bug.cgi?id=1774171, and this second ticket was created after internal consolidation of the detailed history of actions carried out.
The certificate involved was issued but not deployed by the certificate manager. https://crt.sh/?id=6926734395&opt=zlint
Actual results:
The non-compliance was identified and escalated on June 14 afternoon, and the following actions have been implemented:
- we checked whether other certificates were concerned, which is not the case.
- We investigated why the automated validity check scripts allowed a duration of 400 days and have identified the case not processed by the scripts.
- The incident has been communicated to all CA and RA teams in order to be more vigilant about this situation and to remind the maximum period of validity.
- Corrections to the verification scripts have been developed, tested and now deployed.
- The certificate, which was not deployed, was revoked on June 15 at 8:37 AM.
Link to CRL : http://crl.certigna.fr/servicesca.crl
Serial Number : 51e3e5d10a6f2e4935e2dd0f79fa0235 - The incident was reported to our supervisory body (ANSSI) and our assessment body (LSTI) on June 15 at 10:00 AM.
We remain at your disposal for any further information.
Expected results:
Automatic checks have been set up to check and correct the validity period of certificates before their issuance. But our verification scripts did not cover a special case related to a certificate renewal where a Regristration Operator could manually increase the lifetime of the certificate for commercial purposes (which rarely happens). The operator was aware of the 397-day limitation of our certificates but thought that the control would automatically rectify the duration as for other situations, which was not the case for this type of exceptional situation.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
But our verification scripts did not cover a special case related to a certificate renewal where a Regristration Operator could manually increase the lifetime of the certificate for commercial purposes (which rarely happens).
Do you have other special cases or special validation/issuance paths? I don't really understand why a certificate (request?) that was manually modified by an operator is not processed by the same scripts/tools that normal certificate requests are.
Are you testing all certificate issuance paths?
Do you have post issuance lints that could detect issues that preissuance tools failed to detect?
Assignee | ||
Comment 2•3 years ago
|
||
Yes, we checked if there is other cases during our investigations in order to be sure that the checks cover all operations before delivery. This was a feature rarely used by operators and which was not covered by the controls automatically correcting the duration. This is the only certificate that has been the subject of this incident since November 2020, which demonstrates that the process involved is used exceptionally.
Thank you for your suggestion. Indeed we will work on this subject. Positioning a post-delivery check in addition to the proactive pre-delivery checks could allow us to try to identify non-conformities before they are reported by a third party.
Comment 4•3 years ago
|
||
Hi Josselin,
Please report your overall progress on resolving this incident. And also specifically, you mention in Comment #2 that there was a feature rarely used. Has that feature been disabled or otherwise protected from causing mis-issuance? And then you state, "we will work on this subject". What has been done in this regard?
Thanks,
Ben
Assignee | ||
Comment 5•2 years ago
|
||
Hi Ben
Our automatic checks on validity period of certificates before their issuance now cover the specific case identified at the origin of the incident. This check has also been repositioned to cover all configuration and certificate issuance cases now, in order to guard against any new incident on this subject.
The improvement to place a post-delivery check in addition to the proactive pre-delivery checks has been initiated but is not yet deployed. We can keep you informed when this improvement will be effective.
Regards,
Josselin
Comment 6•2 years ago
|
||
I'll set Mon. 5-Sept-2022 for your next status update.
Updated•2 years ago
|
Assignee | ||
Comment 8•2 years ago
|
||
Hi Ben,
We confirm that the improvement to place post-delivery checks in addition to the proactive pre-delivery checks has been deployed in production and is now operationnal. These checks are based in particular on Certlint/Cablint controls.
Regards,
Josselin
Comment 9•2 years ago
|
||
Unless there are remaining issues to resolve, I will close this sometime next week (9/26-9/30).
Comment 10•2 years ago
|
||
(In reply to Josselin Allemandou from comment #8)
Hi Ben,
We confirm that the improvement to place post-delivery checks in addition to the proactive pre-delivery checks has been deployed in production and is now operationnal. These checks are based in particular on Certlint/Cablint controls.
When was the change made in production? It's disappointing that no specific dates were provided in comment #5 and then the CA needed to be reminded to provide the updates that are required as part of incident resolution. Your response doesn't provide much detail. What caused the delay and what is your process for meeting the incident report requirements?
Updated•2 years ago
|
Assignee | ||
Comment 11•2 years ago
|
||
Hi Ben,
Thank you for this information and sorry for not getting back you sooner.
Hi Mathew,
Sorry for not letting you know sooner that this enhancement is in place, and we were targeting implementation in early September. The improvement was finally deployed on August 30 at the same time as another batch of evolutions. No delays have been identified for this improvement and we are aiming to meet the requirements for incident handling. This was an additional improvement, which for us was not intended to process the incident, but to help detect similar incidents.
Regards,
Josselin
Updated•2 years ago
|
Updated•2 years ago
|
Comment 12•2 years ago
|
||
It appears that this bug can be closed, which I'll do on Wed. 19-Apr-2023.
Updated•2 years ago
|
Description
•