この記事について
この記事はTLS 1.3とサービス名検証の現行RFCを確認し、HTTPSでサーバー証明書が果たす役割を整理しています。検証ステータス：📘 公式仕様確認済み・公開サイト観察は未固定
TLS実装やブラウザ表示は環境で異なるため、特定製品の画面ではなくプロトコル上の役割を中心に説明します。
HTTPSのサーバー証明書は、「通信を暗号化するファイル」そのものではありません。TLS接続の中で、接続先の名前と公開鍵を結び付け、信頼できる認証局へつながる証明書チェーンを使って、相手サーバーのidentityを検証する材料になります。
TLSではその検証と鍵合意を組み合わせ、通信に使うsession keyを確立します。
TLS 1.3の流れを大きく見る
sequenceDiagram
participant C as Client
participant S as HTTPS Server
C->>S: ClientHello
S-->>C: ServerHello
S-->>C: Certificate
S-->>C: CertificateVerify
S-->>C: Finished
C->>C: 証明書・名前・署名等を検証
C-->>S: Finished
Note over C,S: 暗号化されたapplication data
実際のTLS 1.3 handshakeには条件による違いがありますが、「証明書を受け取る → identityと証明書チェーンを検証 → serverが秘密鍵を持つことを確認 → handshakeを完了」という関係を押さえると全体を理解しやすくなります。
証明書で何を確認するのか
代表的な観点は次です。
接続しようとしているservice名と証明書のidentifierが一致するか
証明書の有効期間などが妥当か
信頼できる認証局へcertificate pathを構築・検証できるか
serverが証明書の公開鍵に対応する秘密鍵を持つことをTLS handshakeで示せるか
flowchart TB
A[Server certificate] --> B[名前の一致]
A --> C[有効性]
A --> D[Certificate chain]
D --> E[Trust storeの信頼 anchor]
A --> F[CertificateVerify]
F --> G[対応する秘密鍵を持つことの証明]
URLのホスト名と何を比べるのか
現在のIETF RFC 9525では、service identityのDNS名はsubjectAltNameのdNSNameなど、適切なidentifierと照合する考え方が示されています。
昔の説明でよく出てくるCommon Nameだけを見ればよい、という理解は現在のservice identity検証としては適切ではありません。
名前が一致しなければ、別の正規な証明書を提示されても「アクセスしようとしたserviceの証明書」とは判断できません。
証明書チェーンとは
server certificateだけを単独で信じるのではなく、issuerをたどり、client側のtrust storeにあるtrust anchorまで検証します。
flowchart TB
A[Server / Leaf certificate] --> B[Intermediate CA]
B --> C[Root CA]
C --> D[Client trust store]
実際のpath buildingやvalidationはより複雑ですが、初心者が最初に持つ図としてはこの関係が分かりやすいです。
証明書があれば通信内容はその公開鍵で全部暗号化される？
TLS 1.3では、certificateの公開鍵を使ってWebページ本文すべてを直接暗号化する、という単純な構造ではありません。
handshakeで鍵合意を行い、そこから得た秘密を使ってapplication dataを保護します。証明書はserver authenticationに重要ですが、session dataの暗号化方式と同一視しない方が正確です。
curlで証明書エラーを見るとき
curlはTLS certificate verificationを行います。名前が合わない、信頼チェーンを構築できない、といった場合はverify errorになります。
通常利用で -k / –insecure を「エラーを消す方法」として常用するのは避けます。
flowchart TB
A[curl HTTPS] --> B{certificate verification}
B -->|OK| C[HTTPS requestを継続]
B -->|NG| D[verify error]
D --> E[名前・期限・chain・CA設定を調査]
E -. 安易に検証無効化しない .-> D
検証エラーは邪魔な機能ではなく、接続先のidentityを確認できないことを知らせる安全機構です。
DNSが正しければ証明書も正しい？
DNSで正しいIPへ到達できることと、TLSで接続先のidentityを認証できることは別の層です。
flowchart LR
A[DNS] --> B[接続先IPを得る]
B --> C[TCP接続]
C --> D[TLS handshake]
D --> E[certificateでservice identityを検証]
E --> F[HTTP]
層を分けて見ると、DNS障害、TCP疎通、TLS certificate error、HTTP errorを混同しにくくなります。
まとめ
サーバー証明書は接続先identityと公開鍵を結び付ける
clientは名前、certificate path、有効性などを確認する
TLS 1.3ではCertificateVerifyなどを通じてserverの秘密鍵所持も確認する
証明書の公開鍵でWeb本文をそのまま全部暗号化するわけではない
DNS、TCP、TLS、HTTPは別レイヤーとして切り分ける
certificate verificationを安易に無効化しない
公式情報・一次情報
RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
https://www.rfc-editor.org/rfc/rfc8446.html
RFC 9525 — Service Identity in TLS
https://www.rfc-editor.org/rfc/rfc9525.html
curl — TLS certificate verification
https://curl.se/docs/sslcerts.html
コメント