コンテンツにスキップ
補助ドキュメント
02 X509 and Ca

X.509証明書とCA（認証局）の基礎

このドキュメントでは、TLS通信の根幹をなす「X.509」フォーマットと「CA（認証局）」の役割、およびパブリックなインターネットでの証明書の仕組みについてまとめます。

1. X.509 とは

X.509（エックス・ゴー・マル・キュウ）は、暗号化通信（TLS/SSLなど）において「通信相手が本物であることを証明するためのデジタル証明書」の世界標準規格です。

X.509証明書は、例えるなら**「インターネット上の運転免許証やパスポート」**です。「サーバーの公開鍵」と「そのサーバーの身元情報」を紐づけ、信頼できる第三者がハンコ（デジタル署名）を押した構造になっています。

X.509証明書の各フィールド詳解

openssl x509 -in server.crt -text -noout を実行すると、証明書の中身がテキストとして確認できます。各フィールドの意味は以下の通りです。

基本フィールド

フィールド出力例意味
Version3 (0x2)X.509のバージョン。現代のTLSでは常に v3 が使われる（v3から拡張フィールドが使えるようになった）
Serial Number4a:5d:97:c6:...CAが発行時に採番する証明書のユニークID。失効リスト（CRL）での照合に使われる
Signature Algorithmsha256WithRSAEncryptionCAがどのアルゴリズムで署名したか。SHA-256でハッシュ → RSA秘密鍵で暗号化
IssuerCN=go-mtls-tutorial Root CAこの証明書を発行したCAの名前。クライアントはこれを手がかりに信頼チェーンを辿る
Not Before / Not AfterApr 26 2026 〜 Jul 29 2028証明書の有効期限。期限切れの証明書はTLSハンドシェイクで拒否される
SubjectCN=localhostこの証明書の持ち主（サーバー）の名前

Subject Public Key Info（公開鍵） 

Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus: 00:a5:87:96:...
Exponent: 65537 (0x10001)

サーバーの公開鍵本体です。TLSハンドシェイク時にクライアントへ送られ、鍵交換に使われます。Modulus（係数）と Exponent（指数）の2つの数値がRSA公開鍵を構成しています。対になる秘密鍵（server.key）はサーバーだけが保管しており、外部に渡しても問題ない公開情報です。

X509v3 拡張フィールド

v3から追加された拡張領域で、証明書の用途や信頼の関係を細かく制御できます。

拡張フィールド出力例意味
Authority Key IdentifierF8:DF:46:14:...発行したCAの識別子。ca.crt の Subject Key Identifier と一致する。信頼チェーンを辿るための手がかり
Basic ConstraintsCA:FALSECAとして振る舞えるか。CA:FALSE = 他の証明書に署名できないエンドエンティティ証明書。CA:TRUE = CA証明書（ca.crt がこちら）
Key UsageDigital Signature, Key Enciphermentこの証明書の鍵が何の操作に使えるかのビットフラグ
Extended Key UsageTLS Web Server Authenticationより具体的な用途。serverAuth = TLSサーバー用、clientAuth = TLSクライアント用（mTLSで重要）
Subject Alternative NameDNS:localhost, IP Address:127.0.0.1GoクライアントのSAN検証がここを見る最重要フィールド。tls.Config.ServerName と照合される。Go 1.15以降、CN は見ない
Subject Key Identifier8A:71:95:DB:...この証明書自身の識別子。他の証明書の Authority Key Identifier から参照される

Signature Value 

25:30:dc:a2:70:54:b3:53:...（512バイト）

CAの秘密鍵で署名されたデータ（上記すべてのフィールドのハッシュ値を暗号化したもの）です。openssl verify -CAfile ca.crt server.crt は、まさにこの値をCAの公開鍵で復号・検証しています。

2. 証明書の種類と役割の違い（ca.crt vs server.crt）

チュートリアル内にある ca.crt と server.crt は、どちらも内部データは全く同じ「X.509規格」で作られていますが、**「役割」**が決定的に異なります。

ファイル役割X.509拡張領域の特徴身分証明の対象
ca.crt
(ルートCA証明書)		他の証明書を発行する（ハンコを押す）権限を持つ大元の証明書。
クライアントの「信頼するリスト（Trust Store）」に登録される。		CA: TRUE
（他の証明書に署名できる）		自分自身（自己署名）
server.crt
(サーバー証明書)		サーバー自身の身元をクライアントに証明するための証明書。
ca.crt の持ち主にハンコを押してもらって作られる。		CA: FALSE
（他の証明書は発行できない）		サーバー（例: localhost）
  • パスポートの例え: ca.crt は「日本政府（外務省）」のような発行元としての権威。server.crt は「個人（サーバー）」が持つパスポート本体です。

3. パブリックなインターネットでの証明書の仕組み

本番環境（インターネット上）のウェブサイトで使われる証明書は、世界的に信頼されている少数のCAによって支えられています。

1つのCAが無数のドメインに署名する（1対多）

ドメインごとに個別のCAが存在するわけではありません。 世界には、厳格な審査をクリアした「Let’s Encrypt」「DigiCert」「GlobalSign」などの巨大なCAが数十〜数百個存在します。これらが、世界中の何千万というWebサーバーの証明書（server.crt）に対してハンコを押しています。

クライアント（OS・ブラウザ）は最初からCAを知っている

私たちが購入するPC（MacやWindows）やスマートフォン（iOSやAndroid）のOSには、買った時点で約150〜200個ほどの「信頼できるルートCAのリスト（証明書群）」がインストールされています。

通信の流れ:

  1. ユーザーが example.com にアクセスする。
  2. サーバーから example.com の server.crt が送られてくる。
  3. クライアント（PC/スマホ）は、その server.crt に押されたハンコ（Issuer）を見る。
  4. **「自分のOSに最初から入っているルートCAリストの1つ（例：DigiCert）が押したハンコだ！」**と確認できれば、安全なサイトとして通信を開始します（ブラウザに🔒マークが表示される）。

チュートリアルで RootCAs を指定した理由

Step02 のGoプログラム（client/main.go）で、明示的に RootCAs を設定して ca.crt を読み込ませた理由は、今回自分たちで作成した「オレオレCA」が、当然ながらOSに最初から入っている世界のエリートCAリスト（約150〜200個）の中には存在しないからです。

パブリックな証明書を使う場合、Go言語の tls.Dial などはOSのルートCAリストを自動的に読み込んで検証するため、手動でCAを追加するコードは不要になります。

01 Tcpdump03 Openssl