いまからでも遅くない！SSL/TLS証明書超入門（It's not too late to start! SSL/TLS Certificates: The Absolute Beginner's Guide）

こちらは次のオンラインイベントの公開資料になります。
＜イベントページ＞
https://ibm-developer.connpass.com/event/370019/

＜概要＞
最近話題の「証明書47日問題」がありますが、知らない人も意外と多い証明書について1から丁寧に解説します。
「SSL/TLSって何？」「証明書はなぜ必要？」といった基本的な疑問から、証明書問題の詳細、今後の対応策（Vault, Ansible, IBM Concert）まで、1時間で幅広くご紹介します。
※時間の都合もあり、全てを詳細に解説することが難しかったため、イベントページに掲載済みの資料も併せてご確認ください。

Transcript

1. © 2025 IBM Corporation 1 いまからでも遅くない！ SSL/TLS証明書超入門 2025年10月9日 藤川 郁也、森 江梨花、飯田 光亮 日本IBM テクノロジー事業本部
2. © 2025 IBM Corporation 2 はじめに 1. 本セッションの注意事項 2. 本日のスピーカー自己紹介 3. このセッションについて
3. © 2025 IBM Corporation 3 写真撮影 動画撮影 資料公開 ◯ × ◯ セッション受講における注意事項 ※セッション中に迷惑行為が発覚した場合は、強制退出、セッション中止などの措置を講じます
4. © 2025 IBM Corporation 4 目的 最近話題の「証明書47日問題」がありますが、知らない人も意外と多い証明書について1から丁寧に解説します。 「SSL/TLSって何？」「証明書はなぜ必要？」といった基本的な疑問から、証明書問題の詳細、今後の対応策ま で、1時間で幅広くご紹介します。 ゴール • 「証明書とその仕組みは何か？」を人に説明できるようになる • 「証明書の運用プロセス」についてざっくり理解する • 「証明書47日問題」について内容を把握する このセッションについて
5. © 2025 IBM Corporation 5 目次 Opening 第1部 そもそも証明書って何？ ・SSL/TLSって何？ ・証明書がないとどうなる？ ・SSL/TLSはそれをどう解決してる？ ・CAについて 第2部 証明書の管理・運用って？ ・証明書47日問題 ・証明書の申請・発行 ・証明書の管理 第3部 ＋α（時間があれば） ・自動化ソリューションご紹介（ステマ） Closing
6. © 2025 IBM Corporation 6 第1部 そもそも証明書って何？ 01
7. © 2025 IBM Corporation 7 証明書を理解するために 証明書について語れるようになるためには、①SSL/TLS通信 ②証明書 ③CA（認証局）について理解が必要 クライアント サーバー ①SSL/TLS通信 ②証明書 ③CA（認証局）
8. © 2025 IBM Corporation 8 SSL/TLSって何？
9. © 2025 IBM Corporation 9 SSL/TLSって何？ SSLは旧バージョンで現在はTLSが広く使用されている 以前からの慣習で現在は「SSL/TLS」と表記されることが多い ・SSL… Secure Socket Layer 元々はNetscape Communications社が開発した仕様 TLSの誕生 （SSL3.0を改良したもの） ※現在ではTLS1.2またはTLS1.3の利用が推奨されています ・TLS… Transport Layer Security SSLをベースにIETFが仕様策定
10. © 2025 IBM Corporation 10 SSL/TLSって何？ インターネット上で送受信されるデータを暗号化し、データの盗聴、改ざん、なりすましを防ぐためのプロトコル プロトコル…データをやり取りするための決まり事 SSL/TLS通信を行っている場合 クライアント サーバー ①SSL/TLS通信 悪意のある 第三者 SSL/TLS通信を行っていない場合 クライアント サーバー 悪意のある 第三者 盗聴・改ざんの 危険性あり 通信が暗号化されており 盗聴・改ざん等ができない ×
11. © 2025 IBM Corporation 11 SSL/TLSって何？ - 暗号化通信の流れ（決まりごと） SSL/TLS通信は「本人確認」と「鍵の交換」を行い、その後すべての通信を共通鍵で暗号化 サーバー クライアント 接続要求 証明書 秘密鍵 ②-1.サーバー証明書 公開鍵付送付 証明書 ②-2.証明書の 検証 ②-3.共通鍵の生成 ③-2.暗号化した 共通鍵を送付 ※以降共通鍵を使用した暗号化通信が行われる ③-1.サーバー証明書内の 公開鍵で共通鍵の暗号化 ③-3.秘密鍵で復号 公開鍵 秘密鍵 共通鍵 Step① Step② Step③
12. © 2025 IBM Corporation 12 SSL/TLSって何？ - ブラウザの表示で確認してみよう ブラウザのURL表示や鍵マークで暗号化されているか確認できる 暗号化されていないサイト（http） 暗号化されているサイト（https）
13. © 2025 IBM Corporation 13 SSL/TLSって何？ - 証明書の中身を見てみよう 証明書には、ウェブサイトの運営者情報や発行元、期限、公開鍵などが含まれている 証明書を発行したCA（認証局）の情報 証明書の使用可能期間 暗号化通信に使用する鍵 ・証明書が適用されるドメイン名 ・サイト運営会社の名前
14. © 2025 IBM Corporation 14 SSL/TLSって何？ http https SSL/TLS HyperText Transfer Protocol HyperText Transfer Protocol Secure
15. © 2025 IBM Corporation 15 証明書がないとどうなる？
16. © 2025 IBM Corporation 16 証明書がないとどうなる？ 暗号化されていない通信では ①盗聴 ②改ざん ③なりすまし のリスクが存在 ①盗聴 ②改ざん ③なりすまし メッセージを書き換える 通信相手になりすましている メッセージを盗み見る クライアント 悪意のある 第三者 サーバー メッセージ （送信内容）
17. © 2025 IBM Corporation 17 証明書がないとどうなる？ - ①データが盗聴される データが暗号化されておらず、通信の中身が第三者に盗聴されるリスクがある 証明書がない（暗号化通信されていない）場合 通信の中身が丸見え
18. © 2025 IBM Corporation 18 証明書がないとどうなる？ データの盗聴以外にも下記のようなリスクが存在 クライアント サーバー 悪意のある 中間者 ②データの改ざんがあっても気づかない データの 書き換え クライアント 本物の サーバー 偽物 ③なりすましされても気づかない example.com example.com サーバーの身元を確認できないので 偽サイトを見分けることができない データが途中で書き換えられていないか、 確認する手段がない 私が本物の example.comですよ〜 × ×
19. © 2025 IBM Corporation 19 SSL/TLSはそれをどう解決している？
20. © 2025 IBM Corporation 20 再喝：SSL/TLSって何？ - 暗号化通信の流れ（決まりごと） SSL/TLS通信は「本人確認」と「鍵の交換」を行い、その後すべての通信を共通鍵で暗号化 サーバー クライアント 接続要求 証明書 秘密鍵 ②-1.サーバー証明書 公開鍵付送付 証明書 ②-2.証明書の 検証 ②-3.共通鍵の生成 ③-2.暗号化した 共通鍵を送付 ※以降共通鍵を使用した暗号化通信が行われる ③-1.サーバー証明書内の 公開鍵で共通鍵の暗号化 ③-3.秘密鍵で復号 公開鍵 秘密鍵 共通鍵 Step① Step② Step③
21. © 2025 IBM Corporation 21 SSL/TLSはそれをどう解決してる？ - 暗号化 SSL/TLS通信によりデータが暗号化されているので、第三者がデータの中身を見ることができない 暗号化後のデータ 共通鍵暗号方式による暗号化の模式図 クライアント サーバー 平文 暗号文 共通鍵 暗号文 平文 共通鍵 暗号化通信
22. © 2025 IBM Corporation 22 SSL/TLSはそれをどう解決してる？ - 改ざん検知 SSL/TLS通信により、通信内容が改ざんされてもそれに気づくことができる クライアント サーバー メッセージ MAC関数 （ハッシュ関数） 共通鍵 MAC値 （ハッシュ値） メッセージ MAC関数 （ハッシュ関数） 共通鍵 MAC値 （ハッシュ値） MAC値 （ハッシュ値） MAC値が同じかどうかで 改ざん検知 参考：https://qiita.com/RyomaTaniyama/items/37d36a634a48516afc85
23. © 2025 IBM Corporation 23 SSL/TLSはそれをどう解決してる？ - なりすまし対策 盗聴や改ざんを防ぐには、通信相手の公開鍵が本物であることを信頼できる第三者機関（認証局、CA）が証明する必要がある サーバー CA 証明書を リクエスト 証明書を 発行 ・サーバー側の公開鍵 ・CAによる署名 サーバー CA 証明書の 送付 クライアント 署名の検証 ①サーバー側がCAに証明書発行を依頼 ②クライアントがサーバー証明書を検証 参考：https://qiita.com/RyomaTaniyama/items/37d36a634a48516afc85
24. © 2025 IBM Corporation 24 CAについて
25. © 2025 IBM Corporation 25 CAについて – CAの定義と役割 CA（認証局）とは通信相手の公開鍵が本物であることを保証する第三者機関のこと 主要ブラウザにはあらかじめ信頼できるCAリストが組み込まれており、そのCAが発行した証明書のみを信頼する CA 1 主要ブラウザ ・Chrome ・Safari ・Edge … CA 2 証明書発行者 （認証なし） × ※簡易的な説明のため厳密性に欠けています 第三者機関 監査 基準に沿っているか監査 ・秘密鍵管理 ・証明書発行プロセス 悪意のある 第三者 悪意のある第三者はなりすましをするための 証明書を作成しようとしてもCAにより却下される CA example.comの 証明書作成をリクエスト 却下
26. © 2025 IBM Corporation 26 CAについて – CAは何を見ている？ 証明書の種類ごとに、どこまで本当に信頼できる相手かを認証局が確認 証明書の種類 CAが確認する内容 認証強度 具体例 DV （Domain Validation） • ドメインの所有権 低 ~ 中 • メール認証 • DNSレコード設定 • HTTPファイルアップロード OV （Organization Validation） • ドメインの所有権 • 組織情報 （会社名・所在地・電話番号など） 中 • 商業登記簿 • 第三者データベース • 電話で実在確認 EV （Extended Validation） • ドメインの所有権 • 組織情報 • 厳格な実在性・法的存在確認 高 • 登記情報 • 法的存在 • 物理的住所の検証 • 代表者の権限確認
27. © 2025 IBM Corporation 27 CAについて – CAによって何が違う？ CA（認証局）には複数の企業が存在し、それぞれの証明書を通じて信頼性を提供 どのCAを利用するかで価格・サポート・ブランド認知度が異なり、ユーザーや企業の安心感に影響 CA名 特徴 Let’s Encrypt （無料証明書） • 無料・自動更新 • オープンソース Digicert （有料証明書） • 高信頼 • エンタープライズ向け GlobalSign （有料証明書） • 高信頼・法人向け • 日本でのサポートが強い 価格 サポート ブランド力 ・無料から有料まで ・証明書の種類によって価格が変動 ・証明書の発行・更新・失効に関するサポートの質がことなる ・商用CAは24/7サポートや電話サポートを提供する場合が多い ・大手CAの証明書は企業やユーザーに安心感を与える CA団体・企業の例
28. © 2025 IBM Corporation 28 CAについて – PrivateとPublic 証明書を発行するCA（認証局）には、社内など限定利用のためのPrivate CAと、インターネット全体で適用するPublic CAがある Private Public 社内Webポータル 開発環境 代表的な利用例 公式Webサイト ECサイト 独自に設定した端末や システムのみ 誰が信頼するか 世界中の端末やブラウザ が自動的に信頼
29. © 2025 IBM Corporation 29 本日のおさらい – 第1部「そもそも証明書って何？ 」 証明書の役割 • SSL/TLS通信とはインターネット上で送受信されるデータを暗号化し、 安全にやり取りするための決まりごとのこと • SSL/TLS証明書によってデータの盗聴、改ざん、なりすましを防いでいる CA（証明局）とは？ • CA（認証局）は通信相手の公開鍵が本物である保証をするための第三者機関のこと
30. © 2025 IBM Corporation 30 02 第2部 証明書の管理・運用って？
31. © 2025 IBM Corporation 31 証明書管理の概要 秘密鍵 CA サーバ群 クライアント 1.検知 2.申請・発行 3.保管 4.配布・導入 5.検証 証明書保管 (ローカル, 共有フォルダ etc) 証明書 リスト インフラ・ システム担当者 まず社内で検証
32. © 2025 IBM Corporation 32 証明書47日問題
33. © 2025 IBM Corporation 33 クイズ① 証明書の有効期間の短縮が実施され始めるのは何年からでしょう？ ①2026年 ②2027年 ③2029年 ④2030年 後述しますが実は2026年3月 から段階的に短縮が始まって いくことが決定しています。 なのでこれが正解
34. © 2025 IBM Corporation 34 クイズ② 証明書の有効期間として「47日」を提案した企業はどこでしょう？ ①Cisco ②Apple ③Dell ④Google Googleなどは90日などを提案していま したが、Appleが47日を提唱し、CA/B フォーラム（証明書要件を決定する機 関）で参加企業による投票が実施さ れ、最長有効期限47日が決定しました
35. © 2025 IBM Corporation 35 証明書47日問題 実は短縮スケジュールに合わせて動くためには猶予がない状況 引用：https://www.digicert.com/jp/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days
36. © 2025 IBM Corporation 36 Q.なぜ証明書は47日に？ A.「証明書そのものの信頼性の向上」のため • 証明書の信頼性の確認→ルートCAがDCVを実施した時点の情報 ＝時間が経てば経つほど確認した情報の信頼性は低下 参考：https://www.cybertrust.co.jp/blog/ssl/validity-period-shortening.html 現時点で、最長の有効期間は398日。 1年の間に証明書と実態の齟齬が生じるリスクが高い ※ DCV: ドメイン名の利用権確認
37. © 2025 IBM Corporation 37 証明書の有効期間が短縮されることによる影響 証明書の期限切れ サービスやシステムの停止 ベンダーごとに 期間短縮への 対応が異なる 証明書100枚の更新作業 約 1000時間〜 / 年 対応が追いつかない 各ベンダーに合わせた 運用プロセスの検討・実施
38. © 2025 IBM Corporation 38 証明書の申請・発行
39. © 2025 IBM Corporation 39 証明書の申請・発行プロセス 1. 事前準備 2. 秘密鍵とCSR (証明書署名要求) の作成 3. CA (認証局) への申請 4. DCV (ドメイン名の利用権確認) 5. 組織認証 6. 証明書の発行
40. © 2025 IBM Corporation 40 1. 事前準備 ①証明書の種類選択 DV OV EV ②必要情報の準備 ・ドメイン情報 ・組織情報 ※ ・申請者連絡先 ※ ※ 原則OV/EVのみ
41. © 2025 IBM Corporation 41 再掲： SSL/TLSはそれをどう解決してる？ - なりすまし対策 盗聴や改竄を防ぐには、通信相手の公開鍵が本物であることを信頼できる第三者機関（認証局、CA）が証明する必要がある サーバー CA 証明書を リクエスト 証明書を 発行 ・サーバー側の公開鍵 ・CAによる署名 サーバー CA 証明書の 送付 クライアント 署名の検証 ①サーバー側がCAに証明書発行を依頼 ②クライアントがサーバー証明書を検証 参考：https://qiita.com/RyomaTaniyama/items/37d36a634a48516afc85
42. © 2025 IBM Corporation 42 再掲：SSL/TLSって何？ - 暗号化通信の流れ（決まりごと） SSL/TLS通信は「本人確認」と「鍵の交換」を行い、その後すべての通信を共通鍵で暗号化 サーバー クライアント 接続要求 証明書 秘密鍵 ②-1.サーバー証明書 公開鍵付送付 証明書 ②-2.証明書の 検証 ②-3.共通鍵の生成 ③-2.暗号化した 共通鍵を送付 ※以降共通鍵を使用した暗号化通信が行われる ③-1.サーバー証明書内の 公開鍵で共通鍵の暗号化 ③-3.秘密鍵で複号 公開鍵 秘密鍵 共通鍵 Step① Step② Step③
43. © 2025 IBM Corporation 43 2. 秘密鍵とCSRの作成 証明書における秘密鍵とは？ • 証明書に含まれる公開鍵と対になり、SSL/TLS通信の暗号化で使用する • CSRの署名に使用されるため、この段階で作成する • 秘密鍵は証明書の申請者が自身の環境で厳重に管理 秘密鍵の本体サンプル 引用：https://www.ibm.com/support/pages/certificate-signing-request-csr-example
44. © 2025 IBM Corporation 44 2. 秘密鍵とCSRの作成 証明書署名要求 (Certificate Signing Request; CSR)とは • SSL/TLS証明書を発行してもらうために認証局（CA）に送信する要求ファイルのこと • 申請者による署名（証明書要求情報の要約（ハッシュ値）を秘密鍵で暗号化したもの）を含む 引用：https://www.ibm.com/support/pages/certificate-signing-request-csr-example CertificateRequestInfo ::= SEQUENCE { version INTEGER { v1(0) }, -- CSRフォーマットのバージョン subject Name, -- 地域やドメイン名 subjectPKInfo SubjectPublicKeyInfo, -- 公開鍵情報 attributes [0] IMPLICIT Attributes OPTIONAL -- 任意の追加情報 } signatureAlgorithm AlgorithmIdentifier, -- 署名方法（ハッシュ関数＋暗号方式） signature BIT STRING -- 申請者の署名 Base64でエンコードされた状態で 保存、貼り付け CSRの中身（簡易版） 証明書の申請画面
45. © 2025 IBM Corporation 45 2. 秘密鍵とCSRの作成 CSR作成時の入力事項 引用：https://www.ibm.com/support/pages/certificate-signing-request-csr-example CSRの作成における入力画面の例
46. © 2025 IBM Corporation 46 3. CA (認証局)への申請 – 申請手順 申請者側の準備が整ったらいよいよCAへの申請を実施 CAへの申請手順詳細 a. CAのWebサイトでアカウント作成 b. 証明書タイプの選択 c. CSRのアップロード d. 申請情報の入力 e. 料金の支払い CA インフラ 管理者 CSRの送付 ※1 上記プロセスは有償のPublic CAを想定 ※2 API経由で自動化しているものもある 受け取った公開鍵で CSRの署名の検証 申請者の公開鍵 申請者の秘密鍵 ※3 全ての申請手順が完了後に検証開始
47. © 2025 IBM Corporation 47 3. CA (認証局)への申請 – CAによる検証 申請内容（CSR）に含まれる鍵を使ってCAによる署名の検証が行われる • 公開鍵が改ざんされていないか？ • 公開鍵がセキュリティ基準を満たしているか？（正しい形式であり長さが十分か） • CSRの署名がこの秘密鍵で作成されたか？（申請者が公開鍵に対応する秘密鍵を保持しているか） 証明書要求情報 申請者の署名 署名アルゴリズム （ハッシュ化＋暗号化） 同じハッシュ 関数で要約 証明書要求情報 のハッシュ値 署名を復号して 得られたハッシュ値 CSR内の公開鍵 を用いて復号 CA CSR 一致すればOK CAによる申請者署名の検証プロセス 申請者の公開鍵 申請者の秘密鍵
48. © 2025 IBM Corporation 48 4. ドメイン名の利用権確認 (Domain Control Validation; DCV) 申請者が対象ドメインの管理権限を持っていることを確認するプロセス - 全ての証明書（DV/OV/EV）に共通 HTTP認証 DNS認証 メール認証 CA HTTP リンクをクリック DNSサーバー _acme- challenge.example.com. IN TXT “token123” ⇦ CAが指定 CA CA 管理者メールでの確認 ドメイン情報に TXTレコードを追加 CAに指定されたファイルを サーバーに配置 CAがインターネット経由で TXTレコードを確認
49. © 2025 IBM Corporation 49 5. 組織認証 (OV/EVのみ) 法人登記の確認 電話による実在確認 申請者の在籍確認 申請権限の確認 組織の実在性や所在、連絡先、申請者の権限等を確認するプロセス - 取得する証明書の内容によって確認事項が変わる
50. © 2025 IBM Corporation 50 6. 証明書の発行 CAによる証明書の署名 CA インフラ 管理者 CAによる署名 (申請者の公開鍵を保証) Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, -- 証明書本体 signatureAlgorithm AlgorithmIdentifier, -- 署名アルゴリズム signatureValue BIT STRING -- CAの署名 } 証明書のダウンロード ルートCA 中間CA インフラ 管理者 中間証明書 サーバー証明書 (SSL/TLS証明書) ルート証明書 公開鍵 秘密鍵 申請者の公開鍵 CAの署名 CAの秘密鍵
51. © 2025 IBM Corporation 51 6. 証明書の発行 CAによる証明書の署名 CA インフラ 管理者 CAによる署名 (申請者の公開鍵を保証) Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, -- 証明書本体 signatureAlgorithm AlgorithmIdentifier, -- 署名アルゴリズム signatureValue BIT STRING -- CAの署名 } 証明書のダウンロード ルートCA 中間CA インフラ 管理者 中間証明書 サーバー証明書 (SSL/TLS証明書) ルート証明書 公開鍵 秘密鍵 申請者の公開鍵 CAの署名 CAの秘密鍵 ベンダーが一括で管理
52. © 2025 IBM Corporation 52 補足：SSL/TLSの暗号化通信での証明書チェーンについて SSL/TLS通信は「本人確認」と「鍵の交換」を行い、その後すべての通信を共通鍵で暗号化 サーバー クライアント 接続要求 ②-1. サーバー証明書送付 ②-3.共通鍵の生成 ③-2.暗号化した 共通鍵を送付 ※以降共通鍵を使用した暗号化通信が行われる ③-1.サーバー証明書内の 公開鍵で共通鍵の暗号化 ③-3.秘密鍵で複号 公開鍵 秘密鍵 共通鍵 Step① Step② Step③ ②-2. 証明書の検証 ※ 段階的な検証を実施（証明書チェーン） OSやブラウザの 信頼ストア
53. © 2025 IBM Corporation 53 証明書の管理
54. © 2025 IBM Corporation 54 証明書はどこに、どれくらいあるのか 証明書数の推定値 ・小規模企業：10~40枚 ・中規模企業：100~400枚 ・大企業：500~2,000枚 ・グローバル企業：~ 10万枚 ※2 数値はPublic/Private合算値 ※3 推定には生成AI (GPT-5) を利用 →実際に2021年のリポートでは、 大企業では推定5万枚というデータも アプリ Webサービス アプリサーバー Webサーバー 顧客DB 法人向けAPI 内部ネットワーク（オンプレミス・クラウド） 外部アプリ API ゲートウェイ API管理サーバー DMZ ※1 証明書は自社管理分のみ表示 ：Public ：Private
55. © 2025 IBM Corporation 55 証明書の管理 – 台帳と有効期限の監視 管理台帳の作成 (スプレッドシート等)
56. © 2025 IBM Corporation 56 本日のおさらい – 第2部「証明書の管理・運用って？」 SSL/TLS証明書の管理・更新 • 証明書は社内の至る所に存在しており、管理・更新が大変 • 証明書の有効期間は段階的に短縮され、47日になる SSL/TLS証明書の申請・発行 • 証明書の申請時には、申請者の秘密鍵で署名したCSRをCAに提出 • 証明書の発行にあたり、ドメイン認証（と組織認証）が必要 • 証明書にはCAの署名が含まれる
57. © 2025 IBM Corporation 57 03 第3部：+α 弊社が考える自動化ソリューションご紹介
58. © 2025 IBM Corporation 58 証明書更新プロセスのAs-Is
59. © 2025 IBM Corporation 59 再掲：更新のプロセス 秘密鍵 ルート Public CA サーバ群 クライアント 1.検知 2.申請・発行 3.保管 4.配布・導入 5.検証 証明書保管 (ローカル, 共有フォルダ etc) 証明書 リスト インフラ・ システム担当者
60. © 2025 IBM Corporation 60 原則多くのステップで人手が必要 証明書更新プロセスのAs-Is詳細 人手で実施 人手or一部分をスクリプト で実行 1.検知 5.検証 2.申請・発行 3.保管 4.配布・導入 証明書の有効 期限とシステ ムのメンテナ ンスウィンド ウを確認し、 対応を設定 新しい証明書を取得するため、サーバー上で CSR（証明書署名要求） をパブリックCAベン ダー（DigiCert、CyberTrustなど）に申請を実施 1. 申請側でCSR作成する 2. パブリックCAベンダーから、ドメイン検証用 のメールが送信される 3. 指定アドレス(例:admin@example.com)で メール受信し、検証用リンクをクリック 4. ドメイン検証が完了後、証明書が発行 ※ DCV(Domain Control Validation）としてメー ルを選択した場合 サーバー証明書・中 間証明書を受領し、 CSRで生成した秘密 鍵と一緒に安全に外 部ストレージ等に保 管 新しい証明書の 反映確認、疑似 トランザション の実施など 対象システムに秘密 鍵および証明書一式 を配布し、反映を実 施。この際システム 操作の特権ロールが 必要
61. © 2025 IBM Corporation 61 47日に短縮された場合はプロセス自体が回りきらなくなる可能性がある 証明書更新プロセスのAs-Is詳細 1.検知 5.検証 2.申請・発行 3.保管 4.配布・導入 証明書の有効 期限とシステ ムのメンテナ ンスウィンド ウを確認し、 対応を設定 新しい証明書を取得するため、サーバー上で CSR（証明書署名要求） をパブリックCAベン ダー（DigiCert、CyberTrustなど）に申請を実施 1. 申請側でCSR作成する 2. パブリックCAベンダーから、ドメイン検証用 のメールが送信される 3. 指定アドレス(例:admin@example.com)で メール受信し、検証用リンクをクリック 4. ドメイン検証が完了後、証明書が発行 ※ DCV(Domain Control Validation）としてメー ルを選択した場合 サーバー証明書・中 間証明書を受領し、 CSRで生成した秘密 鍵と一緒に安全に外 部ストレージ等に保 管 新しい証明書の 反映確認、疑似 トランザション の実施など 対象システムに秘密 鍵および証明書一式 を配布し、反映を実 施。この際システム 操作の特権ロールが 必要 手動で実施されていることが多く、ヒューマンエラーの可能性をはらみ、時間がかかる 対象システム操作に必要な権限申請などが必要なこともあり、その管理プロセスにも 今後影響する可能性が高い 証明書管理はエクセルなどで実施されており、更新漏れによる事故が起きる可能性も高い状況
62. © 2025 IBM Corporation 62 証明書更新プロセスのTo-Be
63. © 2025 IBM Corporation 63 再掲：更新のプロセス 秘密鍵 ルート Public CA サーバ群 クライアント 1.検知 2.申請・発行 3.保管 4.配布・導入 5.検証 証明書保管 (ローカル, 共有フォルダ etc) 証明書 リスト インフラ・ システム担当者
64. © 2025 IBM Corporation 64 ルート Public CA 証明書自動化において、人の作業をソリューションで置き換える必要がある 自動化されたTLSサーバー証明書入れ替えの流れ 秘密鍵 1.検知 2.申請・発行 ※詳細は次ページ 3.保管 4.配布・導入 5.検証 Hashicorp Vault Ansible Automation Platform IBM Concert 監視・異常検知 死活監視 IBM Instana サーバ群 証明書, シークレット保管 自動更新 オペレーション 死活監視
65. © 2025 IBM Corporation 65 原則多くのステップで人手が必要。47日に短縮された場合はプロセス自体が回りきらなくなる可能性がある 再掲：証明書更新プロセスのAs-Is詳細 人手で実施 人手or一部分をスクリプト で実行 1.検知 5.検証 2.申請・発行 3.保管 4.配布・導入 証明書の有効 期限とシステ ムのメンテナ ンスウィンド ウを確認し、 対応を設定 新しい証明書を取得するため、サーバー上で CSR（証明書署名要求） をパブリックCAベン ダー（DigiCert、CyberTrustなど）に申請を実施 1. 申請側でCSR作成する 2. パブリックCAベンダーから、ドメイン検証用 のメールが送信される 3. 指定アドレス(例:admin@example.com)で メール受信し、検証用リンクをクリック 4. ドメイン検証が完了後、証明書が発行 ※ DCV(Domain Control Validation）としてメー ルを選択した場合 サーバー証明書・中 間証明書を受領し、 CSRで生成した秘密 鍵と一緒に安全に外 部ストレージ等に保 管 新しい証明書の 反映確認、疑似 トランザション の実施など 対象システムに秘密 鍵および証明書一式 を配布し、反映を実 施。この際システム 操作の特権ロールが 必要
66. © 2025 IBM Corporation 66 Vault Ansible AnsibleとVault、それらを統合するジョブWF製品を組み合わせることで証明書更新〜検証の自動化が可能になる 証明書更新プロセスのTo-Be 1.検知 5.検証 2.申請・発行 3.保管 4.配布・導入 証明書の有効 期限とシステ ムのメンテナ ンスウィンド ウを確認し、 対応を設定 新しい証明書を取得するため、サーバー上で CSR（証明書署名要求） をパブリックCAベン ダー（DigiCert、CyberTrustなど）に申請を実施 1. CSR作成を実施 2. DNSもしくはhttp(ファイル）による検証を 実施 3. ドメイン検証が完了すると、証明書が発行 される サーバー証明書・中 間証明書を受領し、 CSRで生成した秘密 鍵と一緒に安全に外 部ストレージ等に保 管 新しい証明書の 反映確認、疑似 トランザション の実施など 対象システムに秘密 鍵および証明書一式 を配布し、反映を実 施。この際システム 操作の特権ロールが 必要 Ansible AAP(Ansible)/Concert WFなどのWF製品によるジョブコントロール ※この部分は色々な実現方法が検討可能
67. © 2025 IBM Corporation 67 ソリューションのご紹介 （ステマです）
68. © 2025 IBM Corporation 68 Vaultのシステム・機能イメージ 信頼できるアイデンティティーを活用し、クラウド運用モデルにおけるシークレット※や、 アプリケーション・データを安全に保つインフラ・セキュリティー自動化の基盤を提供 クライアント aws アプリケーション ツール(CI/CD) 運用者/開発者 IBM Vault シークレット管理 認証 認証 認証 CLI/GUI 暗号化 API ※シークレット (Secret)とは？ パスワード、トークン、証明書、APIキーなど、 組織が機密として扱うべき情報全て 自動化 認証基盤 Microsoft Azure vmware Database Google Cloud 証明書 ==== ==== Kubernetes サーバ・クラウド …etc.
69. © 2025 IBM Corporation 69
70. © 2025 IBM Corporation 70
71. © 2025 IBM Corporation 71
72. © 2025 IBM Corporation 72 IBM Concert における証明書管理 ◼ 証明書ポリシーの遵守状況の確認 - 証明書発行者、ハッシュアルゴリズム、鍵長 のチェック - 有効期限のチェック 証明書ダッシュボード および ポリシー・ベースの管理機能を提供 ◼ Concert Workflow で Vaultから証明書情報を取込み - No Code / Low Codeの API連携ワークフロー自動化製品を統合済み 証明書管理 など Concert Workflow APIで証明書情報取得 (Pliant)
73. © 2025 IBM Corporation 73 04 Closing – まとめ
74. © 2025 IBM Corporation 74 本日のおさらい – 第1部「そもそも証明書って何？ 」 証明書の役割 • SSL/TLS通信とはインターネット上で送受信されるデータを暗号化し、 安全にやり取りするための決まりごとのこと • SSL/TLS証明書によってデータの盗聴、改ざん、なりすましを防いでいる CA（証明局）とは？ • CA（認証局）は通信相手の公開鍵が本物である保証をするための第三者機関のこと
75. © 2025 IBM Corporation 75 本日のおさらい – 第2部「証明書の管理・運用って？」 SSL/TLS証明書の管理・更新 • 証明書は社内の至る所に存在しており、管理・更新が大変 • 証明書の有効期間は段階的に短縮され、47日になる SSL/TLS証明書の申請・発行 • 証明書の申請時には、申請者の秘密鍵で署名したCSRをCAに提出 • 証明書の発行にあたり、ドメイン認証（と組織認証）が必要 • 証明書にはCAの署名が含まれる
76. © 2025 IBM Corporation 76 本日のおさらい – 第3部 自動化するためには何が必要？ • シークレット（証明書、CSRなど）を保管するSecret Store • 自動化処理を実行するExecution Code（Ansible/TerraformなどIaC） • 自動化処理実行を束ねるWorkflow どんなソリューションが適用できる？ • Secret Store: IBM Vault • Workflow: IBM Concert, RedHat Ansible Automation Platform
77. © 2025 IBM Corporation 77 Thank you！