Closed Bug 1774418 Opened 3 years ago Closed 2 years ago

Certigna: Certificate issued with validity period greater than 398-days

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

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.

Assignee: bwilson → j.allemandou
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance]

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?

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.

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

Flags: needinfo?(j.allemandou)

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

Flags: needinfo?(j.allemandou)

I'll set Mon. 5-Sept-2022 for your next status update.

Whiteboard: [ca-compliance] → [ca-compliance] Next update 2022-09-05

Do you have updates?

Flags: needinfo?(j.allemandou)
Whiteboard: [ca-compliance] Next update 2022-09-05 → [ca-compliance]

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

Flags: needinfo?(j.allemandou)

Unless there are remaining issues to resolve, I will close this sometime next week (9/26-9/30).

Flags: needinfo?(bwilson)

(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?

Flags: needinfo?(bwilson) → needinfo?(j.allemandou)

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

Flags: needinfo?(j.allemandou)
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ov-misissuance]

It appears that this bug can be closed, which I'll do on Wed. 19-Apr-2023.

Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.