¶ 🛠 証明書の運用（Let’s Encrypt / ADCS）
¶ 🧭 このページについて
証明書は「作って終わり」ではなく、運用が本番になる。期限切れ・チェーン不備・秘密鍵の取り扱いミス・更新漏れが起きると、WebサイトやAPIは突然使えなくなる。
このページでは、公開証明書（Let’s Encrypt）と内部証明書（ADCS）を並べて、発行から更新、配布、確認、失効までの運用を整理する。手順そのものは環境ごとに変わるため、ここでは「考え方と運用ルール」を中心にまとめる。
また、反映先の例として Apache（httpd） を取り上げ、SNI（証明書の出し分け）も含めて「どうやって事故が起きるか」「どうやって防ぐか」を説明する。
¶ 📋 目次
- 運用の全体像（ライフサイクル）
- 運用で守るもの（秘密鍵・期限・チェーン）
- Let’s Encrypt運用（公開サイト向け）
- ADCS運用（内部向け）
- Apacheを例にした反映（VirtualHost）
- SNIとは（なぜ必要か）
- 運用でよくある事故パターン
- 点検コマンド（最低限セット）
- 運用ルール（チェックリスト）
¶ 🔁 運用の全体像（ライフサイクル）
証明書運用は、流れにすると次の輪になる。
- 発行（新規取得）
- 配置（サーバに反映）
- 確認（正しい証明書が返るか）
- 更新（期限前に入れ替え）
- 失効（漏えい・不要になったとき）
- 棚卸し（どこに何があるかの管理）
¶ 🧠 身近な例
- 免許証：取得して終わりではなく、更新しないと失効するし、紛失したら再発行が必要になる
¶ 図：証明書運用の輪
¶ 🔐 運用で守るもの（秘密鍵・期限・チェーン）
運用で守る対象は、だいたいこの3つに集約される。
¶ 1) 秘密鍵
秘密鍵が漏れると「本物になりすまし」が成立するため、証明書そのものより秘密鍵が重要になる。
¶ 🧠 身近な例
- 秘密鍵：印鑑そのもの
- 証明書：印鑑証明書
印鑑が漏れたら、印鑑証明書が正しくても意味がない。
¶ 2) 期限
証明書は期限が来ると突然エラーになる。更新を「作業」ではなく「仕組み」にしておくのが運用の基本になる。
¶ 3) チェーン（中間証明書）
サーバ証明書だけ置いても、クライアントがルートまで辿れないと失敗する。公開証明書では特に「中間証明書の設定漏れ」が事故の典型になる。
¶ 🧠 身近な例
- サーバ証明書：身分証
- 中間証明書：発行窓口の証明
- ルート証明書：信頼の根拠
途中が欠けると「この身分証は本物と言い切れない」になる。
¶ 🌍 Let’s Encrypt運用（公開サイト向け）
Let’s Encryptは公開CAであり、不特定多数のブラウザが最初から信頼している証明書を発行できる。特徴は 短い有効期限 と 自動更新前提。
¶ ✅ 何が運用の中心か
- 有効期限が短いので、自動更新（仕組み化）が必須
- 更新が失敗した場合に気付ける（監視・通知）
- 反映後に正しい証明書が返るか確認する（SNI・チェーン）
- 更新後にWebサーバ（Apache等）へ反映する（再読み込み）
¶ 🧠 身近な例
- 定期券：期限が短い代わりに、更新が仕組み化されていると事故が減る
¶ 取得方法（ACMEチャレンジの選び方）
- HTTP-01：Webサーバに検証ファイルを置く方式（公開HTTPが必要）
- DNS-01：DNSにTXTレコードを置く方式（ワイルドカードに使える）
- TLS-ALPN-01：TLSで検証する方式（用途により）
「公開WebならHTTP-01」「ワイルドカードやWebを露出したくないならDNS-01」が基本になる。
¶ 図：Let’s Encrypt（HTTP-01）の流れ
¶ ✅ 自動更新の要点（運用ルール）
- 更新処理は「定期実行」してよい（必要なときだけ更新される）
- 更新後は Apache 等の再読み込みが必要（証明書を読み直す）
- 失敗時に通知が飛ぶ仕組みを持つ（メール・監視など）
¶ 🏢 ADCS運用（内部向け）
ADCSは組織内で使うためのCAであり、信頼は「社内端末にルート証明書を配布する」ことで成立する。公開サイトには向かないが、内部運用には強い。
¶ ✅ ADCSのメリット（運用面）
- 社内で完結する
発行・更新・失効・ポリシーを社内でコントロールできる。 - 端末に信頼を配布できる
GPOなどでルート証明書を配布し、社内端末に確実に信頼させられる。 - テンプレートで用途を統制できる
サーバ証明書、クライアント認証、コード署名など用途ごとに発行条件を整理できる。 - 自動登録（自動更新）の設計が可能
端末・サーバの証明書更新を仕組み化しやすい（手更新の事故を減らせる）。 - コスト面で有利
内部用途を公開CAに依存せず、数が増えても発行コストが増えにくい。
¶ ✅ 何が運用の中心か
- ルート証明書を配布して信頼を成立させる（GPO等）
- テンプレート（用途）を分けて発行基準を整理する
- 失効情報（CRL/OCSP）を利用者が参照できるようにしておく
- 有効期限と更新方針を決める（短すぎても長すぎても事故る）
¶ 🧠 身近な例
- 社員証：会社の中では通用するが、社外では通用しない
ただし社内の入口管理には一番効く
¶ 図：ADCSで証明書を発行する（ざっくり）
¶ 🌐 Apacheを例にした反映（VirtualHost）
この章は「Apacheではどう置くのが普通か」の参考事例。ここは環境ごとに違うため、実際に適用する場合は既存設定の影響範囲を確認してから進める。
¶ ✅ 重要な考え方
- サイト（FQDN）単位で証明書を分ける
- VirtualHost単位で証明書を指定する
- 更新後は Apache を再読み込みして反映する
- 中間証明書（チェーン）が欠けない形にする
¶ 例：SNI前提のVirtualHost（概念例）
<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificateFile /path/to/example.com/fullchain.crt
SSLCertificateKeyFile /path/to/example.com/privkey.key
DocumentRoot /var/www/example
</VirtualHost>
※ fullchain は「サーバ証明書 + 中間証明書」を含む形（公開CAではこれが扱いやすい）。
※ ADCSなどでチェーンを別ファイルで管理する場合は、環境の方針に合わせる。
¶ 🧭 SNIとは（なぜ必要か）
SNI（Server Name Indication）は、TLSハンドシェイクの最初に「どのホスト名に接続したいか」をサーバへ伝える仕組み。
SNIが必要になる典型はこれ。
- 1台のApache（同一IP:443）で複数サイトを運用する
- サイトごとに別の証明書を返したい
¶ 🧠 身近な例
- 受付で「どの部署に用事か」を先に伝えると、正しい窓口に案内できる
¶ 図：SNIで証明書を切り替える
SNIが効いていないと「意図しない証明書が返る」事故が起きる。複数サイト運用では、この確認が運用の中心になる。
¶ 🚨 運用でよくある事故パターン
¶ ① 証明書が更新されたのに、古い証明書が返ってくる
- 原因：Apacheの再読み込み漏れ、または参照先が別ファイル
- 対策：SNI付きでopenssl確認、設定ファイルで参照先確認
¶ ② 一部の端末だけ証明書エラーになる
- 原因：中間証明書が欠けていて、端末側の補完能力に差が出る
- 対策：サーバが「サーバ＋中間」を返す形にする
¶ ③ 内部CAの証明書が外部端末で信頼されない
- 原因：外部端末は社内ルートCAを信頼していない（仕様）
- 対策：公開は公開CA、内部は内部CAで用途を分ける
¶ ④ Let’s Encryptの更新が失敗して期限切れ
- 原因：チャレンジ方式の要件が満たせない（HTTP閉塞、DNS更新失敗など）
- 対策：更新を仕組み化し、失敗時に通知し、期限を監視する
¶ 🧪 点検コマンド（最低限セット）
¶ ① SNI付きで証明書の中身を見る
openssl s_client -connect example.com:443 -servername example.com |
openssl x509 -noout -subject -issuer -dates
¶ ② チェーン（中間証明書）が返っているか見る
openssl s_client -connect example.com:443 -servername example.com -showcerts
¶ ③ HTTP→HTTPSのリダイレクト確認
curl -I http://example.com/
curl -I https://example.com/
¶ ✅ 運用ルール（チェックリスト）
¶ 棚卸し（必ず持つ）
- 対象FQDN
- 発行元（Let’s Encrypt / ADCS）
- 有効期限
- 証明書ファイルの場所
- 秘密鍵ファイルの場所
- Apache設定ファイル（VirtualHost）
- 更新方式（自動 / 手動）
- 更新後の確認方法
¶ 更新作業（必ずやる）
- 更新実行
- Apache再読み込み
- opensslで返却証明書を確認（SNI付き）
- チェーンが欠けていないか確認
- 失敗時のログと通知を確認
¶ 秘密鍵（絶対ルール）
- 秘密鍵は外へ出さない
- 権限は最小限にする
- バックアップは暗号化して扱う