デジタル証明書（X.509）の構造と検証プロセスを完全解説

HTTPSで保護されたWebサイトにアクセスすると、ブラウザのアドレスバーに鍵マークが表示されます。この小さなアイコンの裏側では、デジタル証明書を用いた複雑な検証処理が瞬時に実行されています。情報処理安全確保支援士試験では、この仕組みの理解が午前II・午後問題の両方で問われます。

本記事では、X.509規格に基づくデジタル証明書の内部構造を詳細に解説し、ブラウザがどのようにして「このサイトは信頼できる」と判断しているのか、その検証プロセスを技術的に掘り下げます。実務でのサーバー構築やトラブルシューティングにも直結する知識を、体系的に身につけていきましょう。

デジタル証明書（X.509）の本質と役割

インターネット上の通信では、接続先が本物であるかを物理的に確認できません。銀行のWebサイトだと思ってアクセスしても、精巧に作られたフィッシングサイトである可能性があります。この問題を解決するのがデジタル証明書です。

X.509規格が定める標準フォーマット

デジタル証明書は、ITU-T（国際電気通信連合）が策定したX.509という国際標準規格に従って作成されます。現在の主流はバージョン3（v3）です。この規格により、世界中のあらゆるブラウザ、OS、サーバーが共通して証明書を処理できる環境が実現しています。

X.509証明書が結びつけている核心的な情報は以下の2つです。

主体者（Subject）の身元情報：ドメイン名や組織名などの識別情報
主体者の公開鍵：暗号化通信や署名検証に使用される暗号鍵

信頼できる第三者機関である認証局（CA：Certification Authority）が、「この公開鍵は確かにこの組織のものである」とデジタル署名を付与することで、証明書の正当性が保証されます。

パスポートに例えた証明書の仕組み

デジタル証明書の動作原理は、パスポートの発行・確認プロセスに例えると理解しやすくなります。

申請者：Webサーバーの管理者（海外渡航したい本人）
認証局（CA）：パスポートを発行する外務省
秘密鍵：本人の実印や顔そのもの（厳重に保管し、決して他者に渡してはならない）
公開鍵：パスポートに記載される顔写真や署名の写し（公開しても問題ない）
デジタル証明書：発行されたパスポート本体
検証者（ブラウザ）：空港の入国審査官

入国審査官は提示されたパスポートを見て、以下の項目を確認します。

偽造防止機能の確認：特殊インクや透かし（デジタル署名に相当）の検証
有効期限の確認：期限切れのパスポートは無効
本人確認：パスポートの写真と目の前の人物が一致するか（公開鍵と秘密鍵のペア整合性）
ブラックリスト照合：指名手配されていないか（失効リスト）

デジタル証明書の検証は、このプロセスを暗号技術で実現したものです。

PKI（公開鍵基盤）における証明書の位置づけ

デジタル証明書は単独で機能するのではなく、PKI（Public Key Infrastructure：公開鍵基盤）という仕組みの中で動作します。PKIの主要な構成要素は以下の通りです。

CA（認証局）：証明書を発行し、デジタル署名を付与する機関
RA（登録審査局）：申請者の本人確認や審査を行う機関（CAが兼ねる場合も多い）
リポジトリ：証明書や失効リスト（CRL）を保管・公開するサーバー
エンドエンティティ：証明書を利用するサーバーや利用者

試験では、「CAの秘密鍵が漏洩した場合の影響範囲」や「ルートCAと中間CAの階層構造」といった観点で、PKI全体の理解度が問われます。CAの秘密鍵が漏洩すると、攻撃者が任意のドメインの正規証明書を偽造できてしまうため、影響は極めて甚大です。

X.509証明書の詳細構造：各フィールドの役割

X.509 v3証明書の内部構造を、各フィールドレベルで解説します。試験で「このフィールドには何が格納されるか」と問われた際に即答できることが重要です。

基本フィールド（Basic Fields）

