Closed Bug 1652604 Opened 1 year ago Closed 8 months ago

PKIoverheid: Failure to revoke within 7 days: OCSP EKU issue


(NSS :: CA Certificate Compliance, task)


(Not tracked)



(Reporter: bwilson, Assigned: jorik.vant.hof)



(Whiteboard: [ca-compliance] [delayed-revocation-ca] Next update 2020-12-01)

Opening this bug to track incident response report on, and discussion regarding, CAs not yet revoked. See Bug 1649964 for discussion up until now.

Logius PKIoverheid requires more than 7 days to revoke the certificates affected by Bug1649964. We wil post a detailed incident report within a week.

Duplicate of this bug: 1652922
Whiteboard: [ca-compliance] [delayed-revocation-ca] → [ca-compliance] [delayed-revocation-ca] Next update 22-July-2020

Hello Ben,

Part of the remediation for this issue is already outlined in Bug 1649964, but for clarity we will repeat those measures (and the causes here).

Over het last year Logius PKIoverheid has already reissued certificates under a private root for certain TSPs or use cases. Untill now, this effort has been mostly on a voluntary basis, trying to inform subscribers to make an informed decision about implementing public trust PKI certificates. As indicated in bug 1649964, this approach will now be turned into a more forceful way e.g. to explicitly replace part of the existing publicly trusted TLS certificates issued under the "Staat der Nederlanden Root CA - G3" with new certificates issued under the "Staat der Nederlanden EV Root CA". After this split, the remaining (EV) PKIoverheid certificates will soley be used for websites. The delays incurred by publicy trusted PKIoverheid certificates used in non-webPKI use cases will therefore not be an issue anymore. Those certificates which caused the delay as listed in bug 1649964 will remain valid for the time being, but as the "Staat der Nederlanden Root CA - G3" will be removed from the browser trust stores, this will limit any potential impact of future issues to purely the remaining (government internal) ecosystem.

Other solutions (like further limiting end-user or ICA lifetime, CA key rotation etc) are being looked into, but due to the remaining (short) lifespan of the Staat der Nederlanden EV Root CA, these will, if possible, be included into the next generation PKIoverheid certicates (G4), of which the design phase has already started.

Because of the depth of analysis in , and , I'm OK without having to have that data replicated on this bug. It is the fact that it's so holistic and comprehensive that this divergence from standard policy seems reasonable.

That said, David, could you make sure to capture the specific timelines related to remediating this (e.g. from and the already-passed events from and those pending)

I think just having a clear timeline for the points for remediating this would be sufficient to track in this bug, as well as continuing to use this bug to track the process on that remediation. Bug 1649964 can be used to track the overall segmentation and introduction of the new PKIoverheid PKI, as appropriate.

Flags: needinfo?(david.weissenberg)
Whiteboard: [ca-compliance] [delayed-revocation-ca] Next update 22-July-2020 → [ca-compliance] [delayed-revocation-ca] Next update 29-July-2020
Whiteboard: [ca-compliance] [delayed-revocation-ca] Next update 29-July-2020 → [ca-compliance] [delayed-revocation-ca] Next update 14-Aug-2020

Hello Ryan here is a brief timeline of steps taken already and planned future steps. Since many stakeholders are involved in our PKI system and the profoundly new direction we want it to take, the planning has undergone many iterations. The planning below is the end result and agreed upon by all parties involved. However, small deviations may still occur based on new insights. If so, we will update this bug post.

• Week 27-30: Meetings with TSPs, government agencies and national CERT on the security issue and the way forward; plan has undergone many iterations. [DONE]
• Week 28: Posting of post mortem; revocation of ICAs no longer in use [DONE]
• Week 30: Direction forward is clear; planning submitted in bugpost [DONE]
• Week 31: Ceremonies creating OV intermediate CA under current EV root and creating new issuing CA’s for TSP’s under this intermediate as previously posted [DONE]
• Started WEEK 31: Informing all subscribers plus government agencies on plan to withdraw from trust stores [UNDERWAY]

• Directing subscribers plus government agencies how to move forward; either public or private root depending on their use case [UNDERWAY]
• Issuing new certificates under new OV ICAs for EV subscribers [UNDERWAY]
• Issuing new certificates under new OV ICAs for OV subscribers under G3 root [UNDERWAY]
• Revocation of all EV certificates [UNDERWAY]
• Thorough inventory of dual-use certificates in use by subscribers [UNDERWAY]
• Moving “non-complex” web use cases of TLS certificates under G3 root to new OV ICAs under EV root and revocation of old certificates [STARTING]

• Revocation and supervised key destruction of old intermediate and issuing CA’s under EV root [TO DO]
• Issuing web TLS certificates under new OV ICAs for dual-use cases under G3 root [TO DO]

September to October:
• Preparing M2M environments (TLS certificates under G3) for move from public to private [TO DO]

September to November:
• Preparing M2M environments (TLS certificates under G3) for move from public to private in which software has to be changed, tested and updated [TO DO]

September to December:
• Preparing M2M environments (TLS certificates under G3) for move from public to private in which embedded software has to be changed, tested and updated [TO DO]
• Preparing and testing non-TLS environments for move from public to private [TO DO]
• Preparing S/MIME environments for move from public to private [UNDERWAY].

• Logius will withdraw its G3 from the browser trust stores [TO DO]

Flags: needinfo?(david.weissenberg)
Whiteboard: [ca-compliance] [delayed-revocation-ca] Next update 14-Aug-2020 → [ca-compliance] [delayed-revocation-ca] Next update 30-Sept-2020

Please provide a status update on whether your project plan is still on course. Thanks.

Flags: needinfo?(david.weissenberg)

Hello Ben,

Our plan is on course. PKIoverheid TSPs are currently replacing certificates under our G3 root with either new public OV certificates (via the new CA Server 2020 intermediate CAs) or with certificates under our private root hierarchy. The transition of the EV certificates to OV certificates under de EV root has been completed early september.

More information on planning and progress can be found in the related bug 1649964.

We will keep sending regular updates on our progress up to the foreseen withdrawal date, 31 January 2021.

Flags: needinfo?(david.weissenberg)
Whiteboard: [ca-compliance] [delayed-revocation-ca] Next update 30-Sept-2020 → [ca-compliance] [delayed-revocation-ca] Next update 2020-12-01

David: Can you provide an update on this bug where things stand? It appears you may have been providing progress updates on bug 1649964, but this bug was for the delayed revocation.

Flags: needinfo?(david.weissenberg)

Hello Ryan,

Sorry for the mix-up. As stated in bug 1649964 comment 18

Up to 95% of the TLS-certificates have been replaced. About 30% of these replaced TLS (G3) certificates have been revoked as well.
December 31st is our deadline for replacing all remaining TLS certificates with either PKIoverheid private certificates, or with CA Server 2020 certificates.

The remaining certificates will be revoked between 11 and 22 of January. This will be done in a phased manner, so that if any problems arise they can be dealt with accordingly.

Furthermoore we have filed bug1684158 PKIoverheid: Removal of websites trust bit for "Staat der Nederlanden Root CA – G3".

This request has also been sent to Microsoft Google and Apple, asking them to remove trust as of 1 February 2021.

Flags: needinfo?(david.weissenberg)

I'll close this bug on or about next Wednesday, 31-March-2021.

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