TLS・証明書・認証局（CA）

TLSは通信経路を保護する仕組み

TLSはTransport Layer Securityの略で、通信する相手の認証や、通信内容の暗号化・改ざん検出を行う仕組みです。HTTPSではHTTPのデータをTLSなどの保護された通信でやり取りします。

一般的なWebサイトでは、ブラウザがサーバーの証明書などを確認して接続相手を検証します。その後、合意した鍵でページや入力内容を保護します。証明書だけを置けば、サーバー側のすべての保存データまで暗号化されるわけではありません。

サーバー証明書には公開鍵、対象となるドメイン名、有効期間、発行者などが含まれ、発行者の署名が付きます。秘密鍵は証明書に含めて公開しません。サーバーは対応する秘密鍵を保持し、接続時の認証に使います。

ブラウザは接続先のホスト名が証明書の対象に含まれるか、有効期間内か、信頼できる署名のつながりがあるかなどを検証します。証明書があっても、別のホスト用や期限切れなら通常の検証を通りません。

CAはCertificate Authorityの略で、証明書を発行する認証局です。ブラウザやOSは信頼するルート認証局の情報を持ち、サーバー証明書から中間認証局を経て、信頼するルートへつながる署名を確認します。

ドメイン認証の証明書では、発行前にそのドメインを管理できるかなどを確認します。Let’s Encryptでは指定されたDNS情報やHTTP上の値などで管理を証明できます。これによって、サイトの全ページが無害か、事業者が誠実かまで審査されるわけではありません。

証明書を使う通常のTLS 1.3接続の説明では、最初にブラウザとサーバーが対応方式や鍵共有用の情報を交換します。サーバーは証明書と秘密鍵による証明を示し、ブラウザは接続先の正当性を検証します。

両者は共有した秘密から通信の保護に使う鍵を導き、その鍵でHTTPデータを暗号化し改ざんを検出します。証明書の公開鍵で全ページの本文を直接暗号化するという流れではありません。再接続などでは手順が変わるため、ここでは初回接続の代表例を扱います。

証明書による相手の確認と、共通鍵による本文の保護には異なる役割があります。

証明書の期限が切れると、通常はブラウザが信頼できる接続として受け付けなくなります。更新処理の自動化に加え、失敗の監視、実際に配信されている証明書の確認が必要です。

秘密鍵の漏えいなどでは、期限を待たず証明書の失効を申請し、新しい鍵と証明書へ切り替えます。失効情報の確認方式や反映は環境に依存するため、申請した瞬間に全端末が同じ動作になるとは限りません。

確認問題：配信サービスでHTTPSを受けたら、その後の自社サーバーへの転送も必ず暗号化されるでしょうか。答えは限りません。ブラウザから配信サービス、配信サービスから自社サーバーを別々に確認します。

証明書エラーを無視する設定を恒久対策にせず、ホスト名、時計、期限、中間証明書などの原因を調べます。TLSは通信経路を守るので、APIの権限不備やXSSはアプリ側で対策します。

未確認事項・限界

通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。