証明書の核となる必須情報です。

1. バージョン（Version）

証明書のフォーマットバージョンを示します。拡張領域（Extensions）が利用可能な「v3（値は0x02）」が現在の標準です。v1やv2は互換性のために残されていますが、現代のセキュリティ要件を満たすにはv3が必須です。

2. シリアル番号（Serial Number）

CAが発行した証明書を一意に識別するための番号です。同一CAが発行した証明書間で重複してはなりません。証明書を失効させる際、失効リスト（CRL）でこのシリアル番号を指定して特定します。通常は128ビット以上のランダムな値が設定されます。

3. 署名アルゴリズム識別子（Signature Algorithm ID）

CAがこの証明書に署名する際に使用した暗号アルゴリズムを示します。

例：sha256WithRSAEncryption
意味：証明書データのハッシュ値をSHA-256で計算し、RSA暗号方式でCAの秘密鍵を使って署名した

近年は楕円曲線暗号を用いたecdsa-with-SHA256なども増加しています。アルゴリズムの選択は、セキュリティ強度と計算コストのトレードオフで決定されます。

4. 発行者（Issuer）

証明書を発行したCAの名前です。**識別名（DN：Distinguished Name）**という形式で記述されます。

例：C=US, O=Let's Encrypt, CN=R3
C：国（Country）
O：組織名（Organization）
CN：一般名（Common Name）

このDN形式により、世界中のCA組織が一意に識別できます。

5. 有効期間（Validity）

証明書が有効な期間を定義します。

開始日時（Not Before）：この日時より前は証明書が無効
終了日時（Not After）：この日時より後は証明書が無効

試験では、有効期限切れによるシステム障害や、2038年問題（UNIX時刻のオーバーフロー）との関連で出題されることがあります。最近のWeb用TLS証明書は、セキュリティ強化のため有効期間が**397日以下（約13ヶ月）**に制限される傾向にあります。これは、万が一秘密鍵が漏洩した場合の被害期間を最小化するためです。

6. 主体者（Subject）

証明書の持ち主（Webサーバーなど）の名前です。Issuerと同様にDN形式で記述されます。

例：C=JP, ST=Tokyo, L=Minato-ku, O=Example Corp, CN=www.example.com

従来は、ここの**CN（Common Name）**にドメイン名を記載し、ブラウザはそれを検証していました。しかし、現在は後述するSAN（Subject Alternative Name）が優先的に使用されます。

7. 主体者の公開鍵情報（Subject Public Key Info）

証明書の最も重要な部分です。

アルゴリズム識別子：RSA、ECDSA、Ed25519など
公開鍵データ：実際の暗号鍵データ（バイト列）

この公開鍵が改ざんされると、攻撃者が偽の鍵に置き換えて暗号化通信を盗聴できてしまうため、デジタル署名による保護が不可欠です。

拡張領域（Extensions）の詳細

X.509 v3で追加された拡張領域は、現代のインターネットセキュリティにおいて極めて重要な役割を果たします。試験でも頻出の分野です。

1. Subject Alternative Name (SAN)

「主体者代替名」と訳されます。これは現代の証明書検証において最も重要な拡張です。

従来のCN（Common Name）は1つのドメイン名しか記述できませんでしたが、SANを使用することで以下が可能になります。

複数ドメインの保護：www.example.comとapi.example.comを1枚の証明書でカバー
ワイルドカード：*.example.comで全サブドメインを保護
IPアドレスの記述：内部システム向け証明書で使用

重要な仕様変更：現在のブラウザ（Chrome 58以降など）は、CNフィールドを無視し、SANのみを確認します。SANが存在しない証明書は、たとえCNが正しくてもエラーになります。この仕様変更を理解していないと、実務で証明書エラーの原因特定に時間がかかります。

2. Key Usage（鍵用途）

公開鍵を何の目的で使用してよいかをビットフラグで制限します。

