はじめに
本ドキュメントは、SSL（Secure Sockets Layer）およびTLS（Transport Layer Security）を用いたページ認証の仕組みを分かりやすく解説することを目的としています。
背景
インターネットでやり取りする情報は、第三者に見られたり改ざんされたりする恐れがあります。例えば、オンラインショップでのクレジットカード情報や、ログイン時のパスワードなどは特に保護が必要です。SSL/TLSは、こうした情報を安全にやり取りするための技術です。
目的と対象読者
本書は、技術者だけでなくウェブ担当者や運用担当者、安定した運用を目指す方を対象に設計しています。専門用語はできるだけ平易に説明し、具体例を用いて理解を助けます。
本書の構成と読み方
全8章で、概念的な説明から実装の流れ、証明書の種類、そしてハンドシェイクや検証の具体的な手順まで段階的に解説します。まずは全体像をつかみ、必要に応じて該当章を詳しくお読みください。
第2章: SSLの基本概念と現状
概要
SSL（現在は主にTLS）は、インターネット上のデータを暗号化して安全に送受信する仕組みです。ホームページとユーザーのブラウザ間の通信を守ることで、情報の盗み見や改ざん、なりすましを防ぎます。例えばお問い合わせフォームやログイン画面、クレジットカード入力画面では必須です。
何を守るのか（シンプルな説明）
- 暗号化：通信内容を第三者に読まれないようにします。たとえば入力した住所やパスワードがそのまま流れません。
- サーバーの確認：ブラウザが本物のホームページと通信しているかを確かめます。偽サイトに情報を送らないためです。
- 整合性：送られたデータが途中で改ざんされていないかを確認します。
現状と注意点
技術的にはTLSが主流で、古いSSLは使われません。ほとんどのブラウザはHTTPS（鍵付きの通信）を標準で扱います。無料の証明書も多く、導入は以前より簡単になりました。一方で証明書の管理（期限や設定ミス）は重要です。期限切れや誤設定は「保護されていない」表示につながります。
導入のポイント（実務的な目安）
- すべてのページをHTTPSにする（ログインやフォームだけでなく）
- 証明書の有効期限を把握する
- サーバー設定で最新のTLSを有効にする
この章ではまず基本を押さえ、次章でSSL/TLSが提供する具体的な機能を深掘りします。
SSL/TLSが提供する3つの重要な機能
1. 機密性
通信内容を暗号化し、第三者が読めないようにします。たとえば「田中」という文字列は暗号化されると「19ge6kp」のような無意味な文字列に変わります。傍受されても元の内容は分かりません。これにより、パスワードや個人情報を安全に送れます。
2. 完全性
送信中にデータが改ざんされていないことを確認します。送る側が作ったチェック値（ハッシュや署名）と受け取った値を比べ、違いがあれば改ざんを検出します。改ざんがあれば受信側は受け取りを拒否できます。
3. 送信元の認証
相手が本当にそのサイトかを確かめます。ウェブサイトはデジタル証明書を提示し、信頼できる認証機関がその証明書を保証します。銀行やショッピングサイトでは、正しい相手とやり取りしているか確認できます。
これら三つがそろうことで、HTTPSは安全な通信を支えます。
SSL実装の流れ
はじめに
SSL/TLSを実装する際は、順を追って確実に作業します。ここでは具体的な手順を分かりやすく説明します。
1. 準備
対象のサーバーに管理者権限で入れること、ドメイン名が決まっていることを確認します。例えば「example.com」を使う場合、DNSがそのサーバーを指している必要があります。
2. 秘密鍵の作成とCSR生成
サーバー上で秘密鍵を作ります。秘密鍵は他人に渡してはいけません。その鍵でCSR（証明書署名要求）を作ります。CSRにはドメイン名や組織名が入ります。例：opensslで鍵とCSRを生成します。
3. CSRの提出と認証局の審査
CSRを認証局（CA）に提出します。CAはドメイン所有の確認などを行い、審査が通れば証明書を発行します。審査の内容は証明書の種類で変わります。
4. 証明書の受領とインストール
CAから送られてきた証明書（通常はサーバー証明書と中間証明書）を受け取り、秘密鍵と合わせてサーバーに配置します。Webサーバー（Apacheやnginxなど）の設定ファイルで証明書と鍵のパスを指定します。
5. 設定とテスト
設定を反映してサーバーを再起動します。ブラウザやオンラインの検査ツールで接続が暗号化されているか、チェーンに問題がないかを確認します。
6. 運用と更新
証明書には有効期限があります。期限切れ前に更新手続きを行い、秘密鍵の管理や定期的な設定チェックを続けます。
SSL証明書の種類と認証局の審査
概要
SSL/TLS証明書は認証局（CA）が申請内容を確認して発行します。確認の深さで証明書の種類が分かれ、用途に応じて選びます。
主な証明書の種類
- DV（ドメイン認証）: ドメイン所有の確認だけ行います。個人ブログやテストサイトに向きます。例: example.com の管理ができるかを確認。
- OV（組織認証）: ドメインに加え、法人や組織が実在し運営しているかを確認します。企業サイトや業務用に適します。
- EV（拡張認証）: 申請者の身元、権限、法的・物理的な存在を詳細に確認します。金融や重要サービスで信用表示を強めたい場合に選びます。
認証局の審査の流れ
- ドメイン確認: メール認証／HTTPファイル配置／DNS TXTレコードのいずれかで行います。短時間で終わることが多いです。
- 組織確認（OV/EV）: 会社登記情報や公開電話番号、公式サイトの照合、提出書類の確認を行います。
- 拡張確認（EV）: 代表者の身分確認や申請者が発行権限を持つかの確認、実際の所在地確認などを実施します。数日〜数週間かかる場合があります。
追加の種類と注意点
- ワイルドカード: *.example.com のように複数サブドメインを一括で保護します。管理が楽になります。
- マルチドメイン（SAN）: 複数のドメインを1枚でカバーできます。
選び方のポイント
小規模な個人サイトはDVで十分です。会社サイトや顧客情報を扱う場合はOVかEVを検討してください。発行の速さとコストも比較して選ぶと安心です。
ページ認証の仕組み～SSL/TLSハンドシェイク①
はじめに
ユーザーがhttpsで始まるURLにアクセスすると、まず「事前のあいさつ」のようなやり取りが始まります。これがSSL/TLSハンドシェイクです。ここでは最初の二つのメッセージ、ClientHelloとServerHelloをやさしく説明します。
1. クライアントHello
ブラウザ（クライアント）が最初に送るメッセージです。内容は主に次のような項目です。
– 対応可能なプロトコルのバージョン（例：TLS1.2やTLS1.3）
– サポートする暗号方式の候補（暗号スイート）
– 暗号鍵作成に使うためのランダム値
– サーバー名（SNI）などの拡張情報
例えると、外国の人と話す前に「私は英語か日本語どちらでも話せます」「こんな話し方ができます」と伝えるようなものです。ブラウザは複数の選択肢を送って、サーバーに希望を示します。
2. ServerHello
サーバーは受け取った候補の中から一つを選んで返します。主な内容は次の通りです。
– 選んだプロトコルバージョンと暗号スイート
– サーバー側のランダム値
– セッションID（あとで接続を早くするため）
サーバーは互いに使える共通の方法を「合意」します。ランダム値は後で安全な鍵を作る材料になります。セッションIDは以前の接続と再利用する際に便利です。
この段階で、どの方式で暗号化するかが決まります。次の手順で証明書交換や鍵の確定に進み、安全な通信路を作り始めます。
ページ認証の仕組み～SSL/TLSハンドシェイク②
ServerCertificate（サーバー証明書の送信）
サーバーは自分の証明書をブラウザに送ります。証明書にはサーバーの公開鍵や発行者情報が入っています。多くの場合、サーバー証明書と中間証明書をまとめて送ります。中間証明書は「発行者の経歴書」のようなもので、ブラウザはこれを使って最終的な信頼の流れ（ルート証明書まで）をたどります。
ブラウザは受け取った証明書を次の点で確認します。発行先のドメインと一致するか、有効期限内か、証明書チェーンが正しくつながるか、発行者の署名が正しいか。必要に応じて失効情報（OCSP/CRL）をチェックします。これらが正常なら次の段階へ進みます。
ServerKeyExchange（追加パラメータの送信）
サーバーの証明書だけで鍵交換に十分でない場合、追加の暗号パラメータを送り、それに対するデジタル署名も付けます。例えば、一時的な鍵（エフェメラル鍵）を使う方式では具体的な数値を示します。ブラウザはその署名を検証し、パラメータが改ざんされていないかを確かめます。
これらのやり取りが終わると、ブラウザは自分側の鍵情報を送る準備が整います（ClientKeyExchangeへ）。安全に共通の暗号鍵を作るための土台がここで整います。
サーバー証明書の検証プロセス
ブラウザが受け取ったサーバー証明書を確認する流れを、わかりやすく順に説明します。
1) 発行元とドメインの照合
サーバー証明書の「サブジェクト」欄にあるドメイン名が、実際に接続したサイトのドメインと一致するかを確認します。例えば「www.example.com」に接続しているのに証明書が「mail.example.com」になっていれば不一致です。ドメインが合っていなければ接続を続けません。
2) 有効期限の確認
証明書には開始日と終了日があります。現在時刻がその範囲内であるかを見ます。期限切れの証明書は安全とは言えませんので、ブラウザは警告を出します。
3) 署名の検証（チェーン検証）
サーバー証明書は、中間認証局（中間CA）が署名していることが多いです。ブラウザは中間証明書の公開鍵でサーバー証明書の署名を検証し、さらに中間証明書がさらに上位のCAに署名されているかを順に確かめます。最終的に信頼済みルート証明書にたどり着けば、改ざんされていないことが証明されます。例えると、信頼できる紹介者からの推薦状を順に確認するような手順です。
4) 撤回（失効）のチェック
証明書が発行後に取り消されている場合があります。ブラウザはCRL（失効リスト）やOCSP（オンライン問い合わせ）でその証明書が失効していないかを確認します。失効していれば接続を中止します。
これらの手順を組み合わせて、ブラウザはサーバー証明書の正当性を判断します。安全に接続するための基本的で重要なプロセスです。
