「仕組みは分かったけど、実際の設計ではどう考えればいいの？」
連載「証明書入門」も、いよいよ最終回です。第1回から第10回まで、暗号の基礎から証明書の中身、PKI、TLS、発行と自動化、社内PKIとクラウド、トラブルシュートまでを見てきました。最終回は、それらを実際の場面で使うための設計演習です。
5つの問題を用意しました。どれも現場で本当によく出会う状況をもとにしています。解答例を見る前に、ぜひ一度自分で考えてみてください。
演習の進め方
- 問題を読む：要件に線を引き、書かれていない条件（体制、予算、規程、将来の拡張）は仮定する
- 5分考える：選ぶ案と理由、確かめるコマンドを書く
- 比べる：同僚やチームで共有できるなら、ほかの人の案と比べる
- 解答例と解説を読む：決め手になった要件を確かめる
正解は1つではありません。案の良し悪しより、理由の筋道を比べることが大切です。
問1 Webサーバー2台とロードバランサーの証明書
- 状況：会員向けのサイトを、ロードバランサー（冗長ペア）とWebサーバー2台（web01・web02）で公開します。利用者は
https://www.example.jp/とhttps://example.jp/の両方でアクセスします - 要件①：
/api/へのアクセスだけを別のサーバー群に振り分けます。ログインした利用者は、Cookieで同じサーバーに届けます - 要件②：情報セキュリティの規程で「利用者からWebサーバーまで、経路上はすべて暗号化する」と定められています
- 要件③：来年、
shop.example.jpを同じロードバランサーで公開する予定です
考えるポイント：TLSをどこで終端するか、証明書の枚数と名前（SAN）、秘密鍵を置く場所の数、更新の手間
問1 解答例
| 案 | 構成 | メリット | デメリット |
|---|---|---|---|
| A | LB で終端し、LB→Web は HTTP。公開証明書1枚（SAN：example.jp、www.example.jp）を LB に置く | L7 の振り分けとセッション維持ができる。鍵も更新も1か所 | 要件②（経路上すべて暗号化）を満たさない |
| B | LB で終端し、LB→Web を再暗号化。公開証明書1枚を LB に、Web には社内CA の証明書を1枚ずつ | 要件①②を両立できる。公開証明書の鍵は LB の1か所だけ | Web 側の証明書の発行・更新と、LB での検証の設定が別に要る |
| C | TCP のまま通し（パススルー）、Web で終端。同じ公開証明書と鍵を web01・web02 に置く | 経路上どこでも平文にならない | LB は中身を見られず要件①を満たせない。鍵の置き場所と更新作業が2か所に増える |
要件①②から案Bが有力です。利用者に見える名前は1つのサイトなので、公開証明書は1枚で足ります（台数ではなく名前で数える）。example.jpとwww.example.jpはSANに並べ、ワイルドカードを使わずに済ませます。
問1 解説
証明書の枚数は「利用者が使う名前」で、置き場所は「TLSをどこで終端するか」で決まります（第9回）。
- 案Bでは、利用者向けの公開証明書はLBの1枚だけで、Webサーバーの証明書はLBだけが見る社内向けのもの
- 再暗号化の区間では、LBがWebの証明書を検証するかどうかまで決める。AWSのALBはターゲットの証明書を検証しないため自己署名でも通信できるが、オンプレのLBで検証を有効にするなら、社内CAのルートをLBに登録する
- 要件③の
shop.example.jpは、SNIで証明書を切り替えられるので、同じLBに2枚目を追加するだけ。Webは触らない - ワイルドカード（
*.example.jp）にまとめると、鍵が漏れたときの影響がすべてのサブドメインに及び、example.jp自体も含まれない（第6回）
問2 47日化に向けた運用の見直し
- 状況：社内で管理している公開証明書は約40枚です。台帳は表計算ソフトで、最後に更新した担当者は異動しました。多くはOV証明書を毎年購入し、手作業で入れ替えています
- 内訳：AWSのALB（ACMを使用）8枚、オンプレのWebサーバー（Apache・IIS）15枚、メールサーバー（SMTP・IMAP）3枚、VPN装置・WAF・ロードバランサーなどの機器10枚、用途不明4枚
- 背景：公開証明書の有効期間は、2026年3月から最長200日になり、2027年3月に100日、2029年3月に47日へ短くなります（第6回）
- 要件：期限切れによるサービスの停止をなくし、担当者1人あたりの作業を増やさないこと
考えるポイント：最初に何をするか、自動化できるものとできないものの分け方、期限の監視のしかた
問2 解答例
| 案 | 進め方 | メリット | デメリット |
|---|---|---|---|
| A | 担当者を増やし、手順書と更新カレンダーで手作業を続ける | すぐに始められる。機器を変えずに済む | 47日になると年に約8回、40枚で300回を超える作業になる。ミスは減らない |
| B | 棚卸し → ACM・ACME で自動化 → 自動化できない機器は終端を集約するか更新 → 期限と CT を監視 | 更新の回数が増えても作業が増えない。停止の原因を仕組みで減らせる | 棚卸しと移行に数か月かかる。機器の更新に費用がかかることがある |
| C | 公開証明書をやめ、すべて社内CA の証明書にする | 有効期間を自由に決められる | 社外の利用者や取引先の端末では信頼されず、公開するサービスには使えない |
案Bが有力です。案Cは、社内だけで使う名前にだけ当てはまります（問3）。期限の直前ではなく余裕を持って更新するため、47日のときの実際の更新は年に8回より多くなります。Aは回数に比例して増え、Bは最初に作業を前払いする、という違いです。
問2 解説：移行の進め方
| 段階 | 作業 | ポイント |
|---|---|---|
| 1 棚卸し | CT ログ（crt.sh など）で自社ドメインの発行履歴を洗い出し、実機と照合する | 用途不明の4枚を見つける。台帳は名前・置き場所・担当・更新方法の4点 |
| 2 AWS | ACM は DNS 検証の CNAME を残す。EC2 の OS に置くものは ACM の ACME かエクスポート | 198日・45日前に自動更新（第9回） |
| 3 オンプレのサーバー | certbot・win-acme などの ACME クライアントで自動更新（第8回） | DNS-01 は _acme-challenge を CNAME で委任し、DNS の API キーを各サーバーに配らない |
| 4 機器 | ACME や API に対応した版へ更新する。無理なら前段の LB で終端を集約する | 自動化できない置き場所を減らすことが目的 |
| 5 認証の再利用期間 | ドメイン認証の再利用期間も、2029年3月に10日へ短くなる | 発行のたびの認証も自動化しないと追いつかない |
| 6 監視 | 期限の監視（残り30日で警報）、CT の監視、CAA で使う CA を限定 | 自動更新の失敗を検知する。ARI（RFC 9773）で更新時期の指示も受ける |
自動化の本当の目的は、更新を「人が思い出して行う作業」から「失敗したときだけ人が呼ばれる仕組み」に変えることです。そして、知らない証明書は自動化できない。だから棚卸しが1段目です。CAAの書き方は、連載「DNS入門」の第6回を参照してください。
問3 社内システム用の証明書をどう用意するか
- 状況：ADドメインは
corp.example.jpで、社内のWebシステムが約50あります（app01.corp.example.jpなど）。corp.example.jpは社内のDNSだけで引け、外部には公開していません（連載「DNS入門」第2回） - 端末：ドメインに参加したWindows PC 800台、Mac 50台とiPhone 300台（MDMで管理）、Linuxサーバー40台
- 現状：各システムは自己署名証明書で、利用者は証明書の警告を「詳細設定 → 進む」で回避しています
- 要件：警告をなくし、今後増えるシステムにも手間をかけずに証明書を出せること。社内のホスト名の一覧は外部に知られたくない
考えるポイント：公開CAか社内CAか、ルート証明書の配り方、更新の自動化、自己署名を続けてはいけない理由
問3 解答例と解説
| 案 | 方法 | メリット | デメリット |
|---|---|---|---|
| A | 公開CA の証明書を ACME（DNS-01）で取る | ルートの配布が不要で、どの端末でも信頼される | CT ログで社内のホスト名が公開される。外部の DNS に認証用の名前が要る。期間の短縮の影響を受ける |
| B | 社内CA（AD CS の2層、または AWS Private CA）で発行し、ルートを配布する | 名前が外に出ない。Windows は自動登録で発行・更新できる | ルートの配布（Mac・iPhone は MDM、Linux、Firefox・Java の独自のストア）と、CA の運用・保護が必要 |
| C | 自己署名のまま、各端末に個別に信頼させる | 費用がかからない | システムごとに配布が要り、期限と鍵の管理が破綻する。警告を回避する習慣が残る |
要件から案Bが有力です。「社内のホスト名を外に知られたくない」という要件が、案Aを外す決め手になります（公開CAの証明書はCTログに載る）。
- ドメイン参加のWindowsは、エンタープライズCAのルートを自動で信頼するが、それ以外の端末には明示的に配る
- 社外からも使うシステムだけ、案Aにする
- 公開CAのワイルドカード（
*.corp.example.jp）なら個々の名前はCTに出ないが、50のシステムに同じ鍵を配ることになる
CAを作る手間より、ルートを配る先の数が作業量を決めます。案Cの自己署名を続けると、第1回・第6回で見たとおり、警告を回避する習慣が残り、本物の攻撃を見過ごす原因になります。
問4 「一部の端末だけ証明書エラーが出る」
- 状況：社内ポータル
portal.corp.example.jp（IIS、社内CAの証明書）について、月曜の朝に「証明書エラーが出る」と連絡が入りました。先週末、発行CAを新しいサーバーへ移行し、ポータルの証明書も新しい発行CAのものに入れ替えています - 報告①：新しく導入したMac 10台で、Chromeに
NET::ERR_CERT_AUTHORITY_INVALIDが出る - 報告②：LinuxのバッチサーバーからAPIを呼ぶと、
curl: (60) ... unable to get local issuer certificate (20)で失敗する - 報告③：工場のWindows PC 1台だけ
NET::ERR_CERT_DATE_INVALIDが出る。ほかのWindows PC（ドメイン参加）は正常に開ける
考えるポイント：報告ごとに原因は同じか、どの順に何を確かめるか、どこを直すか
問4 解答例と解説
| 案 | 対応 | メリット | デメリット |
|---|---|---|---|
| A | 各端末で警告を回避させる（「進む」を押す、curl に -k を付ける） | すぐに業務を再開できる | 原因が残り、中間者攻撃に無防備になる。連携の設定に -k が残る |
| B | 報告ごとに、サーバーが送るチェーン、端末の信頼ストア、時刻を順に確かめ、サーバーと配布の設定を直す | 原因ごとに正しく直せ、再発も防げる | 切り分けの知識と時間が要る |
| C | 証明書を旧発行CA のものに戻す | 移行前の状態に戻る | Mac と工場の PC の問題は直らない。移行も止まる |
答えは案Bです。同じ証明書なのに端末によって結果が分かれるのは、原因が3つ別々だからです（第10回）。
- 報告を端末の種類で分ける（Mac／Linux／工場のPC）
- 報告②（Linux）：
openssl s_client -showcertsで0番しか無ければ、IISに新しい中間証明書を入れ忘れている（WindowsやChromeはAIAで補うため気づかない）→ IISのCert:\LocalMachine\CAに追加 - 報告①（Mac）：MDMの構成プロファイルに新しい社内ルートが入っていない → MDMで配る
- 報告③（工場のPC）：
w32tm /query /statusで時刻を確かめる → NTPに合わせる
サーバー側から確かめると、影響の広い原因から片付きます。案Aの「回避」は、第10回で見たとおり、その端末だけを無防備にするので避けます。
問5 vCenter・ESXiの証明書を社内CAのものにする
- 状況：vCenter Server 1台（
vcsa01.corp.example.jp、vSphere 8.0 Update 3）とESXi 8台で、ESXiは今後も増える予定です。証明書は構築時のまま（VMCAの既定）です - 監査の指摘：「管理者がvSphere Clientを開くと証明書の警告が出る。社内CAの証明書にすること」
- PKI担当（AD CSの2層構成）の方針：「発行CAの下にCAを作ることは、原則として認めない（例外は申請と審査が必要）」
- 運用：vSphereの管理者は2名で、ESXiの追加や入れ替えは年に数回あります。ESXiのHost Clientを直接開くのは障害のときだけです
考えるポイント：VMCAをどう使うか、社内CAから何を何枚もらうか、更新の手間と、ホストを増やすときの手間
問5 解答例
| 案 | 方法 | メリット | デメリット |
|---|---|---|---|
| A | VMCA を中間CA にする（社内CA から「下位の証明機関」の証明書を1枚もらい、VMCA のルートを置き換える） | 以後の ESXi の証明書も社内CA のチェーンになり、追加と更新は自動 | PKI 担当の例外の審査が要る。置き換え後に ESXi の証明書の更新が要る |
| B | ハイブリッド（vCenter の Machine SSL だけを社内CA の Web サーバー用証明書にし、ESXi は VMCA のまま） | PKI の方針に沿い、社内CA からは1枚で済む。監査の指摘が解消する | Host Client では警告が出るため、VMCA のルートを管理者の端末に配る。Machine SSL は手動で更新 |
| C | カスタム（vCenter と ESXi 8台に社内CA の証明書を1枚ずつ） | すべてが社内CA のチェーンになる | 9枚以上の発行と、ESXi を増やすたびの手作業。更新も台数分 |
方針と台数から、まず案Bが有力です。「発行CAの下にCAを作らない」という方針が案Aを、「ESXiが今後も増える」という運用が案Cを外す決め手になります。ESXiの証明書も社内CAにそろえる必要が出たら、PKI担当と合意して案Aに移ります。案Cは、規程でVMCAを使えない場合の選択肢です（第9回）。
問5 解説：置き換えの注意点
| 項目 | 内容 | 注意 |
|---|---|---|
| 証明書の名前 | 主体は PTR と一致する FQDN（vcsa01.corp.example.jp）。別名は SAN に入れ、主体の名前を SAN の先頭に置く | ワイルドカードは使えない。IP アドレスでも開くなら SAN に入れる |
| 用途 | 案A は「下位の証明機関」（Basic Constraints が CA）の証明書、案B は Web サーバー用 | Web サーバー用の証明書では VMCA は中間CA として動かない |
| チェーン | 置き換えのときに、発行CA とルートの CA 証明書もそろえて登録する | 欠けると、サービスの起動や連携製品の接続で失敗する |
| 手順 | vSphere Client の証明書の管理、または vCenter の certificate-manager | 事前に電源を切った状態のスナップショットとバックアップを取る |
| 連携製品 | NSX、VCF Operations、バックアップ製品などは vCenter の証明書を登録し直す | 置き換えの後に、各製品の接続を確認する |
| 期限の監視 | vCenter は期限の警報を出す（既定で残り30日で赤の警報） | 社内CA の証明書は CA/B Forum の200日の上限の対象外だが、期間は社内規程で決める |
vCenter 8.0 Update 3h以降は、VMCAが発行したMachine SSL証明書を期限の5日前に自動更新します（案Bで社内CAの証明書にした部分は対象外）。手順は版ごとに違うため、Broadcom TechDocsの該当するバージョン（vSphere 8.0／9.0の「vSphere Authentication」）で確認してください。
連載を終えて
5つの問題、いかがでしたか。どの問題も、答えを知っているかどうかより、「どの要件が決め手か」と「誰が、どの名前の、どの鍵を、誰の署名で信じているか」を言えるかどうかが大事でした。
11回にわたって、暗号の基礎から証明書の中身、PKI、TLS、発行と自動化、社内PKIとクラウド、トラブルシュートまでを見てきました。証明書は「期限が来たら更新するもの」と思われがちですが、その裏には、通信の安全を支える仕組みがぎっしり詰まっています。そして有効期間が47日へ短くなる今、証明書の運用は「人が思い出して行う作業」から「仕組み」へと変わろうとしています。
この連載が、証明書のエラーが出たときに「警告を無視して進む」以外の手を打つための、そして自動化へ踏み出すための手がかりになればうれしいです。まずは自分が管理するサイトにopenssl s_client -showcertsを実行して、送られているチェーンと期限を確かめてみてください。
最後まで読んでいただき、ありがとうございました。
コメント