digitalSignature：デジタル署名の作成・検証
keyEncipherment：鍵の暗号化（TLSの鍵交換プロセスなど）
dataEncipherment：データの直接暗号化
keyCertSign：他の証明書への署名（CA証明書のみ）
cRLSign：失効リスト（CRL）への署名

用途を制限することで、万が一秘密鍵が漏洩した場合の被害範囲を限定できます。例えば、TLS用の証明書でコード署名ができてしまうと、攻撃者がマルウェアに正規の署名を付与できてしまいます。

3. Extended Key Usage（拡張鍵用途）

Key Usageよりも具体的な利用目的を指定します。

serverAuth（1.3.6.1.5.5.7.3.1）：サーバー認証（Webサーバー用）
clientAuth（1.3.6.1.5.5.7.3.2）：クライアント認証（端末認証用）
codeSigning（1.3.6.1.5.5.7.3.3）：ソフトウェアのコード署名
emailProtection（1.3.6.1.5.5.7.3.4）：S/MIME暗号化メール

これらはOID（Object Identifier）という数値で一意に識別されます。Webサーバー用証明書でコード署名を行おうとしても、Extended Key Usageの制約により拒否されるべきです。

4. Basic Constraints（基本制約）

証明書の持ち主が「CA（認証局）」なのか「エンドエンティティ（末端利用者）」なのかを区別します。

CA=TRUE：この証明書を使って、下位階層の証明書を発行可能
CA=FALSE：これ以上証明書を発行できない（末端証明書）
pathLenConstraint：CA=TRUEの場合、何階層下まで証明書を発行できるかを制限

この制約がないと、攻撃者が正規のエンドエンティティ証明書を入手し、それを悪用して「偽CA」を作り、任意のドメインの偽証明書を発行できてしまいます。Basic ConstraintsのCA=FALSEは、そのような攻撃を防ぐ重要な防御機構です。

5. その他の重要な拡張

CRL Distribution Points：失効リスト（CRL）のダウンロードURL
Authority Information Access（AIA）：OCSPレスポンダのURLや、発行CAの証明書の取得先
Certificate Policies：証明書が準拠するポリシーのOID（EV証明書の識別などに使用）

デジタル署名値（Signature Value）

証明書の最後には、CAによるデジタル署名が付加されています。これは以下の手順で生成されます。

証明書の基本フィールドと拡張領域（署名値を除く全データ）をハッシュ関数（例：SHA-256）で処理し、固定長のハッシュ値を得る
そのハッシュ値を、CAの秘密鍵で暗号化する
暗号化された値を署名値として証明書に付加する

この仕組みにより、証明書の内容が1ビットでも改ざんされると、検証時にハッシュ値の不一致が検出され、改ざんを確実に検知できます。

ブラウザによる証明書検証プロセス

利用者がHTTPSサイトにアクセスした際、ブラウザはサーバーから送られてきた証明書を瞬時に検証します。このプロセスはパスバリデーション（Path Validation）と呼ばれ、SC試験の午後問題で通信ログやエラー原因の解析として頻出です。

検証の5ステップ

証明書検証は以下の手順で実行されます。どれか1つでも失敗すると、ブラウザは「この接続ではプライバシーが保護されません」という警告を表示します。

ステップ1：信頼の連鎖（Chain of Trust）の構築

証明書単体では信頼されません。ブラウザは「誰が署名したか」を辿り、信頼できる起点まで遡ります。

サーバー証明書のIssuerフィールドを確認 → 「中間CA A」が発行者
中間CA Aの証明書を取得（サーバーから送られるか、AIAから取得）
中間CA AのIssuerを確認 → 「ルートCA X」が発行者
ルートCA Xの証明書を確認 → 発行者が「自分自身」（自己署名証明書）

