Android 17でカスタムCA証明書が使えなくなる — Certificate Transparencyの強制適用と、HTTP Toolkitが実装した回避策

9月23日、HTTP Toolkitが「Android 17 enables certificate transparency, and breaks custom CAs」と題した記事を公開した。Android 17で証明書の透明性（Certificate Transparency、以下CT）がデフォルト強制となり、カスタムCA証明書を使ったHTTPS通信のインターセプトが事実上できなくなるという、開発者・セキュリティ研究者への直接的な影響を詳述した内容だ。

アプリのHTTPS通信をデバッグ・解析するには、カスタムCA証明書を端末に信頼させてMitMプロキシとして動作させる手法が長らく使われてきた。Android 17はこの手法の根本を崩す変更であり、Play Storeへの掲載継続に必要なAPIレベル37の対応期限（2027年8月）と合わせると、約1年以内にほぼ全アプリに影響が及ぶ。HTTP Toolkitの著者はこの問題を実装レベルで解決しており、その手法は開発者・セキュリティ研究者双方にとって参考になる。

カスタムCAが「使えなくなる」とはどういうことか

Android 17では、APIレベル37をターゲットにしたアプリがAndroid 17端末で動作する場合、システムストアに登録されたCA証明書であっても、CTに対応していなければ信頼されない。カスタムCAが発行した証明書はSCT（Signed Certificate Timestamp）を持てないため拒否され、以下のようなエラーが発生する。

NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
SSLPeerUnverifiedException: Certificate transparency failed
Certificate chain does not conform to required transparency policy: NOT_ENOUGH_SCTS
SSLHandshakeException: Certificate transparency failed

APIレベル37の対応はPlay Store掲載継続のために2027年8月までに必須となるため、この影響はほぼ全アプリに広がる見込みだ。

証明書の透明性（CT）とは何か

CTは、信頼されたCAが不正に証明書を発行した際に検知できるよう設計された公開インフラだ。2011年にオランダのCA「DigiNotar」が侵害され不正証明書が大量発行された事件が直接の契機となり、Googleが主導して整備した。

仕組みの概要は以下のとおり。

CAが証明書を発行する際、公開CTログサービスに証明書を提出する
ログサービスはSCT（Signed Certificate Timestamp）を返す
SCTはサーバー証明書に埋め込まれ、クライアントが接続時に検証する
信頼されたログ由来のSCTがあれば「公開記録済み」と判断される

問題は、自分で生成したカスタムCA証明書はどの公開CTログにも登録されておらず、一般ユーザー・開発者が登録できる仕組みも存在しない点だ。結果としてカスタムCAの証明書はSCTを持てず、CTを要求するクライアントから拒否される。

Androidによる制限強化の歴史

Android 17の変更は唐突ではなく、Googleが段階的に進めてきた制限強化の延長線上にある。

Android 7（2016年）：ユーザーストアのCA証明書をアプリがデフォルトで信頼しなくなった
Android 11（2020年）：ユーザーへのCA証明書インストールを促進する手段が封じられた
Android 14（2023年）：システム証明書ストアがAPEXモジュールに移動し、rootアクセスによる書き換えも複雑化

Chromeも独自のトラストストアに移行しており、CT強制はChrome 99（2022年）でブラウザ向けにすでに適用済みだ。Android 17はこれをアプリ全体に拡大する位置づけとなる。

HTTP Toolkitが実装した回避策：プライベートCTログを自前で立てる

記事の著者（HTTP Toolkit開発者）はこの問題に対し、自前のCTログプロバイダーを構築し、端末上で信頼させるという解決策を実装した。

CTの仕様では、ログが実際に証明書を公開したかどうかをクライアントがリアルタイムで検証するInclusion Proof機能は実用上ほとんど利用されておらず、独立した監査機関による事後確認で担保されている。この構造上の特性を利用し、実際には証明書を外部に公開しないプライベートCTログを立て、そこからSCTを発行してカスタムCA証明書に埋め込む手法だ。

処理の流れは以下のとおり。

CAの証明書からCTログオペレーターのIDとキーペアを導出する
証明書生成時にSCTを発行してその証明書に埋め込む
デバイスセットアップ時（HTTP Toolkitのインターセプトフロー内）にカスタムCTログをシステムに信頼させる

実装の詳細は以下のリポジトリで公開されている。

問題の本質

著者は、この変更がAndroidによる意図的なインターセプト妨害ではないと見ている。CTはあくまで証明書の不正発行対策として設計されたものだが、セキュリティ研究・HTTPSデバッグ・リバースエンジニアリングといったユースケースへの配慮なしにCTが導入された結果、正当な用途を持つ開発者・研究者が影響を受ける形になっている、というのが著者の見立てだ。

AdGuardのようなモバイル広告フィルタリングツール、プライバシー研究者、そして自分のアプリをデバッグしたい開発者など、影響を受ける対象は広い。HTTP ToolkitのようなプライベートCTログによる対処が現状では最も現実的な回避策であり、実装は全てオープンソースで公開されている。

詳細はAndroid 17 enables certificate transparency, and breaks custom CAsを参照していただきたい。