事象
・古いPCからWindowsアプリを使ってAWSにSSL/TLSリクエストを送信すると証明書エラーとなる。
System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: 接続が切断されました: SSL/TLS のセキュリティで保護されているチャネルに対する信頼関係を確立できませんでした。 ---> System.Security.Authentication.AuthenticationException: 検証プロシージャによると、リモート証明書は無効です。
・古いPCからWebブラウザを使ってAWSにSSL/TLSリクエストを送信すると問題なし。
・新しいPCからWindowsアプリ、Webブラウザを使ってAWSにSSL/TLSリクエストを送信すると問題なし。
図にするとこんな感じ。
解決策
WindowsUpdateする。
もしくは、
Amazon Trust Servicesに公開されているルート証明書をクライアントPCにインストールする。
前提
TLS通信を行うには、サーバーのSSL証明書をクライアントに送付し、クライアント側でその証明書の発行元を信頼する必要がある（他にも色々あるが割愛）。
WindowsOSには、最初から「信頼されたルート証明機関」というものがあり、信頼する発行元のリストが登録されている。
リストに無い場合でも、WindowsUpdate等から自動で最新のリストを更新するようになっている（らしい）。
それとは別に、Webブラウザには最初から信頼リストを別で保持している。
AWSサービスの多くはACMから発行されたSSL証明書を利用している。
クライアントでACMから発行されたSSL証明書を信頼するには、信頼リストに以下のいずれかが登録されている必要がある。
- ①Amazon Root CA 1
- ②Amazon Root CA 2
- ③Amazon Root CA 3
- ④Amazon Root CA 4
- ⑤Starfield Services Root Certificate Authority - G2
- ⑥Starfield Class 2 Certification Authority （※ただし2024年7月以前に発行された証明書に限る）
原因
上記の ⑥Starfield Class 2 Certification Authority がポイントで、AWSの通知にて、2024年8月以降にACMで発行された証明書のルート証明機関からStarfield Class 2を除外するという通知が出ている。
今回のケースでは、どちらのPCもブラウザは比較的新しいものを使っており、ブラウザの信頼リストに①～⑤が登録されていたため、WebブラウザからのTLS通信は問題無かった。
ただし、WindowsアプリからのTLS通信の場合、OSの信頼リストのみを参照する。
新しいPCではOSの信頼リストに⑤と⑥が登録されていたため、TLS通信は問題なかった。
古いPCではOSの信頼リストに⑥のみ登録されていたため、2024年8月以降に発行された証明書を利用したサーバーに対するSSL/TLSリクエストに失敗していたと思われる。
多くのACMを利用した証明書の更新はAWSが自動更新してくれるため、新しい証明書に自動更新されたタイミングで急に接続できなくなることも起こり得るかもしれない。（ただし古くて更新がされていないPCからのアクセスに限る）