ここでブラウザ（またはOS）は、内蔵している信頼されたルート証明書ストアを確認します。「ルートCA X」の証明書がそこに含まれていれば、トラストアンカー（信頼の起点）に到達したと判断され、検証が進みます。含まれていなければ「不明な発行者」としてエラーになります。

試験対策ポイント：企業内でプライベートCAを構築した場合、全社員のPCやモバイル端末にルート証明書を配布・インストールする必要があります。これは、このトラストアンカーを確立するためです。配布が漏れた端末では、社内システムにアクセスするたびに証明書エラーが発生します。

ステップ2：デジタル署名の暗号学的検証

信頼の連鎖が確認できたら、各証明書が改ざんされていないかを暗号技術で検証します。

証明書チェーン内の各証明書について、以下の計算を実行します。

証明書の「署名値以外の部分」（TBSCertificate：To Be Signed Certificate）を取り出す
それをハッシュ関数（証明書に記載されたアルゴリズム、例えばSHA-256）で処理し、ハッシュ値Aを計算する
証明書の「署名値」を取り出す
発行者（親CA）の公開鍵を使って署名値を復号し、ハッシュ値Bを得る
AとBを比較する
- 完全一致：証明書は改ざんされていない
- 不一致：証明書が改ざんされているか、破損している

この検証により、証明書がCAによって署名されてから現在まで、1ビットたりとも改変されていないことが数学的に保証されます。

ステップ3：有効期間の確認

現在時刻が、証明書のNot BeforeとNot Afterの間に収まっているかを確認します。

トラブル事例：PC やサーバーのシステム時計が大幅にずれていると、正規の証明書でも「有効期限外」と判断されてエラーになります。NTP（Network Time Protocol）による時刻同期が重要な理由の1つです。

ステップ4：失効状態（Revocation）の確認

証明書が有効期限内であっても、以下の理由でCAによって無効化（失効）されている場合があります。

秘密鍵の漏洩または侵害の疑い
ドメイン所有者の変更
証明書の誤発行
組織の解散や契約解除

ブラウザは以下のいずれかの方法で失効状況を確認します。

CRL（Certificate Revocation List）：失効した証明書のシリアル番号が記載されたリストファイルをCAのサーバーからダウンロードして照合
OCSP（Online Certificate Status Protocol）：OCSPレスポンダというサーバーにリアルタイムで証明書の状態を問い合わせる

性能上の問題：失効確認は追加の通信が発生するため、Webサイトの表示速度に影響します。そのため、OCSP Staplingという技術が開発されました。これは、Webサーバー自身が定期的にOCSPレスポンスを取得し、TLSハンドシェイク時にクライアントに提供する方式です。クライアントはOCSPレスポンダに問い合わせる必要がなくなり、高速化とプライバシー保護の両方が実現されます。

失効確認の詳細は、次回の記事で掘り下げます。

ステップ5：ドメイン名の一致確認

最後に、証明書のSAN（Subject Alternative Name）フィールドに記載されているドメイン名と、ブラウザのアドレスバーに入力されたURLのドメイン名が一致するかを確認します。

google.comの証明書をyoutube.comのサーバーで使用 → エラー
ワイルドカード証明書*.example.comはwww.example.comにマッチするが、example.comにはマッチしない

試験頻出ポイント：ワイルドカード証明書は1階層のサブドメインのみをカバーします。*.example.comはapi.example.comにマッチしますが、api.internal.example.comにはマッチしません。この仕様を理解していないと、実務でワイルドカード証明書を導入しても一部のサービスで証明書エラーが発生します。

証明書の種類と認証レベル

X.509の技術仕様は同一でも、CAが実施する審査の厳格さによって証明書は3つのレベルに分類されます。試験では、「Webサイト運営者の実在性を証明するのに適切な証明書はどれか」といった形で出題されます。

DV（Domain Validation：ドメイン認証）

審査内容：ドメインの管理権限のみを確認します。具体的には、指定されたメールアドレスへの確認メール送信、特定のDNSレコード設定、特定のHTTPファイル配置などの自動確認で発行されます。

