TrustAsiaは、同社のLiteSSL ACMEサービスにおける重大な脆弱性の発見を受け、143件のSSL/TLS証明書を失効しました。
2026年1月21日に開示されたこの欠陥により、異なるACMEアカウント間でドメイン検証データを再利用できてしまい、他のユーザーによって検証されたドメインについて、権限のない証明書発行が可能になっていました。
この脆弱性は、証明書発行ごとに一意のドメイン検証を義務付けるCA/Browser Forum Baseline Requirements（TLS BR Version 2.2.2、セクション3.2.2.4）に違反していました。
根本原因は、LiteSSLのACMEサービスにおけるAuthorizationオブジェクトの取り扱いに関するロジックエラーにありました。
Mozillaが報告したとおり、同サービスは、証明書署名要求（CSR）が初回の検証を実施したのと同一のACMEアカウントから送信されたものかどうかを検証できていませんでした。
この不備により、攻撃者は発行プロセスを乗っ取り、DNS-01チャレンジを再実行することなく、任意のドメインに対するワイルドカード証明書を取得できました。
さらに研究者は、LiteSSLがDNS-01検証チャレンジに対して過度に長いキャッシュを維持しており、悪用可能な期間を大幅に拡大していたことを発見しました。
| 項目 | 値 |
|---|---|
| 認証局 | TrustAsia |
| 影響を受けたサービス | LiteSSL ACME |
| 脆弱性の種類 | ドメイン検証の再利用／認可バイパス |
| 影響を受けた証明書 | 合計143件（140件を失効、3件は既に失効済み） |
| 発行期間 | 2025年12月29日以降 |
| プロトコル | ACME（DNS-01チャレンジ） |
影響を受けた143件の証明書はすべて、2025年12月29日以降にACMEプロトコル経由で発行されていました。脆弱性を確認後、TrustAsiaは直ちにACME発行サービスを停止し、包括的なシステム修復を開始しました。
数時間以内に、同社はコード修正を完了し、本番環境へパッチを展開し、なお有効だった140件の証明書を失効しました。3件は既に失効済みでした。
TrustAsiaは、本番環境におけるすべてのACME AuthorizationをVALIDからREVOKEDへリセットし、証明書発行を再開する前にクライアントが再検証を実施するよう強制しました。
本件はCA/Browser Forum要件への不適合に該当します。TrustAsiaは、根本原因分析および不適合開始日の正確な日時を含む包括的な完全インシデントレポートを公開することを約束しています。
インシデントのタイムラインと技術データ
| 時刻（UTC+8） | イベント | 詳細 |
|---|---|---|
| 14:55 | 報告受領 | V2EX経由のコミュニティ報告により、ドメイン検証の再利用問題が指摘された |
| 15:10 | 一次確認 | 問題を確認し、ACME発行サービスを直ちに停止 |
| 15:30 | 範囲調査 | 影響範囲を特定し、証明書の調査を開始 |
| 15:33 | 初回失効 | コミュニティ報告に含まれていた2件の証明書を失効 |
| 21:00 | コード修正完了 | テスト環境で修正が正常に検証された |
| 21:21 | 全範囲の特定 | 影響を受けた143件の証明書をすべて特定し、一括失効を開始 |
| 21:30 | 失効完了 | 有効な140件の証明書を失効（3件は既に失効済み） |
| 21:41 | 本番展開 | パッチ適用済みコードを本番環境へ展開 |
| 22:35 | 認可のリセット | すべてのACME AuthorizationをVALIDからREVOKEDへリセットし、再検証を要求 |
| 22:50 | 内部検証 | 本番環境の検証が正常に完了 |
| 23:00 | サービス復旧 | 外部向けACME発行サービスを完全に復旧 |
TrustAsiaは、発見から8時間以内に脆弱性を封じ込め、サービスを完全に修復することで、迅速なインシデント対応を示しました。
2025年12月29日から2026年1月21日の間にLiteSSL ACME経由で証明書を発行した組織は、証明書ステータスを確認し、再発行が必要となる可能性に備えるべきです。
本件は、ACME実装における適切なアカウントコンテキスト検証の重要性と、証明書検証ワークフローにおいてユーザードメイン間の厳格な分離が必要であることを浮き彫りにしています。
