Open Bug 1927532 Opened 3 months ago Updated 3 days ago

SSL.com: Issuance of certificates using keys previously reported as compromised

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: rebeccak, Assigned: rebeccak)

Details

(Whiteboard: [ca-compliance] [dv-misissuance])

Attachments

(2 files)

Appendix A - 6.1.1.3(4).csv
7.84 KB, application/octet-stream
Details
Appendix B - 4.9.1.1.csv
12.31 KB, application/octet-stream
Details

Preliminary Incident Report

Summary

On 2024-10-25, SSL.com was informed by a Root Store Program representative about a mis-issuance of TLS certificates using keys which had been previously reported by the same actor as compromised, in violation of BR, section 6.1.1.3 (4).

The report included steps to reproduce the issue through ACME; it also included the following illustrative non-exhaustive list of mis-issued certificates:

In response to this report, SSL.com performed the following:

  • The Certificate Problem Report (CPR) process was initiated immediately; once the issue was confirmed, the relevant certificates (total: 4, all belonging to the same Subscriber) were revoked within 24 hours from the time we received the report, and the keys in question were added to our blocklist. Email notifications were sent to the Reporter’s and the Subscriber’s email addresses.

  • Our Security Auditing team was informed, and the Incident Management Process was triggered. The Security Auditing team started gathering facts to assess the issue, investigate how this occurred and determine the population of affected certificates.

  • Further investigation revealed another 26 certificates issued with keys that correspond to certificates previously revoked with reason “keyCompromise”. These certificates were also revoked within 24 hours from the time of discovery, the associated keys were added to the blocklist, and email notifications were sent to the Subscribers.

  • Upon initial investigation, it was determined that a manual process was in place to blocklist keys in the context of a CPR, but there was a gap in automatically blocklisting keys associated with self-service “keyCompromise” revocations.

Per discussions between Security Auditing and Engineering, the following technical controls were successfully tested and deployed to production as emergency fixes to address this issue in the short term and prevent re-occurrence, while we work on a permanent fix.

A scheduler scans every 5 minutes to identify any new “keyCompromise” revocations, add them to the table of blocklisted keys and thus prevent any further issuances with the same key. With the current implementation, due to propagation delays, the maximum time between a “keyCompromise” revocation and blocking the key is 15 minutes. We are working internally and with our CA software vendor for a permanent fix that minimizes this delay.

Further, a scan is automatically initiated to identify any other non-expired non-revoked certificates with the same key and, in case of any matches, inform the relevant teams. In such cases, the process entails verifying whether the key compromise is asserted or demonstrated to determine the scope of revocation and proceed accordingly within the required timeline (24 hours).

SSL.com will file a full incident report on or before November 7.

Assignee: nobody → rebeccak
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance] [dv-misissuance]

Isn't there a chance that some subscribers are omitting the revocation reason even for key compromise revocations?

I think this is a real possibility considering that the default reasonCode required by Mozilla for "tools" is "unspecified". From https://wiki.mozilla.org/CA/Revocation_Reasons

Tools that the CA operator provides to the certificate subscriber MUST allow for these options to be easily specified when the certificate subscriber requests revocation of their certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL).

Additionally, for ACME, specifying the revocation reason is optional and the "unspecified" revocation reason is the default recommendation. From RFC 8555:

7.6. Certificate Revocation
...
reason (optional, int): One of the revocation reasonCodes defined in Section 5.3.1 of [RFC5280] to be used when generating OCSP responses and CRLs. If this field is not set, the server SHOULD omit the reasonCode CRL entry extension when generating OCSP responses and CRLs.

There might even exist ACME clients not supporting to set a different revocation reason.

Isn't it better to err on the side of caution for this type of issues and additionally prevent the reuse of keys whose certificate has been revoked with reason “unspecified” considering that some of them might be compromised?

PS: An interesting related document can be found at https://csrc.nist.gov/files/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc-1998/final/docs/paperg2.pdf

