会社のセキュリティ教科書 第3部 3-4
PKIとデジタル証明書とは｜サイトの鍵マークの裏側
公開：2026年10月15日／最終更新：同／Moshiru 岡﨑 悠太
こんなときに役立ちます
- サイトの証明書の期限切れの警告が出たとき／SSL証明書を選ぶとき
- 制作会社やレンタルサーバーから「証明書の有効期間が短くなります」と案内が来て、何をすればいいか知りたいとき
- SGや支援士、Security+の勉強で、PKI・CRL・OCSPを実務の言葉でつかみたいとき
読み終えたあと、社内でこう言えます
「うちのサイトの証明書は、有効期限を◯日に確認済みです」
結論：PKI（公開鍵基盤）は、「この公開鍵は本当にこのサイトのものか」を第三者が保証する仕組みです。保証する役が認証局（CA）で、保証の書面がデジタル証明書です。ブラウザの鍵マークが示すのは通信が暗号化されていることで、サイトの運営者が信頼できることまでは示しません。証明書の最長の有効期間は、2026年3月15日から200日に短くなりました。2029年3月には47日になるため、更新は手作業ではなく自動にするのが前提になります。
PKIとは：鍵マークの裏で起きていること
暗号化の通信では、相手の公開鍵を使います（公開鍵の考え方は暗号の基本で扱いました）。ここで問題になるのが、受け取った公開鍵が本物かどうかです。偽のサイトが自分の公開鍵を渡してきたら、暗号化しても相手は偽物のままです。
そこで、信頼できる第三者が「この公開鍵はこのドメインの持ち主のものです」と署名して保証します。この第三者が認証局（CA）、保証の書面がデジタル証明書（公開鍵証明書）です。証明書・認証局・失効の確認などをまとめた仕組み全体をPKIと呼びます。
| 登場するもの | 役割 |
|---|
| ルート証明書 | 信頼の出発点（トラストアンカー）。OSやブラウザにあらかじめ入っている。 |
| 中間CA証明書 | ルートから権限を受けた認証局の証明書。実際のサーバ証明書は多くがここから発行される。 |
| サーバ証明書 | 自社サイトに入れる証明書。ドメイン名と公開鍵が書かれ、中間CAが署名している。 |
| クライアント証明書 | 人や端末に入れる証明書。社外から社内システムに入れる端末を限るときなどに使う。 |
ブラウザは、サーバ証明書→中間CA証明書→ルート証明書と署名をたどり、手元のルート証明書につながるかを確かめます。この連なりを証明書チェーンと呼びます。署名の仕組みはデジタル署名の節で説明しています。
証明書に書かれていること
- 持ち主：ドメイン名（例：www.example.co.jp）。OVやEVでは会社名も入る。
- 公開鍵：そのサイトとの暗号化に使う鍵。
- 有効期間：いつからいつまで使えるか。
- 発行者と署名：どの認証局が保証したか。改ざんされていないことを署名で確かめられる。
DV・OV・EVの違いと、鍵マークが示すもの
サーバ証明書は、認証局が発行前に何を確かめたかで3種類に分かれます。暗号化の強さは、種類によって変わりません。
| 種類 | 発行前に確かめること | 向いている場面 |
|---|
| DV（ドメイン認証） | 申請者がそのドメインを管理していること。DNSへの登録などで確かめる。 | 会社案内のサイト、ブログ。無料のものも多い。 |
| OV（組織認証） | ドメインの管理に加え、組織が実在すること。 | 問い合わせフォームや会員ページのある企業サイト。 |
| EV（拡張認証） | OVより厳しい手順で、組織の実在と申請の正当性を確かめる。 | 金融機関など、取引先から求められる場合。 |
かつてはEV証明書のサイトで、アドレスバーに会社名が緑色で出ていました。しかしGoogle ChromeはChrome 77（2019年9月）で、この表示をアドレスバーから外しました。会社名は、サイトの情報を開いた画面で確かめる形に変わっています。さらにChrome 117（2023年9月）では、鍵マークそのものを別のアイコンに置き換えました。
Googleは理由として、2021年の調査で鍵マークの正確な意味を理解していた人が11%だったことを挙げています。鍵マークは「通信が暗号化されている」印にすぎません。偽サイトでもDV証明書は取れるため、鍵マークがあるから安全なサイト、とは言えないのです。社員教育でもこの点を伝えてください。
失効：期限の前に使えなくする仕組み（CRLとOCSP）
証明書は、期限の前に無効にすることがあります。秘密鍵が漏れた、ドメインを手放した、誤って発行された、といった場合です。これを失効と言います。失効したかどうかを確かめる方法は、主に2つあります。
| 方式 | 仕組み | 弱点 |
|---|
| CRL（証明書失効リスト） | 認証局が失効した証明書の一覧を定期的に公開する。 | 一覧が大きくなる。公開の間隔のぶん、反映が遅れる。 |
| OCSP | 証明書1枚ごとに、認証局へその場で問い合わせる。 | どのサイトを見ているかが認証局に伝わる。問い合わせ先が止まると確認できない。 |
近年はCRLに寄せる流れです。証明書のルールを決める業界団体CA/Browser Forumは、2023年にOCSPを任意とし、CRLを必須にしました。無料の証明書を発行するLet's Encryptは、利用者のプライバシーを主な理由に、2025年8月6日にOCSPの提供を終えています。
試験ではCRLとOCSPの違いがよく問われます。実務では、自社で失効の確認を設定する場面は多くありません。大事なのは、秘密鍵が漏れたら認証局に失効を申請すると覚えておくことです。
有効期間はどこまで短くなるか：200日→100日→47日
サーバ証明書の最長の有効期間は、CA/Browser Forumの基本要件（Baseline Requirements）で決まります。2025年4月に可決された投票SC-081で、次のように段階的に短くすることが決まりました。
| 発行日 | 最長の有効期間 | ドメイン確認の使い回し |
|---|
| 2026年3月14日まで | 398日 | 398日 |
| 2026年3月15日から | 200日 | 200日 |
| 2027年3月15日から | 100日 | 100日 |
| 2029年3月15日から | 47日 | 10日 |
「ドメイン確認の使い回し」は、一度確かめたドメインの管理を、次の発行でも有効とみなせる日数です。2029年以降は、ほぼ毎回の更新でドメインの確認をやり直すことになります。
期間を短くする狙いは、漏れた鍵や古い情報が使われ続ける期間を縮めることです。失効の確認がうまく働かない場合でも、短い期限が安全網になります。Let's Encryptも独自に、2028年2月までに標準の有効期間を90日から45日へ縮める予定を公表しています。
会社がやること
- 証明書の一覧を作る：自社サイト、ECサイト、メールサーバー、社内の機器など。どこで何の証明書を使っているかを書き出す。
- 更新を自動にする：ACME（証明書の発行と更新を自動で行う標準の手順）に対応したサーバーや、レンタルサーバーの自動更新を使う。
- 担当と通知先を決める：自動更新が失敗したときの通知を、辞めた人ではなく今の担当に届くようにする。
- 制作会社との分担を書面にする：更新を誰が行い、誰が費用を持つかを契約や発注書で決めておく。
期限切れの警告が出たとき
証明書の期限が切れると、ブラウザは「接続がプライベートではありません」などの警告を出します。自社サイトで出た場合と、他社サイトで出た場合で、やることが違います。
| 場面 | やること |
|---|
| 自社サイトで出た | 証明書の期限と発行元を確かめ、サーバーの管理者（自社・制作会社・レンタルサーバー）に更新を依頼する。直ったら自動更新が止まった原因も確かめる。 |
| 他社や取引先のサイトで出た | 先へ進まず、IDやカード番号を入れない。相手に知らせる場合は、サイトのURLと日時を添える。 |
| 社内の機器の管理画面で出た | 機器が最初から持つ自己署名の証明書のことが多い。機器の管理者に、正しい画面か確かめてもらう。 |
たとえば社員30人の工務店では（架空の例）
施工事例を載せたサイトを、レンタルサーバーで運用している工務店を考えます。証明書は無料のDV証明書で、自動更新になっていました。ある月、ドメインの管理会社を変えたあと、自動更新が止まりました。
2か月後、問い合わせフォームに警告が出て、見込み客から「サイトが危ないと出る」と連絡が来ます。原因は、移管のときにDNSの設定が変わり、ドメインの確認に失敗していたことでした。更新の失敗を知らせるメールは、退職した前任者の宛先に届いていました。
この会社がやるべきだったのは、通知先を共有のアドレスにすることと、DNSを変えたあとに更新を試すことの2つです。有効期間が短くなるほど、このような止まり方に早く気づく仕組みが大事になります。
証明書を選ぶときの考え方
中小企業のサイトであれば、多くの場合、DVで十分です。暗号化の強さは同じで、違いは「発行前に何を確かめたか」だけだからです。ただし、次に当てはまる場合はOVやEVも検討します。
- 取引先や業界のガイドラインで、組織認証の証明書を求められている。
- 証明書の中身を見た人に、運営会社の名前を確かめてもらいたい。
- 官公庁や金融機関の調達で、証明書の種類が指定されている。
選ぶ基準として、種類より大事なのは自動で更新できるかです。OVやEVは組織の確認が入るため、更新のたびに手続きが残ることがあります。年に何回も更新が来る時代には、手作業の手順がそのまま止まる原因になります。購入前に、発行元とサーバーが自動更新に対応しているかを確かめてください。
チェックシートではこう聞かれる
| よくある設問 | 答え方の例 |
|---|
| Webサイトの通信をSSL/TLSで暗号化していますか。 | はい。全ページをHTTPSで提供し、HTTPでのアクセスはHTTPSへ転送しています。 |
| サーバ証明書の有効期限を管理していますか。 | はい。証明書は自動更新にしており、更新の失敗は共有のアドレスに通知されます。証明書の一覧を年2回見直しています。 |
| 秘密鍵が漏えいした場合の手順を定めていますか。 | いいえ。現在は未整備で、〇月までに、認証局への失効の申請と再発行の手順を文書にする予定です。 |
証明書の更新を制作会社に任せている場合は、「委託先が管理している」と書き、契約での取り決めを添えると伝わります。書き方はチェックシートの回答の書き方を参考にしてください。
試験ではここが問われる
SG・支援士・Security+ 1・CISSP 3・AWS 5
- 証明書が保証するもの：公開鍵と、その持ち主（ドメインや組織）の結びつき。認証局のデジタル署名で保証します。
- 信頼の連なり：ルート証明書（トラストアンカー）→中間CA証明書→サーバ証明書。ブラウザは手元のルート証明書までたどれるかを確かめます。
- CRLとOCSP：CRLは失効した証明書の一覧、OCSPは1枚ごとの問い合わせ。どちらも「期限前に無効にした証明書」を見分ける仕組みです。
- DV・OV・EV：違いは発行前の確認の厳しさで、暗号化の強さではありません。
- 英語：Certificate Authority、Certificate Revocation List、Online Certificate Status Protocol。AWSではACM（AWS Certificate Manager）での証明書の管理と自動更新が問われます。
確認問題
問1 デジタル証明書（公開鍵証明書）が第三者として保証するものとして、最も適切なものはどれですか。
- ア サイトの運営会社が法令を守っていること
- イ 公開鍵と、その持ち主との結びつき
- ウ サイトにウイルスが含まれていないこと
- エ 通信の内容が改ざんされないことを、認証局が常に監視していること
答えと解説
正解：イ 証明書は、公開鍵が誰のものかを認証局が署名で保証するものです。運営会社の行いの良さ（ア）や、サイトの中身の安全（ウ）は保証しません。認証局が通信を監視すること（エ）もありません。
問2 社員25人の会計事務所（架空）で、サイトのサーバーの秘密鍵が、退職した外注先のパソコンに残っていたと分かりました。証明書の期限はまだ4か月あります。最初に行うこととして、最も適切なものはどれですか。
- ア 期限が切れるまで様子を見る
- イ 認証局に証明書の失効を申請し、新しい鍵で証明書を再発行する
- ウ 証明書の種類をDVからEVに変える
- エ サイトのパスワードだけを変更する
答えと解説
正解：イ 秘密鍵が漏れたおそれがあれば、証明書を失効させ、鍵を作り直して再発行します。期限まで待つ（ア）と、その間なりすましに使われるおそれがあります。種類の変更（ウ）やパスワードの変更（エ）では、漏れた鍵は無効になりません。
問3 CRLとOCSPの説明として、最も適切なものはどれですか。
- ア CRLは失効した証明書の一覧で、OCSPは証明書ごとに状態を問い合わせる方式である
- イ CRLは証明書の発行を申請する手順で、OCSPは証明書を暗号化する方式である
- ウ CRLもOCSPも、証明書の有効期間を延ばすための仕組みである
- エ OCSPは利用者の閲覧先が認証局に伝わらないため、CRLよりプライバシーに優れる
答えと解説
正解：ア どちらも失効を確かめる方式です。発行の申請（イ）や期限の延長（ウ）とは関係ありません。OCSPは問い合わせで閲覧先が認証局に伝わるため、プライバシーの面ではCRLより不利とされます（エは逆）。
よくある質問
無料の証明書と有料の証明書で、安全性は違いますか？
暗号化の強さは変わりません。違うのは、発行前の確認（DV・OV・EV）と、補償やサポートの有無です。会社案内のサイトなら、自動更新できる無料のDV証明書で十分なことが多いです。
有効期間が47日になったら、47日ごとに作業が必要ですか？
自動更新にしていれば、人の作業は要りません。手作業で更新している場合は、2027年3月の100日への短縮までに、自動更新へ切り替える計画を立てるのが現実的です。レンタルサーバーや制作会社に、対応状況を文面で確かめてください。
社内の機器で出る証明書の警告は、無視してよいですか？
無視する習慣をつけると、本物の偽サイトの警告も見過ごすようになります。機器の管理者に確かめてもらい、可能なら正しい証明書を入れてください。警告が出ない状態を普通にしておくことが、社員教育にもなります。
参考にした資料
- CA/Browser Forum「Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates」Version 2.3.0（2026年9月）
- CA/Browser Forum「Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods」（2025年4月）
- CA/Browser Forum「Ballot SC-063v4: Make OCSP Optional, Require CRLs, and Incentivize Automation」（2023年7月）
- Let's Encrypt「OCSP Service Has Reached End of Life」（2025年8月）
- Let's Encrypt「Decreasing Certificate Lifetimes to 45 Days」（2025年12月）
- Chromium Blog「An update on the lock icon」（2023年5月）
- Chromium security-dev「Upcoming Change to Chrome's Identity Indicators」（2019年8月）
- IPA「情報セキュリティマネジメント試験 シラバス」Ver.4.1（2025年4月）