2011713 - TrustAsia: ACME Authorization Reuse Non-Compliance

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[TrustAsia]

Attachment: dv-misissuance-certs.txt

Preliminary Incident Report

Summary

• Incident description:

On 2026-01-21, TrustAsia received a report indicating that the LiteSSL ACME service had a vulnerability related to the reuse of domain validation data. After our investigation, the affected scope was the certificates using ACME protocol and issued after 2025-12-29, where Authorization data was reused across different ACME accounts. In total, 143 certificates were impacted.

After confirming the issue, we immediately suspended the ACME issuance service. At the current stage, all the affected certificates have been revoked. The vulnerability has been fixed, and the ACME issuance service has been restored.

Timeline (all times are UTC+8):

• 2026-01-21
  • 14:55 – Internal compliance team received a community report
    (https://v2ex.com/t/1187331) indicating a domain validation data reuse issue in TrustAsia’s LiteSSL ACME service.
  • 15:10 – Preliminarily confirmed the issue and suspended the ACME issuance service.
  • 15:30 – Confirmed the issue and the impact scope involving the certificates issued using ACME protocol; investigation of affected certificates and system remediation began.
  • 15:33 – Initiated revocation of the two certificates referenced in the community report.
  • 21:00 – Fix completed and successfully validated in the test environment.
  • 21:21 – Identified all the affected certificates and initiated batch revocation.
  • 21:30 – Completed revocation of the 140 affected and still-valid certificates (the remaining 3 affected certificates had already been previously revoked).
  • 21:41 – Deployed the fixed code to the production environment.
  • 22:35 – Reset all ACME Authorizations in the production environment with status VALID to REVOKED and requested the clients to perform re-validation
  • 22:50 – Successfully completed the internal validation of the production environment.
  • 23:00 – External ACME issuance service restored.

We will publish the final incident report as soon as possible.

• Relevant policies:

TLS BR Version 2.2.2
Section 3.2.2.4:
The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate as follows

• Source of incident disclosure:

Third-party reporters

Comment 1

[Malcolm D]

the affected scope was the certificates using ACME protocol and issued after 2025-12-29,

Shouldn't your timeline reflect this date as the start of non-compliance?

Comment 2

[TrustAsia]

(In reply to Malcolm D from comment #1)

the affected scope was the certificates using ACME protocol and issued after 2025-12-29,

Shouldn't your timeline reflect this date as the start of non-compliance?

Thank you for your feedback. The timeline provided in this Preliminary Incident Report primarily focuses on incident response and remediation. A complete timeline (including the Non-compliance start date) will be detailed in the Full Incident Report.

Comment 3

[Seo Suchan]

from looking at comments on that thread (73th comment there, if google translator didn't screw up), it looks like inside database auth/certs are connected by EAB, not acme account. and those EAB are not assigned per enduser: is that right?

Comment 4

[TrustAsia]

(In reply to Seo Suchan from comment #3)

from looking at comments on that thread (73th comment there, if google translator didn't screw up), it looks like inside database auth/certs are connected by EAB, not acme account. and those EAB are not assigned per enduser: is that right?

Thank you for raising this point.

1. In our database, Authorizations and Certificates are associated via ACME Accounts. There is a one-to-one mapping between ACME Accounts and EABs.
2. EABs are assigned to end-users.
   We will provide further details in the upcoming Full Incident Report.

Comment 5

[TrustAsia]

Investigation of the incident in progress and a full incident report will follow.

Comment 6

[TrustAsia]

Attachment: Bug2011713_Appendix.csv

Comment 7

[TrustAsia]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A007539

• Incident description:
  On 2026-01-21, TrustAsia received a report from a community security researcher indicating a domain validation record reuse vulnerability in the LiteSSL ACME service (https://v2ex.com/t/1187331). After the compliance team investigated and confirmed the issue, we promptly suspended the ACME service and fixed the vulnerability on the same day by implementing mandatory ACME account isolation verification in the code logic. Additionally, we revoked all 143 affected certificates and reset the status of all existing ACME Authorizations in the production environment, forcing clients to perform re-validation. The ACME service was restored after the fix.

  • The affected scope includes the DV certificates issued using ACME between 2025-12-29 and 2026-01-21 that reused domain validation records across different ACME accounts. A total of 143 certificates were affected.
  • The first affected certificate was issued on 2026-01-03 02:00 (UTC+8).
  • The last affected certificate was issued on 2026-01-21 15:01 (UTC+8).

• Timeline summary:

  • Non-compliance start date: 2025-12-29 20:33 UTC+8
  • Non-compliance identified date: 2026-01-21 15:10 UTC+8
  • Non-compliance end date: 2026-01-21 23:00 UTC+8

• Relevant policies:
  TLS BR Version 2.2.1, Section 3.2.2.4:
  “The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate as follows”

• Source of incident disclosure: Third Party Reported

Impact

• Total number of certificates: 143
• Total number of "remaining valid" certificates: 0
• Affected certificate types: This incident affects DV certificates issued via ACME.
• Incident heuristic: We analyzed all certificates issued via ACME between 2025-12-29 and 2026-01-21, and inspected their associated domain validation records. If the ACME Account ID belonging to the certificate did not match the ACME Account ID in the domain validation record, the certificate was determined to be affected. Using this logic, we identified 143 affected certificates. A complete list of affected certificates is provided in the Appendix.
• Was issuance stopped in response to this incident, and why or why not?: Yes. Upon confirming the issue, we immediately suspended the LiteSSL ACME issuance service to prevent further mis-issuance until the patch was deployed and verified.
• Analysis: N/A
• Additional considerations: This incident only affected DV certificates that were requested via ACME and reused domain validation records across different ACME accounts.

Timeline

All times are UTC+8.

2025-11-13

• LiteSSL ACME service made available to the public.

2025-12-18

• 15:24 Engineering team submitted the code containing the issue to the test branch.

2025-12-19

• 09:59 Testing began on the version containing the problematic code.

2025-12-29

• 19:58 Testing of the version with problematic code completed and merged into the main branch.
• 20:33 Version with problematic code deployed to the production environment.

2026-01-03

• 02:00 System issued the first affected certificate (https://crt.sh/?sha256=9BD26ED01ACF9F9A73AE5FC2B099CF680215DEE6FED77158509CBCC59156C958).

2026-01-21

• 14:55 Internal compliance team received a report (https://v2ex.com/t/1187331) stating that the LiteSSL ACME service provided by TrustAsia had a vulnerability of domain validation record reuse across ACME accounts.
• 15:01 Internal compliance team began verifying the existence of the issue.
• 15:01 System issued the last affected certificate (https://crt.sh/?sha256=75FF650BBB6A8532949D01672B69943CC0B4A106E6BD725A4A2DFDDD649724CE).
• 15:10 Initial confirmation of the issue; initiated the process to suspend the ACME service, and confirmed the service was fully stopped 30 minutes later.
• 15:30 Confirmed that the issue only affected DV certificates issued via the ACME protocol, and began identifying affected certificates and fixing the system.
• 15:33 Initiated revocation of the two certificates referenced in the report.
• 15:40 Confirmed the ACME service was completely stopped.
• 21:00 Completed the fix and verified it in the testing environment.
• 21:21 Identification of affected certificates completed; initiated batch revocation.
• 21:30 Completed revocation of affected certificates (143 in total: 140 were valid, 3 had been revoked previously).
• 21:41 Deployed the fixed program to the production environment.
• 22:35 Reset all ACME Authorizations in the production environment with status VALID to REVOKED, and requiring clients to perform re-validation.
• 22:50 Internal verification of the production environment passed.
• 23:00 Restored ACME service to the public.

2026-01-22

• 01:12 Preliminary Incident Report submitted.

Related Incidents

Bug	Date	Description
1943604	2025-01-23	Validation data reuse caused by a domain validation logic error for non-ACME certificates (similar reuse logic defect, while the present case involves cross-account authentication isolation).
1978163	2025-07-15	Reuse of expired validation data, rather than data validation reuse caused by isolation failure.
1961406	2025-04-18	Implementation defect in DCV logic resulting in the validation of unintended domains.
1876593	2024-01-25	Highlighted that specific logic paths (or manual intervention) might bypass expected validation checks in automated systems.

Root Cause Analysis

Contributing Factor #1: Account isolation failure in validation record retrieval logic

• Description:
  The root cause was the engineering team's failure to implement account isolation constraints in the ACME validation record retrieval logic. The ACME Account ID was not made a mandatory input parameter, causing the program to incorrectly return domain validation records from other ACME accounts when searching for reusable records, leading to cross-account reuse.

  Specifically:

  • In system versions prior to 2025-12-29, the domain validation logic for ACME was: if a valid and unexpired validation record for the submitted domain existed within the requesting ACME account, the system would reuse the record; otherwise, a new validation record would be created. The system operated well before this.
  • In the version released on 2025-12-29, the intended ACME domain validation logic was: if a valid and unexpired validation record for the submitted domain, or a DNS-01 validation record for its upper-level domain, existed within the requesting ACME account, the system would reuse the record to improve validation efficiency. During the implementation, the engineering team encapsulated the reuse validation record query logic into a common function within the core validation service. However, when the ACME processing logic called this common function to query the completed domain validation information, it failed to pass the ACME Account ID as a mandatory filtering condition, and the common function did not enforce this parameter (the engineering team was unaware that this change would affect ACME). This led to a logic defect: validation records from ACME Account A were erroneously returned and reused for ACME Account B.

• Timeline: This logic was included in the problematic code branch submitted on 2025-12-18 and introduced to production with the release on 2025-12-29 20:33 (UTC+8).

• Detection: Reported by an external security researcher.

• Interaction with other factors: This is the direct technical cause. If Contributing Factor #2 or #3 were present, this error could have been intercepted before issuance.

• Root Cause Analysis methodology used: 5 Whys.

Contributing Factor #2: Insufficient Testing Scenarios Coverage

• Description:
  Although the QA team performed tests for requesting domains across different ACME accounts, there was a flaw in the design of the test data: the QA engineers used domains controlled by the same individual to simulate the cross-ACME account applications. In this "single-controller" scenario, when the system incorrectly reused the validation records of ACME Account A to issue a certificate to ACME Account B, the testers failed to identify the vulnerability of validation record reuse due to an expectation bias arising from their ownership of the domain. By reviewing the test case library, it is discovered that adversarial test scenarios were missing from the test suite. Specifically, the scenario where ACME Account A requests a certificate for a domain that belongs to ACME Account B and without having control over the DNS. If such a scenario had been included, testers would have immediately identified the vulnerability by receiving a certificate without authorized DNS access.
• Timeline: Existed throughout the testing cycle prior to the 2025-12-29 release.
• Detection: Discovered during a review of the test case library after the incident occurring.
• Interaction with other factors: Had the test scenarios included adversarial tests, this logic defect would have been intercepted before going live.
• Root Cause Analysis methodology used: 5 Whys.

Contributing Factor #3: Incomplete Defense-in-Depth

• Description:
  During the Finalize Order stage, the system performed consistency checks on domain validation status, validity period, and the subject account. However, the ACME Account ID was not included in the final consistency check list.
• Timeline: This design oversight existed since the system design phase.
• Detection: Discovered during post-incident analysis.
• Interaction with other factors: Even if the front-end query logic was flawed, a strict consistency check of the ACME Account ID during the Finalize stage would have acted as a backstop to block the mis-issuance.
• Root Cause Analysis methodology used: 5 Whys.

Lessons Learned

• What went well:

  • Affected certificates were promptly revoked upon confirmation of the issue.
  • The batch revocation proceeded smoothly by leveraging the established mass revocation plan.

• What didn’t go well:

  • Code review and testing processes failed to identify the lack of cross-ACME account isolation in core business logic.
  • For changes to ACME authentication logic, there was a lack of sufficient boundary condition testing and adversarial testing scenarios were not identified.
  • The pre-issuance secondary check logic primarily focused on order and authorization matching, while overlooked the account-level association between the ACME order and the validation records. This gap resulted in the failure to identify and block the mis-issuance.

• Where we got lucky:

  • Researchers contacted us promptly after the vulnerability disclosure, allowing for a rapid response.

• Additional: N/A

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Revoke affected certificates	Mitigate	Root Cause #1	Verify that the status of affected certificates is "Revoked".	2026-01-21	Complete
ACME authorization module code fix	Mitigate	Root Cause #1	Fixed code is reviewed and deployed; verify the system strictly enforces account isolation. For requests from different accounts for the same domain, the system is able to identify and require the applicant to perform new validation rather than reusing the existing record.	2026-01-21	Complete
Reset ACME Authorization status	Prevent	Root Cause #1	Confirm all previous "Valid" Authorizations have been reset to "Revoked."	2026-01-21	Complete
Enhance test cases and add adversarial test scenarios for cross-ACME account reuse of domain validation records	Prevent	Root Cause #2	Use ACME Account A to request a certificate for a domain that belongs to ACME Account B and for which Account A has no DNS control; the expected result must be that ACME Account A creates a new Authorization with a status of Pending.	2026-01-21	Complete
Strengthen pre-issuance consistency check logic	Prevent	Root Cause #3	In the pre-issuance check logic, add consistency check to verify ACME Account ID consistency between the Order and Validation record. The system must refuse issuance if mismatched.	2026-03-05	Ongoing

Appendix

Refer to the attachment(Bug2011713_Appendix.csv).

Comment 8

[TrustAsia]

We are working on the Action Item #5 as planned. We kindly request setting the "Next update" date to 2026-03-05.

Comment 9

[TrustAsia]

We have completed all action items associated with this bug and will be posting our Report Closure Summary soon.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Revoke affected certificates	Mitigate	Root Cause #1	Verify that the status of affected certificates is "Revoked".	2026-01-21	Complete
ACME authorization module code fix	Mitigate	Root Cause #1	Fixed code is reviewed and deployed; verify the system strictly enforces account isolation. For requests from different accounts for the same domain, the system is able to identify and require the applicant to perform new validation rather than reusing the existing record.	2026-01-21	Complete
Reset ACME Authorization status	Prevent	Root Cause #1	Confirm all previous "Valid" Authorizations have been reset to "Revoked."	2026-01-21	Complete
Enhance test cases and add adversarial test scenarios for cross-ACME account reuse of domain validation records	Prevent	Root Cause #2	Use ACME Account A to request a certificate for a domain that belongs to ACME Account B and for which Account A has no DNS control; the expected result must be that ACME Account A creates a new Authorization with a status of Pending.	2026-01-21	Complete
Strengthen pre-issuance consistency check logic	Prevent	Root Cause #3	In the pre-issuance check logic, add consistency check to verify ACME Account ID consistency between the Order and Validation record. The system must refuse issuance if mismatched.	2026-03-05	Complete

Comment 10

[TrustAsia]

Report Closure Summary

• Incident description: On 2026-01-21, a vulnerability was discovered in TrustAsia's LiteSSL ACME service where domain validation records were incorrectly reused across different ACME accounts. This resulted in the misissuance of 143 DV certificates. The service was promptly suspended, and the issue was fixed the same day.
• Incident Root Cause(s): The incident was caused by a combination of three factors: (1) an account isolation failure in the validation record retrieval logic where the ACME Account ID was not enforced as a mandatory filter; (2) insufficient QA test scenario coverage that lacked adversarial cross-account testing; and (3) incomplete defense-in-depth, as the ACME Account ID was missing from the final pre-issuance consistency checks.
• Remediation description: We immediately revoked all 143 affected certificates and reset all existing "Valid" ACME Authorizations to "Revoked" in the production environment. We deployed a code fix to strictly enforce account isolation in the authorization module, enhanced our QA test cases with adversarial scenarios, and implemented a pre-issuance consistency check to verify the ACME Account ID between the Order and Validation records.
• Commitment summary: TrustAsia will continuously improve our defense-in-depth architecture. We will continue to enhance our QA testing methodologies, including the integration of adversarial test cases, and maintain ongoing reviews of account isolation logic across our validation services.

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

Comment 11

[incident-reporting]

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

Otherwise, it will be closed on approximately 2026-03-17.