Closed Bug 1988405 Opened 11 months ago Closed 10 months ago

TunTrust: Issue with Valid test Certificate

Categories

(CA Program :: CA Certificate Compliance, task)

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: pki, Assigned: pki)

Details

(Whiteboard: [ca-compliance] [policy-failure])

Preliminary Incident Report

Summary

  • Incident description:
    On September 11, 2025, at 17:39 UTC, we received a report indicating that the website associated with our valid OV SSL test certificate was serving an expired certificate.
    Our investigation determined that the domain was incorrectly presenting the expired certificate instead of the intended valid test certificate due to an incorrect IP address declared in the DNS records for the Disaster Recovery (DR) site.
    The DNS records were corrected on September 11, 2025, at 20:09 UTC to reflect the correct public IP address. Since then, the domain has been serving the valid test certificate as intended : https://validovssl.tuntrust.tn/
    No other publicly accessible components were affected. This issue was limited exclusively to the valid OV SSL test website certificate.

  • Relevant policies:

  • Source of incident disclosure:
    Third Party Reported

Assignee: nobody → pki
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance] [policy-failure]

Full Incident Report

Summary

  • CA Owner CCADB unique ID: A000785

  • Incident description:
    In the context of the issuance of the test website certificates with ACME, we set a new host in May 22nd 2025 with a new public IP address. The IP Address of the valid OV SSL certificate in the main site was updated in the DNS records but not the one in the disaster recovery site. This issue remained undetected since we were using the main site. However, as part of a maintenance operation, a DNS failover was conducted and therefore all IP addresses in the DNS records were switched to the Disaster Recovery site, on September 10th 2025 at 11:09 UTC.
    The hosts with a valid OV SSL certificate in the main and disaster recovery site remained operational but not publicly accessible using the domain name due to the DNS records not being updated with the correct IP address.
    The former host had still the OV SSL certificate that expired on August 21st 2025, installed in it.
    As a result, validovssl.tuntrust.tn was incorrectly serving an expired certificate instead of the intended valid test certificate.
    On September 11, 2025, at 17:39 UTC, we received a report indicating that the website associated with our valid OV SSL test certificate was serving an expired certificate.
    Therefore, an investigation was conducted and the DNS records have been corrected on September 11th 2025 at 20:09 UTC to reflect the updated public IP address. Since then, the domain has been serving the valid test certificate as intended.
    No other publicly accessible components were affected. This issue was limited exclusively to the valid OV SSL test website certificate.

  • Timeline summary:

    • Non-compliance start date: September 10th 2025 at 11:09 UTC
    • Non-compliance identified date: September 11th 2025 at 17:39 UTC
    • Non-compliance end date: September 11th 2025 at 20:09 UTC

  • Relevant policies:

  • Source of incident disclosure:
    Third Party Reported.

Impact

  • Total number of certificates: 01
  • Total number of "remaining valid" certificates: N/A
  • Affected certificate types: OV SSL
  • Incident heuristic: https://validovssl.tuntrust.tn/
  • Was issuance stopped in response to this incident, and why or why not?: No because this incident is not related to certificate issuance.
  • Analysis: N/A
  • Additional considerations: N/A

Timeline

Date Description
2025-09-10 11:09 UTC A maintenance operation triggered a failover, redirecting all DNS records to the DR site.
2025-09-11 17:39 UTC A Problem Report was received indicating that the website associated with the valid OV SSL test certificate was serving an expired certificate.
2025-09-11 19:00 UTC An acknowledgment was sent to the entity filing the Certificate Problem Report.
2025-09-12 13:26 UTC A preliminary report on the findings was sent to the entity filing the Certificate Problem Report.
2025-09-13 10:05 UTC A preliminary incident report was filed on Bugzilla.
2025-09-11 20:09 UTC DNS records were updated to point to the correct public IP address. Following this action, the domain immediately began serving the intended valid test certificate as expected.

Related Incidents

These are examples of related incidents from other CAs:

Bug Date Description
Bug 1962809 2025-04-25 Valid Test Website Certificate is expired
Bug 1904038 2024-06-21 Valid Test Website Certificate is expired.
Bug 1726333 2021-08-18 Valid Test Website Certificate is expired.
Bug 1730291 2021-09-10 Valid Test Website Certificate is expired.

Root Cause Analysis

Contributing Factor #1: Insufficient monitoring

  • Description:
    Monitoring of the valid OV test certificates was focused on the internal network, verifying certificate expiration and system availability. External monitoring of the public-facing address was not in place to verify that the correct certificate was being served, which allowed the issue to go undetected.
  • Timeline:
    Since the deployment of the test certificates in 2019.
  • Detection:
    The issue was detected only after it was reported externally. Internal monitoring was in place to verify certificate validity and system availability, but it was limited to checks from within the internal network. This gap in monitoring allowed the issue to persist undetected.
  • Interaction with other factors:
    This gap in monitoring interacted with the outdated DNS configuration (Root Cause #3) and the fact that no external validation checks were performed after DNS failover (Root cause #2). As a result, the incorrect DNS entry serving the expired certificate went unnoticed.

Contributing Factor #2: Insufficient checks after DNS failover

  • Description:
    Following the DNS failover, verification was performed to ensure that the host was publicly accessible. However, the check did not include confirming that the correct certificate was being served.
  • Timeline:
    After DNS failover on September 10th 2025 at 11:09 UTC.
  • Detection:
    This contributing factor was detected during the post-incident investigation. The existing verification process focused solely on confirming that services were reachable following DNS failover. Because certificate validation was not part of the standard verification step, the expired certificate on the DR host went unnoticed. This limited scope of verification acted as a missed safeguard, allowing the issue to persist until externally reported.
  • Interaction with other factors:
    The limited scope of the failover verification, focused only on accessibility, combined with the lack of external monitoring (Root Cause #1), allowed the expired certificate on the DR host to remain undetected.

Contributing Factor #3: Inconsistency in the process of changing the IP address

  • Description:
    After the host in the DR site was set up, its IP address in the DNS records was not updated. This was initially intended as a temporary measure during the ACME issuance procedure with MPIC to avoid conflicts between the main and DR sites.

  • Timeline:
    May 22nd 2025

  • Detection:
    This factor was identified once the incident occurred and traffic was redirected to the DR site. The outdated DNS record had not interfered with normal operations as long as the main site remained active, which explains why the issue avoided detection prior to failover. The absence of external monitoring and the reliance on internal checks meant that the outdated configuration was not flagged, and it only became apparent when the DR host began serving traffic.

  • Interaction with other factors:
    The absence of external monitoring (Root Cause #1) and the limited scope of failover verification (Root Cause #2) did not prevent or detect this misconfiguration (Root Cause #3), which allowed the issue to persist until it was externally reported.

  • Root Cause Analysis methodology used:
    5 Whys:

    • Why was the expired certificate served? → DNS pointed to the wrong DR host.
    • Why was DNS pointing incorrectly? → It wasn’t updated after DR host setup.
    • Why wasn’t it updated? → It was left as a temporary measure during ACME issuance. (Root cause #3)
    • Why did no one catch this? → Monitoring was internal only. (Root cause #1)
    • Why did the failover check not catch it? → Verification didn’t include certificate checks. (Root cause #2)

Lessons Learned

  • What went well:
    The problem reporting process was carried out in accordance with temporal requirements of the Root Stores.
  • What didn’t go well:
    Had the issue not been detected by the entity filing the Problem Certificate Report, it could have remained unnoticed, and the valid test website might have continued serving the incorrect certificate until the end of the maintenance period.
  • Where we got lucky: N/A
  • Additional: N/A

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Configure the monitoring system to verify, via the external network, that the served certificates are valid and not expired. Detect Root Cause # 1 & What didn’t go well Alerts received in case of unavailability, certificate expiration, etc. 2025-09-30 Ongoing
Update the DNS failover verification procedure to include verification of test website certificates, ensuring that the correct certificates are being served. Prevent Root Cause # 2 Misconfiguration in DNS records is detected upon DNS failover 2025-10-06 Ongoing
Configure the DR site host to automatically obtain a certificate through ACME when it detects that it is the publicly accessible host. Mitigate Root Cause # 3 DR host configuration updated to enable ACME-based issuance 2025-10-06 Ongoing

Appendix

N/A

Following the implementation of Action Item #1, this is an update to the incident report.

Full Incident Report

Summary

  • CA Owner CCADB unique ID: A000785

  • Incident description:
    In the context of the issuance of the test website certificates with ACME, we set a new host in May 22nd 2025 with a new public IP address. The IP Address of the valid OV SSL certificate in the main site was updated in the DNS records but not the one in the disaster recovery site. This issue remained undetected since we were using the main site. However, as part of a maintenance operation, a DNS failover was conducted and therefore all IP addresses in the DNS records were switched to the Disaster Recovery site, on September 10th 2025 at 11:09 UTC.
    The hosts with a valid OV SSL certificate in the main and disaster recovery site remained operational but not publicly accessible using the domain name due to the DNS records not being updated with the correct IP address.
    The former host had still the OV SSL certificate that expired on August 21st 2025, installed in it.
    As a result, validovssl.tuntrust.tn was incorrectly serving an expired certificate instead of the intended valid test certificate.
    On September 11, 2025, at 17:39 UTC, we received a report indicating that the website associated with our valid OV SSL test certificate was serving an expired certificate.
    Therefore, an investigation was conducted and the DNS records have been corrected on September 11th 2025 at 20:09 UTC to reflect the updated public IP address. Since then, the domain has been serving the valid test certificate as intended.
    No other publicly accessible components were affected. This issue was limited exclusively to the valid OV SSL test website certificate.

  • Timeline summary:

    • Non-compliance start date: September 10th 2025 at 11:09 UTC
    • Non-compliance identified date: September 11th 2025 at 17:39 UTC
    • Non-compliance end date: September 11th 2025 at 20:09 UTC

  • Relevant policies:

  • Source of incident disclosure:
    Third Party Reported.

Impact

  • Total number of certificates: 01
  • Total number of "remaining valid" certificates: N/A
  • Affected certificate types: OV SSL
  • Incident heuristic: https://validovssl.tuntrust.tn/
  • Was issuance stopped in response to this incident, and why or why not?: No because this incident is not related to certificate issuance.
  • Analysis: N/A
  • Additional considerations: N/A

Timeline

Date Description
2025-09-10 11:09 UTC A maintenance operation triggered a failover, redirecting all DNS records to the DR site.
2025-09-11 17:39 UTC A Problem Report was received indicating that the website associated with the valid OV SSL test certificate was serving an expired certificate.
2025-09-11 19:00 UTC An acknowledgment was sent to the entity filing the Certificate Problem Report.
2025-09-12 13:26 UTC A preliminary report on the findings was sent to the entity filing the Certificate Problem Report.
2025-09-13 10:05 UTC A preliminary incident report was filed on Bugzilla.
2025-09-11 20:09 UTC DNS records were updated to point to the correct public IP address. Following this action, the domain immediately began serving the intended valid test certificate as expected.

Related Incidents

These are related incidents from other CAs.

Bug Date Description
Bug 1962809 2025-04-25 Valid Test Website Certificate is expired.
Bug 1904038 2024-06-21 Valid Test Website Certificate is expired
Bug 1726333 2021-08-18 Valid Test Website Certificate is expired.
Bug 1730291 2021-09-10 Valid Test Website Certificate is expired.

Root Cause Analysis

Contributing Factor #1: Insufficient monitoring

  • Description:
    Monitoring of the valid OV test certificates was focused on the internal network, verifying certificate expiration and system availability. External monitoring of the public-facing address was not in place to verify that the correct certificate was being served, which allowed the issue to go undetected.
  • Timeline:
    Since the deployment of the test certificates in 2019.
  • Detection:
    The issue was detected only after it was reported externally. Internal monitoring was in place to verify certificate validity and system availability, but it was limited to checks from within the internal network. This gap in monitoring allowed the issue to persist undetected.
  • Interaction with other factors:
    This gap in monitoring interacted with the outdated DNS configuration (Root Cause #3) and the fact that no external validation checks were performed after DNS failover (Root cause #2). As a result, the incorrect DNS entry serving the expired certificate went unnoticed.

Contributing Factor #2: Insufficient checks after DNS failover

  • Description:
    Following the DNS failover, verification was performed to ensure that the host was publicly accessible. However, the check did not include confirming that the correct certificate was being served.
  • Timeline:
    After DNS failover on September 10th 2025 at 11:09 UTC.
  • Detection:
    This contributing factor was detected during the post-incident investigation. The existing verification process focused solely on confirming that services were reachable following DNS failover. Because certificate validation was not part of the standard verification step, the expired certificate on the DR host went unnoticed. This limited scope of verification acted as a missed safeguard, allowing the issue to persist until externally reported.
  • Interaction with other factors:
    The limited scope of the failover verification, focused only on accessibility, combined with the lack of external monitoring (Root Cause #1), allowed the expired certificate on the DR host to remain undetected.

Contributing Factor #3: Inconsistency in the process of changing the IP address

  • Description:
    After the host in the DR site was set up, its IP address in the DNS records was not updated. This was initially intended as a temporary measure during the ACME issuance procedure with MPIC to avoid conflicts between the main and DR sites.

  • Timeline:
    May 22nd 2025

  • Detection:
    This factor was identified once the incident occurred and traffic was redirected to the DR site. The outdated DNS record had not interfered with normal operations as long as the main site remained active, which explains why the issue avoided detection prior to failover. The absence of external monitoring and the reliance on internal checks meant that the outdated configuration was not flagged, and it only became apparent when the DR host began serving traffic.

  • Interaction with other factors:
    The absence of external monitoring (Root Cause #1) and the limited scope of failover verification (Root Cause #2) did not prevent or detect this misconfiguration (Root Cause #3), which allowed the issue to persist until it was externally reported.

  • Root Cause Analysis methodology used:
    5 Whys:

    • Why was the expired certificate served? → DNS pointed to the wrong DR host.
    • Why was DNS pointing incorrectly? → It wasn’t updated after DR host setup.
    • Why wasn’t it updated? → It was left as a temporary measure during ACME issuance. (Root cause #3)
    • Why did no one catch this? → Monitoring was internal only. (Root cause #1)
    • Why did the failover check not catch it? → Verification didn’t include certificate checks. (Root cause #2)

Lessons Learned

  • What went well:
    The problem reporting process was carried out in accordance with temporal requirements of the Root Stores.
  • What didn’t go well:
    Had the issue not been detected by the entity filing the Problem Certificate Report, it could have remained unnoticed, and the valid test website might have continued serving the incorrect certificate until the end of the maintenance period.
  • Where we got lucky: N/A
  • Additional: N/A

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Configure the monitoring system to verify, via the external network, that the served certificates are valid and not expired. Detect Root Cause # 1 & What didn’t go well Alerts received in case of unavailability, certificate expiration, etc. 2025-09-30 Complete
Update the DNS failover verification procedure to include verification of test website certificates, ensuring that the correct certificates are being served. Prevent Root Cause # 2 Misconfiguration in DNS records is detected upon DNS failover 2025-10-06 Ongoing
Configure the DR site host to automatically obtain a certificate through ACME when it detects that it is the publicly accessible host. Mitigate Root Cause # 3 DR host configuration updated to enable ACME-based issuance. 2025-10-06 Ongoing

Appendix

N/A

Following the implementation of Action Items #2 & 3, this is an update to the incident report.

Full Incident Report

Summary

  • CA Owner CCADB unique ID: A000785

  • Incident description:
    In the context of the issuance of the test website certificates with ACME, we set a new host in May 22nd 2025 with a new public IP address. The IP Address of the valid OV SSL certificate in the main site was updated in the DNS records but not the one in the disaster recovery site. This issue remained undetected since we were using the main site. However, as part of a maintenance operation, a DNS failover was conducted and therefore all IP addresses in the DNS records were switched to the Disaster Recovery site, on September 10th 2025 at 11:09 UTC.
    The hosts with a valid OV SSL certificate in the main and disaster recovery site remained operational but not publicly accessible using the domain name due to the DNS records not being updated with the correct IP address.
    The former host had still the OV SSL certificate that expired on August 21st 2025, installed in it.
    As a result, validovssl.tuntrust.tn was incorrectly serving an expired certificate instead of the intended valid test certificate.
    On September 11, 2025, at 17:39 UTC, we received a report indicating that the website associated with our valid OV SSL test certificate was serving an expired certificate.
    Therefore, an investigation was conducted and the DNS records have been corrected on September 11th 2025 at 20:09 UTC to reflect the updated public IP address. Since then, the domain has been serving the valid test certificate as intended.
    No other publicly accessible components were affected. This issue was limited exclusively to the valid OV SSL test website certificate.

  • Timeline summary:

    • Non-compliance start date: September 10th 2025 at 11:09 UTC
    • Non-compliance identified date: September 11th 2025 at 17:39 UTC
    • Non-compliance end date: September 11th 2025 at 20:09 UTC

  • Relevant policies:

  • Source of incident disclosure:
    Third Party Reported.

Impact

  • Total number of certificates: 01
  • Total number of "remaining valid" certificates: N/A
  • Affected certificate types: OV SSL
  • Incident heuristic: https://validovssl.tuntrust.tn/
  • Was issuance stopped in response to this incident, and why or why not?: No because this incident is not related to certificate issuance.
  • Analysis: N/A
  • Additional considerations: N/A

Timeline

Date Description
2025-09-10 11:09 UTC A maintenance operation triggered a failover, redirecting all DNS records to the DR site.
2025-09-11 17:39 UTC A Problem Report was received indicating that the website associated with the valid OV SSL test certificate was serving an expired certificate.
2025-09-11 19:00 UTC An acknowledgment was sent to the entity filing the Certificate Problem Report.
2025-09-12 13:26 UTC A preliminary report on the findings was sent to the entity filing the Certificate Problem Report.
2025-09-13 10:05 UTC A preliminary incident report was filed on Bugzilla.
2025-09-11 20:09 UTC DNS records were updated to point to the correct public IP address. Following this action, the domain immediately began serving the intended valid test certificate as expected.

Related Incidents

These are related incidents from other CAs.

Bug Date Description
Bug 1962809 2025-04-25 Valid Test Website Certificate is expired.
Bug 1904038 2024-06-21 Valid Test Website Certificate is expired
Bug 1726333 2021-08-18 Valid Test Website Certificate is expired.
Bug 1730291 2021-09-10 Valid Test Website Certificate is expired.

Root Cause Analysis

Contributing Factor #1: Insufficient monitoring

  • Description:
    Monitoring of the valid OV test certificates was focused on the internal network, verifying certificate expiration and system availability. External monitoring of the public-facing address was not in place to verify that the correct certificate was being served, which allowed the issue to go undetected.
  • Timeline:
    Since the deployment of the test certificates in 2019.
  • Detection:
    The issue was detected only after it was reported externally. Internal monitoring was in place to verify certificate validity and system availability, but it was limited to checks from within the internal network. This gap in monitoring allowed the issue to persist undetected.
  • Interaction with other factors:
    This gap in monitoring interacted with the outdated DNS configuration (Root Cause #3) and the fact that no external validation checks were performed after DNS failover (Root cause #2). As a result, the incorrect DNS entry serving the expired certificate went unnoticed.

Contributing Factor #2: Insufficient checks after DNS failover

  • Description:
    Following the DNS failover, verification was performed to ensure that the host was publicly accessible. However, the check did not include confirming that the correct certificate was being served.
  • Timeline:
    After DNS failover on September 10th 2025 at 11:09 UTC.
  • Detection:
    This contributing factor was detected during the post-incident investigation. The existing verification process focused solely on confirming that services were reachable following DNS failover. Because certificate validation was not part of the standard verification step, the expired certificate on the DR host went unnoticed. This limited scope of verification acted as a missed safeguard, allowing the issue to persist until externally reported.
  • Interaction with other factors:
    The limited scope of the failover verification, focused only on accessibility, combined with the lack of external monitoring (Root Cause #1), allowed the expired certificate on the DR host to remain undetected.

Contributing Factor #3: Inconsistency in the process of changing the IP address

  • Description:
    After the host in the DR site was set up, its IP address in the DNS records was not updated. This was initially intended as a temporary measure during the ACME issuance procedure with MPIC to avoid conflicts between the main and DR sites.

  • Timeline:
    May 22nd 2025

  • Detection:
    This factor was identified once the incident occurred and traffic was redirected to the DR site. The outdated DNS record had not interfered with normal operations as long as the main site remained active, which explains why the issue avoided detection prior to failover. The absence of external monitoring and the reliance on internal checks meant that the outdated configuration was not flagged, and it only became apparent when the DR host began serving traffic.

  • Interaction with other factors:
    The absence of external monitoring (Root Cause #1) and the limited scope of failover verification (Root Cause #2) did not prevent or detect this misconfiguration (Root Cause #3), which allowed the issue to persist until it was externally reported.

  • Root Cause Analysis methodology used:
    5 Whys:

    • Why was the expired certificate served? → DNS pointed to the wrong DR host.
    • Why was DNS pointing incorrectly? → It wasn’t updated after DR host setup.
    • Why wasn’t it updated? → It was left as a temporary measure during ACME issuance. (Root cause #3)
    • Why did no one catch this? → Monitoring was internal only. (Root cause #1)
    • Why did the failover check not catch it? → Verification didn’t include certificate checks. (Root cause #2)

Lessons Learned

  • What went well:
    The problem reporting process was carried out in accordance with temporal requirements of the Root Stores.
  • What didn’t go well:
    Had the issue not been detected by the entity filing the Problem Certificate Report, it could have remained unnoticed, and the valid test website might have continued serving the incorrect certificate until the end of the maintenance period.
  • Where we got lucky: N/A
  • Additional: N/A

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Configure the monitoring system to verify, via the external network, that the served certificates are valid and not expired. Detect Root Cause # 1 & What didn’t go well Alerts received in case of unavailability, certificate expiration, etc. 2025-09-30 Complete
Update the DNS failover verification procedure to include verification of test website certificates, ensuring that the correct certificates are being served. Prevent Root Cause # 2 Misconfiguration in DNS records is detected upon DNS failover 2025-10-06 Complete
Configure the DR site host to automatically obtain a certificate through ACME when it detects that it is the publicly accessible host. Mitigate Root Cause # 3 DR host configuration updated to enable ACME-based issuance. 2025-10-06 Complete

Appendix

N/A

Report Closure Summary

  • Incident description:
    On September 10th, 2025, during a maintenance operation, a DNS failover redirected traffic to the DR site. Because its DNS record still pointed to an outdated IP address, the domain validovssl.tuntrust.tn began serving an expired SSL certificate from the former host instead of the valid test certificate.
    The issue was externally reported on September 11th, 2025, at 17:39 UTC. An internal investigation was immediately launched, and the DNS records were corrected the same day at 20:09 UTC to reflect the updated IP address. The issue was limited solely to the valid test website and did not affect any other publicly accessible components.

  • Incident Root Cause(s):
    The incident resulted from a combination of process and monitoring deficiencies:

  1. Monitoring was limited to internal checks and did not detect the issue externally.
  2. Post-failover verification focused only on service accessibility and did not include certificate validity.
  3. In the context of issuing test website certificates through ACME, a new host was deployed on May 22nd, 2025, with a new public IP address. While the DNS record for the main site was updated to reflect the new IP address, the record for the Disaster Recovery (DR) site was not. This misconfiguration remained unnoticed since normal operations were conducted through the main site.
  • Remediation description:
    To address the identified root causes, three action items were implemented.
  1. External monitoring was configured to continuously verify certificate validity and detect any expirations. (Completed September 30th 2025)
  2. The DNS failover verification procedure was updated to ensure that, following any failover, the correct certificates are being served. (Completed October 6th 2025)
  3. The Disaster Recovery host was configured to automatically obtain a valid certificate through ACME whenever it becomes publicly accessible. (Completed October 6th 2025)
  • Commitment summary:
    In addition to the completed remediation actions, TunTrust remains committed to continuously enhancing its operational and monitoring processes. Our timely response to the problem report and the prompt implementation of corrective measures, demonstrate this commitment. Furthermore, ongoing staff training on configuration management and incident response will be maintained to ensure continued awareness and continuous process improvement.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Flags: needinfo?(incident-reporting)

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2025-10-20.

Whiteboard: [ca-compliance] [policy-failure] → [close on 2025-10-20] [ca-compliance] [policy-failure]
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Flags: needinfo?(incident-reporting)
Resolution: --- → FIXED
Whiteboard: [close on 2025-10-20] [ca-compliance] [policy-failure] → [ca-compliance] [policy-failure]
You need to log in before you can comment on or make changes to this bug.