特徴：

発行が高速（数分〜数時間）
低コスト（無料〜数千円/年）
暗号化通信は保証されるが、運営者の実在性は保証されない
フィッシングサイトでも取得可能

用途：個人ブログ、開発環境、社内システム

リスク：DV証明書は暗号化を提供しますが、「誰が運営しているか」は保証しません。攻撃者がg00gle.com（0が2つ）のような類似ドメインを取得してDV証明書を付ければ、鍵マークが表示される「安全そうに見える」フィッシングサイトが完成します。

OV（Organization Validation：企業実在認証）

審査内容：ドメイン管理権限に加え、以下を確認します。

登記事項証明書や商業登記による組織の法的実在性
電話による実在確認（電話帳やNTT番号案内との照合）
申請担当者の在籍確認

特徴：

証明書のSubjectフィールドに組織名（O=Company Name）が記載される
ブラウザの鍵マークをクリックすると組織情報が確認可能
発行まで数日〜1週間程度

用途：一般企業のコーポレートサイト、会員制サービス、EC サイト

EV（Extended Validation：EV認証）

審査内容：CA/ブラウザフォーラムが定めた極めて厳格な基準（EV SSL証明書ガイドライン）に基づいて審査します。

組織の法的実在性の厳密な確認
物理的な所在地の確認（現地訪問または第三者データベース照合）
署名権限者の在籍と権限の確認
ドメイン所有権の確認
第三者データベース（Dun & Bradstreetなど）との照合

特徴：

最も信頼性が高い
かつてはアドレスバーが緑色になる視覚的表示があった（2019年以降は廃止）
現在は鍵マーククリックで詳細な組織情報が表示される
発行まで2週間程度
コストが高い（年間数万円〜）

用途：金融機関、証券会社、大規模ECサイト、決済サービスなど、高度な信頼が要求されるサイト

試験対策：「暗号化強度はDV・OV・EVで変わらない」という点が重要です。違いは「誰が運営しているか」の保証レベルです。技術試験では、暗号化とアイデンティティ検証を混同しないよう注意が必要です。

PEM形式とDER形式：実務で遭遇するファイル形式

証明書を実際に扱う際、拡張子が.pem、.crt、.cer、.derなどさまざまで混乱することがあります。試験でも、ファイル形式の理解が問われることがあります。

DER形式（Distinguished Encoding Rules）

X.509証明書のデータ構造（ASN.1という記法で定義）を、バイナリデータとしてエンコードした形式です。

特徴：

人間には読めないバイナリ形式
データサイズが小さい
Java、Windows環境でよく使用される
拡張子：.der、.cer

PEM形式（Privacy Enhanced Mail）

DER形式のバイナリデータをBase64エンコードし、テキスト化した形式です。

特徴：

テキストエディタで開ける
-----BEGIN CERTIFICATE-----で始まり-----END CERTIFICATE-----で終わる
Linux（Apache、Nginx）で標準的に使用される
複数の証明書を1ファイルに連結可能（証明書チェーンの保存に便利）
拡張子：.pem、.crt、.cer

試験対策：「証明書の内容を確認せよ」という問題では、以下のOpenSSLコマンドを知っていると有利です。

# PEM形式の証明書を人間が読める形式で表示
openssl x509 -in certificate.pem -text -noout

# DER形式からPEM形式へ変換
openssl x509 -inform DER -in certificate.der -outform PEM -out certificate.pem

実務では、証明書形式の変換トラブルが頻発します。形式の違いを理解していないと、「証明書をインストールしたのに認識されない」といった問題に直面します。

ルート証明書ストアとセキュリティリスク

信頼の起点となるルート証明書は、OS（Windows、macOS、Android、iOSなど）やブラウザ（Firefoxなど）のベンダーがあらかじめ審査して組み込んでいます。これをルート証明書ストアまたはトラストストアと呼びます。

ルート証明書ストアへの攻撃

もし攻撃者があなたのPCのルート証明書ストアに、悪意のある「偽ルートCA証明書」をインストールさせることに成功したらどうなるでしょうか？

攻撃者は、その偽ルートCAを使って、google.comやbank.co.jpなどの任意のドメインの偽証明書を自由に発行できます。あなたのブラウザは偽ルートCAを「信頼」しているため、偽サイトに接続しても警告が表示されません。これにより、HTTPS通信の内容がすべて盗聴・改ざんされるMITM（Man-in-the-Middle：中間者）攻撃が成立します。

正当なMITM：SSL復号化装置

企業ネットワークでは、セキュリティ対策として意図的にMITM構成を採用することがあります。

SSL/TLS復号化プロキシ：

社員のHTTPS通信を復号化してウイルスチェックやDLP（Data Loss Prevention）を実施
プロキシサーバーに専用のプライベートCAを設置
全社員のPCに専用ルート証明書を配布
社員から見ると正規のHTTPS通信に見えるが、実際はプロキシが中継している

この仕組みを正しく理解していないと、「社内システムだけ証明書エラーが出る」といったトラブルの原因究明ができません。

試験ポイント：「ルート証明書をユーザー端末に配布する理由」を問われた場合、「SSL復号化プロキシ等での通信検査を可能にするため」「プライベートCAによる社内証明書を信頼させるため」といった観点で回答できるようにしましょう。

ハッシュアルゴリズムの危殆化とSHA-1問題

証明書の署名に使用されるハッシュアルゴリズムも、時代とともに変化します。

SHA-1の危殆化

かつてはSHA-1（160ビットハッシュ）が広く使用されていましたが、計算機の性能向上と攻撃手法の進化により、衝突攻撃（異なるデータから同じハッシュ値を生成）が現実的な時間で可能になりました。

2017年、GoogleとCWIアムステルダムが「SHAttered攻撃」を発表し、実際にSHA-1の衝突を生成しました。これにより、攻撃者が以下のような攻撃を実行できる可能性が示されました。

正規の内容の証明書申請データを作成
同じSHA-1ハッシュ値を持つ悪意ある内容のデータを作成
正規データでCAから証明書を取得
証明書の署名値を悪意あるデータに流用

SHA-2への移行

これを受け、2016年頃から主要ブラウザはSHA-1証明書の受け入れを段階的に停止しました。現在はSHA-256（SHA-2ファミリー）以上が必須です。

試験対策：「なぜ暗号アルゴリズムを定期的に更新する必要があるのか」という問いには、「計算機性能の向上により、以前は安全とされていたアルゴリズムが現実的な時間で解読可能になるため（危殆化）」と答えられるようにしましょう。

暗号技術は「絶対に安全」ではなく「現時点の技術で解読に膨大な時間がかかる」という相対的な安全性です。定期的な見直しが不可欠です。

Certificate Transparency（CT）：証明書の透明性

比較的新しい技術ですが、SC試験でも今後出題される可能性があるのがCT（Certificate Transparency）です。

CTの目的

CAがドメイン所有者の許可なく証明書を誤発行してしまう事故や、CAへのハッキングによる不正証明書発行を早期発見するための仕組みです。

CTの仕組み

CAが証明書を発行する際、公開ログサーバー（CTログ）にその記録を登録
CTログは誰でも閲覧・監視可能
ドメイン所有者は自社ドメインの証明書発行を監視できる
不正発行を発見したら即座にCAに報告・失効要求

証明書にSCT（Signed Certificate Timestamp）というデータが埋め込まれることで、CTログへの登録済みであることが証明されます。

Google Chromeは、2018年以降に発行されたEV証明書については、SCTがないものを信頼しないポリシーを採用しています。

試験ポイント：「CA自身が侵害された場合のリスク軽減策」として、CT が有効であることを理解しておきましょう。

ASN.1：証明書の記述言語

X.509証明書はASN.1（Abstract Syntax Notation One）という言語でデータ構造が定義されています。

ASN.1は、プログラミング言語やプラットフォームに依存しない抽象的なデータ記述言語です。例えば、有効期間（Validity）は以下のように定義されています。

Validity ::= SEQUENCE {
     notBefore      Time,
     notAfter       Time
}

この定義により、「Validityは2つのTime型データを順番に並べた構造体である」ことが厳密に規定されます。ASN.1で定義されたデータ構造を、実際のバイト列にエンコードする規則がDER（Distinguished Encoding Rules）です。

このような厳密な型定義と標準化により、世界中の異なるシステム間で証明書データを正確に解釈・交換できる基盤が確立されています。

試験レベル：ASN.1の詳細な構文は試験で問われることは少ないですが、「X.509はASN.1で定義され、DERでエンコードされる」という知識があると、技術的な深い理解を示せます。

学んだ知識を定着させよう

ここまでの内容が理解できたか、簡単なクイズで確認してみましょう。

【演習】X.509デジタル証明書構造と検証（全10問）

まとめ：デジタル証明書はインターネットの信頼の基盤

本記事では、情報処理安全確保支援士試験で重要なデジタル証明書（X.509）について、その内部構造と検証プロセスを詳細に解説しました。

重要ポイントの再確認

X.509 v3は国際標準規格であり、主体者情報と公開鍵をバインドし、CAがデジタル署名を付与したデータセット
証明書の構造は、基本フィールド（バージョン、シリアル、発行者、有効期間、主体者、公開鍵など）と拡張領域（SAN、Key Usage、Basic Constraintsなど）から構成される
SAN（Subject Alternative Name）は現代のドメイン検証において最重要の拡張フィールドであり、ブラウザはCNではなくSANを優先的に確認する
検証プロセスは、信頼の連鎖構築、デジタル署名の暗号学的検証、有効期間確認、失効状態確認、ドメイン名一致確認の5ステップで構成される
証明書の種類（DV、OV、EV）は技術仕様ではなく審査レベルの違いであり、暗号強度は同等だが運営者の実在性保証レベルが異なる

実務への応用

デジタル証明書は単なる「設定ファイル」ではありません。暗号技術と信頼モデル（PKI）が凝縮された、インターネットセキュリティの根幹を支える仕組みです。

サーバー管理者として証明書をインストールする際、セキュリティエンジニアとしてログを解析する際、本記事で解説した構造を理解していれば、トラブルの原因を論理的に特定できます。

「証明書エラーが発生した」→有効期限切れ? ルート証明書未登録? ドメイン名不一致? SANの設定ミス?
「MITM攻撃を防ぐために証明書がどう機能するか」→偽の公開鍵へのすり替えを、CAの署名検証で検知

SC試験対策

午後問題では、証明書検証のどのステップで失敗したかを推論させる問題や、PKI構成における脆弱性を指摘させる問題が出題されます。

「なんとなく安全」ではなく「なぜ安全と言えるのか」を説明できること
秘密鍵を持つCAが署名し、その署名を数学的に検証できたから信頼できる、という論理を理解すること
証明書チェーン、失効確認、ドメイン検証のそれぞれが独立した検証項目であることを意識すること

これらの理解があれば、試験の記述式問題で的確な回答を構築できます。

次回予告

今回少し触れた「失効確認」について、次回はさらに詳しく掘り下げます。

CRL（Certificate Revocation List）とOCSP（Online Certificate Status Protocol）の技術的詳細
それぞれの利点と欠点
OCSP Staplingによる性能改善
CRLiteやOCSP Must-Stapleなどの最新技術

証明書の世界は奥深く、セキュリティ技術の最前線が凝縮されています。一つ一つの仕組みを確実に理解し、合格への道を着実に進んでいきましょう。