Hi Jaime! I think this is a very interesting idea, but off-topic for this bugzilla incident report (which concerns handling revocation requests which do specify keyCompromise, not handling ones which don't), so I've replied on MDSP: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/p-FKzpu5tMo

We would like to inform the community that we will be posting our Final Incident Report tomorrow, November 8, 2024. We appreciate your patience.

Summary: SSL.com: Issuance of ACME TLS certificates using keys previously reported as compromised → SSL.com: Issuance of certificates using keys previously reported as compromised

Appendix A

Appendix B

Attachment #9436514 - Attachment mime type: application/vnd.ms-excel → application/octet-stream

Final Incident Report

Summary

On 2024-10-25, SSL.com was informed by the Chrome Root Store about a mis-issuance of TLS certificates through the SSL.com ACME service, using keys which had been previously reported by the same Subscriber as compromised, in violation of section 6.1.1.2 of the SSL.com CP/CPS and section 6.1.1.3 (4) of the BR.

Our initial investigation also indicated that revocations with reason "keyCompromise" were not followed up to request from the Subscribers to confirm possession of the private keys and potentially proceed with revocation of all non-expired certificates associated with the same key, as required by sections 4.7.1.2 and 4.9.1.1 of the SSL.com CP/CPS.

After completing our investigation, we determined that the issue was linked to the SSL.com Subscriber "self-service" revocation processes, when the revocation reason was "keyCompromise", regardless of the certificate type or whether the revocation was triggered through the ACME service or the RA Portal.

Impact

Upon receiving the report and after conducting an initial investigation, 30 non-expired non-revoked certificates were found to be affected. Within 24 hours these certificates were revoked, and temporary measures were introduced to prevent future issuance of reported compromised keys.

Our investigation was extended to cover the entire corpus of certificates regardless of their status to determine the full impact of the issue and the affected period. This resulted in determining the following two populations of affected certificates:

  • Appendix A: 99 TLS certificates issued between 2022-09-26 and 2024-10-25 in violation of clause 6.1.1.2 of the SSL.com CP/CPS and clause 6.1.1.3 (4) of the BR

  • Appendix B: 152 certificates issued between 2022-01-11 and 2024-10-25 were not retroactively investigated for possible follow-up actions in violation of sections 4.7.1.2 and 4.9.1.1 of the SSL.com CP/CPS and the Mozilla Root Store Policy

    • 148 TLS
    • 1 S/MIME
    • 1 Code Signing
    • 2 Document Signing

Timeline

All times are UTC.

To provide the necessary background, the timeline starts with relevant events prior to October 25, 2024 that SSL.com received the report by the Google Root Store. Bold font has been used to highlight the points in time that the issues in question were introduced.

2020-10-19:

  • BR 1.7.3 was issued. Section 6.1.1.3 clarified that "The CA SHALL reject a certificate request if [...] The CA has previously been made aware that the Applicant's Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1;". Section 4.9.1.1 required that the CA obtains evidence that the "Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;".

2020-11-10: 

  • SSL.com enabled ACME service. This added a path for Subscribers to choose the revocation reason when revoking a certificate. Note that our CA software does not currently flag which revocation requests are signed with the private key associated with the to-be-revoked certificate, thus self-service revocations with reason "keyCompromise", despite being authenticated, are basically claims that a key is compromised rather than a demonstration of that fact.

2021-02-16: 

  • CP/CPS v1.11 issued incorporating BR 1.7.3. This introduced the non-compliance for the ACME revocation service.

2022-04-29: 

2022-09-14: 

  • CP/CPS v1.16 was issued, incorporating Mozilla Root Store Policy 2.8.

2022-09-20:

  • The RA Portal was updated to allow Subscribers to select a revocation reason when performing self-service revocation. This added another path for Subscribers to choose the revocation reason when revoking. In case of revocations with reason "keyCompromise", the Portal sends a notification to the support team to perform any follow-up actions. Due to a filtering rule which was applied in the support ticketing system to reduce the amount of non-actionable alerts, these alerts were blocked. This introduced the non-compliance for the RA Portal revocation service.

2024-10-16

  • 11:01: SSL.com submitted a feature request to the CA software vendor to automatically blocklist keys involved in revocations with reason "keyCompromise"

2024-10-25:

  • 20:53: A report about a potential violation of BR and the SSL.com CP/CPS is received at support@ssl.com from a member of the Chrome Root Store

  • 21:02: Support team escalated the matter internally

  • 21:07: Support team replied to the reporter confirming receipt of the report

  • 21:28: Validation team informed the reporter about the initiation of the investigation

  • 21:43: Compliance team was notified of the event, and an internal ticket was created to investigate

2024-10-26:

  • 08:34: Compliance team completed an initial review and escalated the event to an incident in accordance with the SSL.com Incident Management Policy

  • 10:02: 26 additional non-expired non-revoked certificates were found during the investigation

  • 12:04: The already compromised keys were manually added to the CA software blocklist

  • 16:55: The initially reported certificates were revoked

  • 16:57: A temporary mechanism was put in place to prevent future issuance of reported compromised keys

  • 18:34: The validation team informed the reporter about the revocation of the reported certificates

  • 19:40: A scanning mechanism was introduced to alert internal teams in case of any non-expired non-revoked certificates that share the same key after a revocation of a certificate with reason "keyCompromise"

2024-10-27:

  • 07:34: All 26 non-expired non-revoked certificates, found to share keys with certificates revoked with reason "keyCompromise", were revoked

  • 22:32: Validation team informed the Subscribers of the above 26 affected certificates about the revocation

2024-10-28

  • 17:17: SSL.com posted a Preliminary Incident Report to Bugzilla Bug 1927532 - SSL.com: Issuance of certificates using keys previously reported as compromised

  • 18:48: Compliance officer notified Root Stores independently, about this Bugzilla bug

2024-10-29 to 2024-11-07

  • A detailed investigation/collection of evidence surrounding the events that led to the incident was conducted along with a Root Cause Analysis and discussion of possible remediation actions

  • The team extended the investigation to cover the entire corpus of certificates issued by SSL.com (including expired and revoked) to identify the period during which the issue existed

2024-11-05

  • 19:57: The extended investigation was completed resulting in the final populations of affected certificates (see Appendices A and B)

2024-11-06

  • 19:06: The revocation reasons of unexpired TLS certificates were retroactively updated, along with the revocation reasons and dates of any Code Signing and Document Signing certificates affected to denote the key compromise

2024-11-08

  • Submission of the Final Incident Report (this report)

Root Cause Analysis

The Root Cause Analysis (RCA) is split into two parts to address the separate events that led to the non-compliance of the ACME revocation service on 2021-02-16 and of the RA Portal revocation service on 2022-09-30.

Problem Statement:

Mis-issuance of TLS certificates using keys that had been previously reported by the same Subscribers as compromised. Revocations performed by Subscribers with reason "keyCompromise" were not followed up to request from the Subscribers to confirm possession of the private keys and potentially proceed with revocation of all non-expired certificates associated with the same keys.

RCA for the ACME revocation service

1. Why did the above two violations occur?

The keys involved in the previous revocations were not included in the blocklist to prevent further issuances with the same keys. No action was taken to request proof of possession of those keys and retroactively perform cascading revocations if needed.

2. Why were the keys not included in the block list to prevent further issuance or take further action to request proof of possession?

No process was in place in the SSL.com ACME service to treat the "keyCompromise" revocation event different than the other revocation events.

3. Why was no process in place to treat "keyCompromise" revocations?

At the time of the SSL.com ACME service implementation (November 2020) the interpretation was that key compromises would need to be demonstrated through Certificate Problem Reports (CPR) rather than revocations. When the issue was discussed in the community and Mozilla Root Store Policy 2.8 was introduced in October 2022 (to require revocations with reason codes, provide guidance for blocking issuances with the same keys and for determining the scope of cascading revocations), the ACME service was not updated to meet the requirements of the updated SSL.com CP/CPS.

4. Why was the ACME service not updated to meet the requirements of the updated SSL.com CP/CPS?

The change didn't trigger a thorough analysis to assess all the implications of this change for the ACME service.

5. Why was no thorough analysis conducted for updating the ACME service?

Revocation with reason codes was already supported by the SSL.com ACME service and it was considered that the underlying CA software didn't require further configurations or system updates.

RCA for the RA Portal revocation service

1. Why did the above two violations occur?

The keys involved in the previous revocations were not included in the blocklist to prevent further issuances with the same keys. No action was taken to request proof of possession of those keys and retroactively perform cascading revocations if needed.

2. Why were the keys not included in the blocklist to prevent further issuance or take further action to request proof of possession?

The process to add these keys to the blocklist and alert the relevant teams upon revocations caused by the Subscribers themselves (self-service revocation) failed.

3. Why did the process to add these keys to the blocklist and alert the relevant teams fail?

The process, which was implemented in the RA Portal on 2022-09-20, to allow Subscribers to choose the revocation reason, was based on an automated notification being triggered and sent to a designated internal support email address by the revocation system. The relevant teams did not receive these notifications to perform any follow-up actions.

4. Why did the relevant teams not receive the notifications to perform any follow up actions?

Our support ticketing system blocked the sending address.

5. Why did our support ticketing system block the sending address?

To block a flood of unnecessary notifications from the same address, a filtering rule was applied to send all emails from that address to the spam folder. This inadvertently blocked the meaningful notifications, as well.

Lessons Learned

What went well

  • Prompt response; revocation of all non-expired non-revoked certificates affected, and temporary remediation measures placed within 24 hours.
  • A thorough retroactive analysis, dating back to 2020, identified all the events that pertain to the incident.
  • Good practices were applied with the retroactive update of revocation reasons and revocation dates, depending on the type of certificate.

What didn't go well

  • The revocation alerting mechanism did not use the proper delivery system.
  • Poor communication between teams on handling changes to alert systems, like mail filtering.
  • Failure to identify implications of CPS/policy updates to all systems.
  • Over-dependence on the CA software vendor to address normative updates and make timely updates to their software.
  • Lack of detective mechanism to identify potential violations of 6.1.1.3 (4) and 4.9.1.1.

Where we got lucky

  • Even though the issues were not introduced recently, only a limited number of certificates were affected.

Action Items

# Action Item Kind Due Date
1 Update the revocation alerting system to utilize the same delivery method used for Certificate Problem Reports when a revocation with reason "keyCompromise" occurs. Prevent 2024-11-15
2 Introduce automated hourly scanning to identify any additional non-expired non-revoked certificates with the same key and, in case of any matches, inform the relevant internal teams of possible cascading revocations. This addresses 4.9.1.1 for all systems (ACME, RA Portal). Prevent Already implemented
3 Update the ACME service to detect revocations signed with the private key of the certificate and propagate this information to assist the relevant teams with any cascading revocations. Detect 2024-11-29
4 Introduce a scheduled scan to identify any new "keyCompromise" revocations and add the relevant keys to the blocklisted table (temporary measure). Prevent Already implemented
5 Update key blocking mechanism to automatically add keys involved in "keyCompromise" revocations to the "global" blocklist near real time, regardless of the path utilized to perform these revocations. This addresses 6.1.1.3(4) for all systems (ACME, RA Portal). Prevent 2025-03-31
6 Work with our CA software vendor on our 2024-10-16 feature request regarding a native blocklisting mechanism of compromised keys. Prevent 2025-03-31
7 Introduce automated hourly scanning to identify any certificates issued with the same key after the key was declared compromised and, in case of any matches, inform the relevant teams about a possible violation. Detect 2024-11-22
8 Review and update filtering rules in the support ticketing system to identify any other actionable email notifications that would require a distinct delivery method and filter any unnecessary email notifications. Prevent/Mitigate 2024-12-13
9 Update our internal procedures to provide detailed guidance to the teams involved on how to handle the above alerts. Prevent 2025-01-17
10 Update our CP/CPS Change Management System to require a thorough analysis of possible implementation-level implications by all key roles. Prevent/Mitigate 2025-01-30

Appendix A – Certificates mapping to violation of 6.1.1.3(4)

See attachment "Appendix A – 6.1.1.3(4).csv".

Appendix B – Certificates mapping to violation of 4.9.1.1

See attachment "Appendix B - 4.9.1.1.csv".

Hi Rebecca,

Thanks for filing this detailed incident report - and for covering the expected items described by the CCADB Incident Reporting Guidelines quite well.

A few questions below:

(1) Related to the corpus of affected certificates, can you please share more information about how these were identified?

For example, we can’t seem to find 1 or 2 on either Appendix attachment, but they appear to fit the pattern of problematic certificates described by the report.

A description of how SSL.com evaluated its corpus will help us understand why the above two certificates are not represented in the Appendices, and may also be considered helpful by other members of the community when evaluating other potential instances of the same failure mode, including their own.

(2) The timeline states “11:01: SSL.com submitted a feature request to the CA software vendor to automatically blocklist keys involved in revocations with reason "keyCompromise" - can you share what motivated this outreach to the CA vendor?

(3) The “What didn’t go well” list describes “Over-dependence on the CA software vendor to address normative updates and make timely updates to their software.” While the “Action Items” list offers a specific example related to native blocklisting of compromised keys, can you share how the broader challenge will be addressed, and the possible Action Items that should be considered alongside it?

(4) Has SSL.com contemplated any potential changes to its own policies as a result of this incident?

Thanks,
Ryan

Flags: needinfo?(rebeccak)

Hi Rebecca, and thanks for the detailed report!

Two of your actions items are:

Update key blocking mechanism to automatically add keys involved in "keyCompromise" revocations to the "global" blocklist near real time, regardless of the path utilized to perform these revocations.

and

Update the ACME service to detect revocations signed with the private key of the certificate and propagate this information to assist the relevant teams with any cascading revocations.

My reading of these two points is that SSL.com plans to block all keys reported as compromised regardless of whether that compromise was demonstrated via the ACME protocol, but then only do (manual) cascading revocations of existing certs if that compromise was in fact demonstrated. Is that understanding correct? (This is not a leading question; I don't think you're doing something wrong, I'm just genuinely curious.)

Thank you Ryan and Aaron for your questions. We plan to answer you within the next week, as we continue to gather the information you have requested.

Flags: needinfo?(rebeccak)

(In reply to Aaron Gable from comment #8)

Hi Rebecca, and thanks for the detailed report!

Two of your actions items are:

Update key blocking mechanism to automatically add keys involved in "keyCompromise" revocations to the "global" blocklist near real time, regardless of the path utilized to perform these revocations.

and

Update the ACME service to detect revocations signed with the private key of the certificate and propagate this information to assist the relevant teams with any cascading revocations.

My reading of these two points is that SSL.com plans to block all keys reported as compromised regardless of whether that compromise was demonstrated via the ACME protocol, but then only do (manual) cascading revocations of existing certs if that compromise was in fact demonstrated. Is that understanding correct? (This is not a leading question; I don't think you're doing something wrong, I'm just genuinely curious.)

Hi Aaron,

We currently block all keys reported as compromised and manually revoke any existing certificates of the same Subscriber, regardless of demonstration. If possession of the key is demonstrated in accordance with our CP/CPS 4.9.12, we extend the scope of cascading revocations to all Subscribers.

We understand that blocking keys for further issuance across the board (i.e., for all Subscribers) without demonstration of the possession of the private key is not the most optimal solution, but we adopted this policy as the secure path.

Ideally, we want to update our systems to automatically scope the blocking and the cascading revocations depending on whether the possession was demonstrated or not. For example, if the ACME revocation request was signed with the key, it should be automatically treated as “possession demonstrated” and the scope of the key blocking and of the cascading revocations should be global. If possession cannot be automatically determined, the Subscriber will be requested to demonstrate possession and proceed accordingly. At the moment, this is more of a long-term goal that will require extensive engineering and collaboration with our CA software vendor.

Thanks for the clarification! Note that cascading revocation even just of other certs issued to the same Subscriber can lead to unexpected consequences, as demonstrated in https://bugzilla.mozilla.org/show_bug.cgi?id=1742704. Obviously I support the move towards automation, and hope that long-term goal proceeds well for you.

(In reply to Ryan Dickson from comment #7)

Hi Rebecca,

Hi Ryan - Please see our answers below.

Thanks for filing this detailed incident report - and for covering the expected items described by the CCADB Incident Reporting Guidelines quite well.

A few questions below:

(1) Related to the corpus of affected certificates, can you please share more information about how these were identified?

The populations were generated by using the following procedure:

  1. Obtained the Subject Key IDs (SKID), along with the earliest per SKID revocation date of the certificates, that had been revoked with revocation reason “keyCompromise”

  2. Counted the number of certificates corresponding to each SKID

  3. Filtered out the SKIDs that corresponded to a single certificate

  4. Identified any certificates that both corresponded to the remaining SKIDs and expired after the earliest key compromise revocation date of their SKIDs

  5. Filtered the certificates to the ones that were issued after the minimum key compromise revocation dates -> Appendix A – Certificates mapping to violation of 6.1.1.3(4)

  6. Filtered the certificates to the ones that were not revoked or did not expire within 24h of the minimum key revocation dates -> Appendix B – Certificates mapping to violation of 4.9.1.1

For example, we can’t seem to find 1 or 2 on either Appendix attachment, but they appear to fit the pattern of problematic certificates described by the report.

They seem to fit the pattern, but they are false positives.

Certificate 1 (notBefore: 2024-10-14 07:02:41 UTC, revoked at: 2024-10-14 07:13:01 UTC) is not affected, as it was the first certificate in the series that was revoked with reason “keyCompromise”. Please note that revocation reasons of any prior revocations of certificates sharing the same key were retroactively updated to “keyCompromise”, as part of our incident response, to convey more accurate information to relying parties in accordance with Mozilla’s guidance https://wiki.mozilla.org/CA/Revocation_Reasons#Updating_CRL_Entries (see also point 3 of section “What went well” of the final incident report). With this action, the certificate status of all certificates that share the same key now have revocation reason "keyCompromise".

Certificate 2 (notBefore: 2024-10-14 06:35:53 UTC, revoked at: 2024-10-14 07:14:12 UTC) is also not affected because it was issued before certificate 1, and was revoked within 24 hours.

Overall, five certificates were issued with the same key after the initial “keyCompromise” revocation event of this series. These certificates are included in Appendix A. Similarly, there were two certificates that were not investigated for cascading revocations within the required 24-hour timeline (The two certificates are included in Appendix B).

A description of how SSL.com evaluated its corpus will help us understand why the above two certificates are not represented in the Appendices, and may also be considered helpful by other members of the community when evaluating other potential instances of the same failure mode, including their own.

Please refer to (1) above.

(2) The timeline states “11:01: SSL.com submitted a feature request to the CA software vendor to automatically blocklist keys involved in revocations with reason "keyCompromise" - can you share what motivated this outreach to the CA vendor?

The timing of this feature request is coincidental to this incident (though it might have had prevented it). The feature request was submitted as part of our continuous improvement cycle to replace the current manual process of blocklisting keys reported/demonstrated as compromised with an automated mechanism. We considered that this should be supported centrally at the CA level to cover all cases, and for this reason we created the feature request.

(3) The “What didn’t go well” list describes “Over-dependence on the CA software vendor to address normative updates and make timely updates to their software.” While the “Action Items” list offers a specific example related to native blocklisting of compromised keys, can you share how the broader challenge will be addressed, and the possible Action Items that should be considered alongside it?

That is correct, action item no. 6 is related to addressing a manifestation of this dependency; a native blocklisting mechanism of compromised keys.

With regards to the broader challenge, the updated CP/CPS Change Management System (see action item no. 10 for more information) specifies a more thorough analysis of any policy updates to our systems, including verification of any third-party software that participates in the fulfilment of an updated requirement. Other initiatives have already been underway: transition to in-house software for parts of our PKI, in-house customizations of the CA software to address any gaps when a vendor update is not available, and closer collaboration with the software vendors.

(4) Has SSL.com contemplated any potential changes to its own policies as a result of this incident?

Yes. Action item no. 10 addresses upcoming changes to our CP/CPS Change Management System, i.e. improvements in policies, procedures and tooling that will be used to adopt changes in normative requirements. This maps to the root cause of the failure to identify implications (and update accordingly) the ACME revocation service when the Mozilla Root Store Policy 2.8 was introduced two years after SSL.com deployed its ACME service.

The root cause of the RA Portal revocation service was different, as it had to do with the configuration of the notification system. Action item no. 8 includes retroactive review of existing filtering rules and notifications. Forward-looking, this failure illustrated the importance of choosing the proper notification delivery mechanism, especially when it comes to actionable items.

Thanks,
Ryan

This is an update to report our progress with remediation actions.

The following action items have already been implemented:

# Action Item Kind Due Date
1 Update the revocation alerting system to utilize the same delivery method used for Certificate Problem Reports when a revocation with reason "keyCompromise" occurs. Prevent Completed
7 Introduce automated hourly scanning to identify any certificates issued with the same key after the key was declared compromised and, in case of any matches, inform the relevant teams about a possible violation. Detect Completed

We will continue to provide updates on the progress of our action items.

This is an update to report our progress with remediation actions.

The following action items have already been implemented:

# Action Item Kind Due Date
3 Update the ACME service to detect revocations signed with the private key of the certificate and propagate this information to assist the relevant teams with any cascading revocations. Detect Completed

No update at this time. Next update will be on or before 2024-12-13.

This is an update to report our progress with remediation actions.

# Action Item Kind Due Date
8 Review and update filtering rules in the support ticketing system to identify any other actionable email notifications that would require a distinct delivery method and filter any unnecessary email notifications. Prevent/Mitigate Completed

Action Item #8 has been completed and confirmed no other actionable emails were being filtered.

There is no updates at this time. We will post an update on or before 2025-01-17.

Whiteboard: [ca-compliance] [dv-misissuance] → [ca-compliance] [dv-misissuance] Next update 2025-01-17

The following action item has been completed:

# Action Item Kind Due Date
9 Update our internal procedures to provide detailed guidance to the teams involved on how to handle the above alerts. Prevent Completed

Our next update will be on or before 2025-01-30.

We have made progress to Action Item #10, but it is not complete. We will post another update next week.

Whiteboard: [ca-compliance] [dv-misissuance] Next update 2025-01-17 → [ca-compliance] [dv-misissuance]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: