LASSIC Media らしくメディア
証明書管理(PKI)システム｜SSL/TLS更新と失効の要件
LASSIC IT事業部｜元請（プライムベンダー）としてセキュリティ基盤の開発・運用を受託
この記事のポイント
- 証明書管理(PKI)とは、SSL/TLSサーバー証明書やクライアント証明書の発行・更新・失効というライフサイクルを統制する仕組みです。Microsoftはこの役割を担うAD CSを「PKI証明書の発行と管理」を行うサーバー役割と説明しています。
- 核となるのは、(1)内部CA・公開CAによる発行、(2)期限切れを防ぐ更新の自動化(ACME)、(3)CRL/OCSPによる失効確認の3点です。鍵・シークレットを扱うKMS、ID権限を統制するIGAとは役割が異なります。
- 証明書の有効期間はCA/Browser Forumの決定で短縮が進み、更新頻度が上がります。外注では失効確認の方式選定、更新自動化、内部CAの設計・運用まで一貫して担える体制かが確認の軸になります。
目次
証明書切れが招くシステム障害——有効期間の短縮で高まる更新・失効管理の負荷
Webサイトの常時暗号化、社内システムのクライアント認証、API連携の相互認証——。いまや多くのサービスがSSL/TLS証明書を土台にして動いています。ところが、この証明書には有効期限が定められています。更新を一度でも見落とせば、その瞬間にブラウザーやクライアントは接続を拒否し、サービスは止まってしまうのです。
やっかいなのは、この障害が「攻撃されたわけでもないのに」起きる点です。設定ミスや監視の抜け、担当者の異動による引き継ぎ漏れ——地味な原因で証明書は切れます。しかも影響は突然、しかも全面的に現れます。手作業と表計算ソフトの管理台帳に頼っている限り、証明書の本数が増えるほど見落としのリスクは膨らんでいくでしょう。
この負荷を一段と押し上げているのが、証明書の有効期間そのものの短縮です。ブラウザーベンダーとCAが参加するCA/Browser Forumは2025年4月、公開CAが発行するTLSサーバー証明書の最長有効期間を現行の398日から段階的に短縮し、最終的に47日へ引き下げる方針を可決しました*6。短縮は2026年3月に始まり2029年3月に完了する日程が示されています*6。有効期間が短くなれば更新の回数は増え、手作業での運用は現実的でなくなります。だからこそ、発行から更新、失効までを体系立てて扱う証明書管理(PKI)の仕組みが要るのです。
本稿では、証明書管理(PKI)が何をする仕組みなのか、鍵・シークレットを扱うKMSやIDを統制するIGAとどう役割が分かれるのか、そして開発を外注する際にどこを確認すべきかを、公式情報に基づいて整理していきます。想定する読者は、セキュリティ基盤の発注を検討するIT部門の意思決定層の方々です。
証明書管理(PKI)とは、SSL/TLS証明書の発行・更新・失効を統制する仕組み
証明書管理とは、PKI(Public Key Infrastructure。公開鍵暗号を使って「この鍵は確かにこの相手のものだ」と証明する土台となる仕組み)のもとで発行される電子証明書の一生を、発行から失効まで統制する営みを指します。MicrosoftはこのPKIを担う製品であるActive Directory証明書サービス(AD CS)を、「セキュアな通信と認証のプロトコルで使われるPKI証明書の発行と管理(issuing and managing public key infrastructure certificates)を行うWindows Serverの役割」だと説明しています*1。
電子証明書が果たす機能は3つに整理できます。暗号化による機密性(confidentiality)、電子署名による完全性(integrity)、そして証明書の鍵をコンピューターやユーザー・デバイスのアカウントに結びつけることによる認証(authentication)です*1。SSL/TLSによるWeb通信の暗号化はこのうち機密性と、サーバーが本物であることの認証を支えています。加えてクライアント証明書を使えば、接続してくる端末や利用者そのものの認証にも用いることができます*1。
証明書を発行する主体がCA(Certification Authority、認証局)です。AD CSはルートCAと下位CA(subordinate CA)を構成し、ユーザー・コンピューター・サービスへ証明書を発行して、その有効性(certificate validity)を管理すると公式に記載されています*1。ここで押さえておきたいのは、証明書管理が単なる「発行」で終わらない点です。証明書には有効期間があり、期限が来る前の更新が要ります。さらに、鍵の漏洩や担当者の退職といった事情で期限前に無効化したい場合には、失効(revocation)という手続きが必要になります。
つまり証明書管理(PKI)の本質は、発行・更新・失効という一連のライフサイクルを、抜けなく回し続けることにあります。AD CSも、証明書の登録(enrollment)と失効を管理する機能を含むと明記されています*1。証明書1枚ずつを手作業で追うのではなく、どの証明書がいつ切れ、どれを更新し、どれを失効させたかを一元的に把握する。この統制こそが、証明書切れによる障害を防ぐ土台になるわけです。
KMS・IGAとの違い——鍵管理・ID統制と「証明書ライフサイクル管理」の役割分担
証明書管理(PKI)を検討する際に混同されやすいのが、KMS(鍵・シークレット管理)やIGA(IDガバナンス)との違いです。いずれも暗号や認証・認可にかかわるため、守備範囲が重なって見えます。当サイトでも別途取り上げていますが、担う対象は大きく異なるのです。ここで整理しておきましょう。
KMS(Key Management Service／シークレット管理)は、暗号鍵やAPIキー、パスワードといった「鍵・秘密情報そのもの」を保護しながら生成・保管・ローテーションする仕組みです。データベースを暗号化する鍵や、アプリケーションが使う接続情報を集中管理する役割を担うものです。証明書管理も鍵を扱う点では隣り合っていますが、主眼はX.509証明書という「身元を証明する文書」の発行・更新・失効に置かれます。証明書の中には公開鍵が含まれ、対応する秘密鍵の保護はKMSやHSM(ハードウェアセキュリティモジュール)の領域と重なるため、両者は補完的に使われることが多いと言えます。
一方のIGA(Identity Governance and Administration。IDガバナンスと管理)は、人や組織のアカウントに対して「誰が何にアクセスできるか」という権限を統制する仕組みです。入社・異動・退職に伴う権限の付与や剥奪、アクセス権の棚卸しといった、人を軸にしたガバナンスを扱います。これに対して証明書管理が相手にするのは、主にサーバーやデバイス、サービスといった「機器・システムの身元(マシンアイデンティティ)」と、その証明書の期限管理です。人の権限そのものを承認・監査するIGAとは、対象も目的も分かれています。
3者の違いを整理すると次の通りです。いずれもセキュリティ基盤を構成する要素であり、競合ではなく補完の関係にあります。
| 観点 | 証明書管理(PKI) | KMS(鍵・シークレット管理) | IGA(IDガバナンス) |
|---|---|---|---|
| 主な対象 | SSL/TLS・クライアント証明書*1 | 暗号鍵・APIキー・パスワード | 人・組織のアカウントと権限 |
| 主な目的 | 発行・更新・失効の統制*1 | 鍵の生成・保管・ローテーション | アクセス権の付与・剥奪・棚卸し |
| 証明する相手 | 機器・サービスの身元(マシン) | 秘密情報そのもの(値) | 人の役割・アクセスの妥当性 |
要件定義の段階で「どの層に何を任せるか」を先に整理しておくと、機能の重複投資を避けやすくなります。証明書の秘密鍵をKMSやHSMで保護し、その証明書のライフサイクルを証明書管理で回す、といった組み合わせも一般的です。境界を意識したうえで設計することが大切になります。
証明書管理の機能要素——発行・更新(ACME)・失効(CRL/OCSP)・内部CAと公開CA
証明書管理システムの中身を、機能要素に分解して見ていきます。ここを理解しておくと、外注時の要件定義でどこに工数がかかるかを判断しやすくなります。
発行——内部CAと公開CAの使い分け
証明書はCAが発行しますが、そのCAには大きく2種類あります。一つは、Let’s EncryptやDigiCertのように、ブラウザーの信頼ストアに登録された公開CAです。インターネットに公開するWebサイトのSSL/TLS証明書は、こうした公開CAから取得しないと利用者のブラウザーで警告が出てしまいます。もう一つが、自社で運用する内部CA(プライベートCA)です。AD CSはまさにこの内部CAを構築する製品であり、ルートCAと下位CAを構成して社内のユーザー・コンピューター・サービスへ証明書を発行します*1。
使い分けの勘どころは、証明書を誰が検証するかにあります。社外の不特定多数が検証するなら公開CA、社内システム間の相互認証やVPN・IPsec・スマートカードサインインのように検証者が自社の管理下にあるなら内部CAが向きます*1。AD CSはこれらの用途に加え、ドメインアカウントを持たないルーターなどのネットワーク機器へ証明書を発行するNetwork Device Enrollment Serviceも備えています*1。内部CAを持つと発行の自由度は上がりますが、その分、CA自身の鍵の保護と運用責任を自社で負う点は見落とせません。
更新——ACMEによる自動化で期限切れを防ぐ
証明書管理でもっとも障害に直結しやすいのが、更新の抜けです。ここを人手に頼らず自動化する標準的な手段がACME(Automatic Certificate Management Environment)です。Let’s Encryptはドキュメントで「発行と更新の自動化はとても重要(automation of issuance and renewals is really important)」だと述べ、ドメインの管理権を自動で検証する仕組みを提供しています*2。
ACMEでは、申請者がドメインを本当に管理しているかを確かめる「チャレンジ」がいくつか用意されています。代表的なのはHTTP-01・DNS-01・TLS-ALPN-01の3方式です*2。HTTP-01は、指定されたトークンを含むファイルをWebサーバーの所定パス(/.well-known/acme-challenge/)に置いて検証する方式で、もっとも広く使われています*2。DNS-01は、トークンから導いたTXTレコードを_acme-challengeという名前でDNSに登録する方式で、ワイルドカード証明書の取得にも対応します*2。TLS-ALPN-01は443番ポート上のTLSを使う方式で、リバースプロキシの前段などで用いられます*2。これらを組み込んでおけば、期限が近づくと自動で再発行・差し替えが走り、更新漏れの余地を大きく減らせます。
失効——CRLとOCSPによる無効化の確認
有効期間内であっても、秘密鍵の漏洩などが起きれば、その証明書は直ちに無効にしなければなりません。この無効化が失効であり、失効した証明書を検証側がどう見分けるかを担うのがCRLとOCSPです。
CRL(Certificate Revocation List、証明書失効リスト)は、失効した証明書の一覧です。RFC 5280はCRLを「CAまたはCRL発行者によって署名され、公開リポジトリで自由に入手できる、失効証明書を識別するタイムスタンプ付きのリスト」と定義しています(https://datatracker.ietf.org/doc/html/rfc5280 )*4。CAは時間ごと・日ごと・週ごとといった一定周期でCRLを発行し、各証明書はそのシリアル番号でリストに載ります*4。検証側は十分に新しいCRLを取得し、対象のシリアル番号が載っていないかを確認するわけです*4。手軽な一方、周期発行ゆえに反映まで時間差が出る点が弱みになります*4。
この時間差を補うのがOCSP(Online Certificate Status Protocol)です。RFC 6960はOCSPを、識別した証明書の失効状態をアプリケーションが判定できるようにするプロトコルと位置づけ、CRLよりも時宜を得た(more timely)失効情報を提供しうると説明しています(https://datatracker.ietf.org/doc/html/rfc6960 )*5。応答は「good(有効)」「revoked(失効済み)」「unknown(不明)」の3値で返されます*5。AD CSでは、この失効状態の問い合わせを処理して署名付きの応答を返すOnline Responder(オンライン レスポンダー)がOCSPの役割を担うと記載されています*1。
失効確認の方式選定は、いま過渡期にあります。Let’s Encryptは2024年12月、プライバシー上の懸念——OCSP応答を通じてCAが「どの利用者がどのサイトを訪れたか」を把握しうる点——を理由に、OCSPを終了しCRLへ移行する計画を公表しました*3。同計画では2025年5月7日に証明書からOCSPのURLを削除し、2025年8月6日にOCSPレスポンダーを停止するとされています*3。失効確認をどう実装するかは、利用するCAの方針も踏まえて設計する必要があるのです。
証明書管理基盤の構築を外注する際に確認したい4つの点
証明書管理は、製品を導入すれば完結する性格のものではありません。自社のどこに何本の証明書があるかを把握し、更新を自動化し、失効を漏れなく確認する運用の設計に、成否がかかっています。外注を検討する際は、次の4点を委託先と確認しておくとよいでしょう。
第一に、証明書の棚卸しと一元管理を設計できるかどうかです。Webサーバー、ロードバランサー、社内システム、ネットワーク機器と、証明書は散在します。どこに何があり、いつ切れるかを可視化する仕組みを描けるかが出発点になります。台帳が整っていなければ、更新も失効管理も後手に回るからです。
第二に、更新の自動化をどこまで担えるかです。ACMEに対応した公開CAとの連携、HTTP-01やDNS-01といったチャレンジ方式の選定、サーバーへの自動差し替えまでを含めて設計できるかを見ます*2。有効期間の短縮で更新頻度が上がる以上、手作業前提の提案では長続きしません*6。
第三に、失効確認の方式をどう選ぶかです。CRLとOCSPの使い分け、そしてOCSPを終了しCRLへ移すCAが出てきている過渡期の動向を踏まえた設計提案ができるかを確認します*3*4*5。ここを誤ると、失効させたはずの証明書が現場で通ってしまう事態にもつながりかねません。
第四に、内部CAの構築・運用まで踏み込めるかです。社内認証やVPNで内部CAを使うなら、AD CSなどでのルートCA・下位CAの設計、鍵の保護、失効応答の運用体制までが問われます*1。内部CAは発行の自由度が高い反面、運用責任も自社側に生じるためです。
これらは複数の専門領域にまたがります。棚卸しから更新自動化、失効確認、内部CA運用までを一貫して担える体制が前提になります。現状の証明書の管理状況を診断したうえで、内製と外注の切り分けを検討することが実務的です。
まとめ：証明書管理(PKI)システムで押さえる3つの要点
本稿では、証明書管理(PKI)システムの仕組みと外注時の確認点を、公式情報をもとに整理しました。要点は3つに集約できます。第一に、証明書管理とはSSL/TLS証明書やクライアント証明書の発行・更新・失効というライフサイクルを統制する仕組みであり、公式にはPKI証明書の発行と管理を担う実践と位置づけられています*1。第二に、鍵・シークレットを扱うKMS、ID権限を統制するIGAとは対象が異なり、証明書管理は機器・サービスの身元と期限の管理に主眼を置きます*1。第三に、更新はACMEによる自動化、失効はCRL/OCSPによる確認が核であり、有効期間の短縮でこれらの重要性はさらに高まっています*2*5*6。これらを担える体制を持つ委託先かどうかが、外注の分かれ目になるでしょう。
よくある質問
証明書管理(PKI)は、KMSやIGAと何が違うのですか。
対象が異なります。KMSは暗号鍵やAPIキーといった鍵・秘密情報そのものの生成・保管を、IGAは人や組織のアカウントに対するアクセス権の統制を担います。これに対し証明書管理(PKI)は、SSL/TLS証明書やクライアント証明書という「機器・サービスの身元を証明する文書」の発行・更新・失効を統制する仕組みです*1。3者は競合ではなく補完関係にあり、証明書の秘密鍵をKMSやHSMで保護する構成も一般的です。
証明書の有効期間が短くなると聞きました。運用にどう影響しますか。
CA/Browser Forumは2025年4月、公開CAが発行するTLSサーバー証明書の最長有効期間を398日から段階的に短縮し、2029年3月までに47日へ引き下げる方針を可決しました*6。有効期間が短くなるほど更新の回数は増え、手作業での運用は現実的でなくなります。ACMEによる更新の自動化を組み込み、期限前に自動で再発行・差し替えが走る仕組みを整えておくことが重要になります*2。
CRLとOCSPは何が違うのですか。どちらを使えばよいですか。
どちらも証明書が失効していないかを確認する手段です。CRLは失効証明書のシリアル番号を並べたリストを一定周期で発行する方式で、反映に時間差が出ます*4。OCSPは失効状態をその場で問い合わせて「good／revoked／unknown」で受け取る方式で、より時宜を得た情報を得られます*5。ただしLet’s Encryptはプライバシー上の理由でOCSPを終了しCRLへ移行しており、利用するCAの方針を踏まえた選定が必要です*3。
内部CA(プライベートCA)と公開CAは、どう使い分ければよいですか。
証明書を誰が検証するかで分かれます。社外の不特定多数がブラウザーで検証するWebサイトには、信頼ストアに登録された公開CAの証明書が必要です。一方、社内システム間の相互認証やVPN・スマートカードサインインなど検証者が自社の管理下にある用途には、AD CSなどで構築する内部CAが向きます*1。内部CAは発行の自由度が高い反面、CA自身の鍵の保護と運用責任を自社で負う点に注意が必要です。
証明書管理基盤の構築を外注する場合、何を基準に委託先を選べばよいですか。
証明書の棚卸しと一元管理を設計できるか、ACMEによる更新の自動化を担えるか、CRL/OCSPの過渡期を踏まえた失効確認を設計できるか、内部CAの構築・運用まで踏み込めるか——この4点を確認するとよいでしょう*1*2*3。複数領域にまたがるため、棚卸しから更新自動化、失効確認、内部CA運用までを一貫して担える体制が前提になります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Microsoft「What is Active Directory Certificate Services in Windows Server?」（Windows Server ドキュメント）（https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/active-directory-certificate-services-overview）
- *2 出典：Let’s Encrypt「Challenge Types」（Let’s Encrypt ドキュメント）（https://letsencrypt.org/docs/challenge-types/）
- *3 出典：Let’s Encrypt「Intent to End OCSP Service」（2024年12月5日）（https://letsencrypt.org/2024/12/05/ending-ocsp/）
- *4 出典：IETF RFC 5280「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile」（https://datatracker.ietf.org/doc/html/rfc5280 ）
- *5 出典：IETF RFC 6960「X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP」（https://datatracker.ietf.org/doc/html/rfc6960 ）
- *6 出典：CA/Browser Forum「Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods」（2025年4月11日）（https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/ ）
