Closed Bug 1949203 Opened 6 months ago Closed 5 months ago

Actalis: two CAs with the same CRLDP

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: agwa-bugs, Assigned: marco.menonna)

Details

(Whiteboard: [ca-compliance] [crl-failure] [external])

Actalis has disclosed the CRL http://ca1.agid.gov.it/CRL for certificates issued by this CA:

C=IT, L=Roma, O=Agenzia per l'Italia Digitale, OU=Area Soluzioni per la Pubblica Amministrazione, CN=AgID CA1

However, the CRL at this URL has the following issuer:

C=IT, L=Roma, O=Agenzia per l'Italia Digitale, CN=AgID CA1

It seems that Actalis has used the same CRLDP for two different CAs:

This is a problem because a CRL can only be issued by one CA. Consequentially, certificates issued by the first CA can't be revoked by CRL. This can only be fixed by revocation of one of these CAs.

Assignee: nobody → marco.menonna
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance] [crl-failure] [external]

Thank you for your report. We acknowledge the issue, which is already under analysis.
We are going to proceed with the revocation of the second certificate, which has already been addressed.

Incident Report

Summary

On January 25th, during a routine regeneration of a technically constrained non-TLS SubCA certificate (https://crt.sh/?id=12510454042), we decided to remove the OU (organizationalUnit) attribute from the CA Subject, as it is not recommended by CAB BRs for such CA certificates.
This modification inadvertently created technical complications that we did not anticipate.

The removal of the OU attribute resulted in an unexpected configuration where the same CRL Distribution Point (http://ca1.agid.gov.it/CRL) became associated with what appeared to be two distinct Certificate Authorities, despite them being identical. This created potential validation inconsistencies in certificate chains.

To resolve the issue, we set up a remediation plan that included Revoking the problematic SubCA certificate and regenerating the certificate with the original Subject DN restored. Both operations were performed on February 20th and disclosed to the CCADB shortly thereafter.

Impact

The primary impact of this incident was that leaf certificates issued by "AgID CA1" before January 25th could no longer be properly revoked after that date. This occurred because these certificates referenced an Issuer that no longer matched the Subject of the current CA certificate.

Fortunately, this technical limitation had minimal real-world consequences:

  • No certificate revocations were requested during the affected period (January 25 - February 20)
  • No end-user certificates were compromised or impacted
  • No "Relying Parties" in the ecosystem where "AgID CA1" certificates are used experienced service disruptions

Timeline

All times are CET.

2025-01-16

2025-01-22

  • In a preliminary internal consultation, where we reviewed the applicable CAB Forum's and Root Programs' requirements, we evaluated that for this technically constrained non-TLS SubCA it was appropriate to remove the OU from the profile of this SubCA certificate ("AgID CA1"), before proceeding with its reissuance.

2025-01-25

2025-02-07

  • We received a note from Ryan Dickson warning us of some problem with the mentioned CRL Distribution Point, referring us to Andrew Ayer's https://sslmate.com/labs/crl_watch

2025-02-10

  • We exchanged email with Andrew Ayer in order to better understand the technical problem underlying the error shown by crl_watch.

2025-02-11

  • We held an internal meeting in order to analyze the problem and decide on the next steps.

2025-02-14

  • We shared the situation with all stakeholders.

2025-02-19

  • This bug was opened by Andew Ayer.

2025-02-20

  • We reissued once again the "AgID CA1" certificate after restoring the OU attribute in the Subject (https://crt.sh/?id=16786055154).

  • We revoked the problematic "AgID CA1" certificate (the one issued on January 25).

  • We then disclosed both the new certificate and the revocation to the CCADB.

2025-02-25

  • We deployed the new "AgID CA1" certificate and checked that everything was consistent.

  • At this point, crl_watch no longer reported problems related to the aforementioned CRL DP.

Root Cause Analysis

Since the involved SubCA chains to a multi-purpose root, we had to comply with the TLS BRs. And given that the TLS BRs recommends against the OU in this kind of SubCAs (see §7.1.2.10.2 CA Certificate Naming), we evaluated it was appropriate to remove the OU from this SubCA certificates' profile.
We did not realize, at the time when we prepared for the SubCA certificate reissuance, that changing the subject DN would have undesirable technical consequences and that, in any case, the subject of a certificate should not be changed in a reissuance. Furthermore, our CA software does not prevent renewing a CA certificate with a modified Subject, otherwise we would have immediately realized that we were making a mistake.

Lessons Learned

What went well

  • The issue was identified before it could have real-world consequences thanks to stakeholder engagement who reported it

What didn't go well

  • Initial certificate profile modification was made without considering all potential technical consequences
  • Lack of monitoring to detect the CRL inconsistency

Where we got lucky

  • No leaf certificates required revocation during the affected period
  • The impacted CRL had minimal usage
  • No revocations have been requested during the incident

Action Items

Action Item Kind Due Date
Implement monitoring of https://sslmate.com/labs/crl_watch Detect 2025-03-31
Conduct awareness training with all internal stakeholders Prevent 2025-03-08
Document incident in our internal knowledge base for future reference and create formal pre-issuance checklist Prevent 2025-03-15

Appendix

Details of affected certificates

Not applicable.

As of today, all identified action items have been addressed. We expect to maintain up-to-date technical knowledge and expertise, robust processes, and an effective monitoring system to prevent similar incidents in the future.

We remain available for any further requests or clarifications.

There's an expectation of weekly status updates to all non-closed incidents.
There have not been recent updates to Bug #1949203, Bug# 1943379
In similar cases, the lack of updates is itself cause to file a separate incident report.

Given the absence of new developments or feedback on the implemented action items, we request the formal closure of this incident.

Report Closure Summary

Incident description:
On January 25th, during the reissuance of a technically constrained non-TLS SubCA certificate, the removal of the Organizational Unit (OU) attribute (recommended by CAB BRs) led to an unintended configuration issue. This caused the CRL Distribution Point to appear associated with two distinct Certificate Authorities, potentially impacting certificate validation

Incident Root Cause(s):
The issue arose from modifying the Subject Distinguished Name (DN) during reissuance, creating a mismatch between previously issued certificates and the new SubCA certificate. Additionally, the CA software did not enforce subject consistency across reissuances, preventing early detection

Remediation description:
To resolve the issue, the affected SubCA certificate was revoked, and a new certificate with the original Subject DN was issued. The updated certificate was disclosed to the CCADB, and checks ensured proper CRL functionality.

Commitment Summary
To prevent similar incidents, the Actalis has:

  • Implemented continuous monitoring using SSLMate's CRL Watch for proactive detection of inconsistencies.
  • Launched internal training to enhance awareness of the technical implications of CA certificate subject modifications upon re-issuance.

I'll close this on or about Wed. 2-April-2025, unless further discussion is needed.

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