X.509証明書の構造

X.509証明書は、公開鍵を身元情報に結び付ける標準化されたデジタル文書です。X.509標準（RFC 5280で定義）は、世界中のデジタル証明書で使用される形式、フィールド、拡張機能を規定しています。TLS/HTTPS証明書、S/MIMEメール証明書、コード署名証明書、クライアント認証証明書は、すべてX.509形式に従います。X.509証明書の構造を理解すると、証明書情報の読み取り、証明書エラーの診断、証明書の導入と検証に関する適切な判断ができるようになります。

X.509証明書の最初のフィールドでは、基本的な識別情報を定義します。Version：X.509 v3が現在の標準です（v3で拡張機能が追加されました）。Serial Number：発行元CAが割り当てる一意の整数で、この証明書を識別します。CRL（失効リスト）で個々の証明書を失効させる際に使用されます。Signature Algorithm：CAが証明書への署名に使用したアルゴリズムを指定します（例：sha256WithRSAEncryptionやecdsa-with-SHA256）。このフィールドはTBSCertificateと外側の署名ラッパーに1回ずつ現れ、両者は一致していなければなりません。

証明書に関係する当事者を定義する、特に重要なフィールドが2つあります。Issuerフィールドは、証明書に署名したCAを識別します（例：CN=DigiCert Global CA G2, O=DigiCert Inc, C=US）。Subjectフィールドは、証明書の発行対象となったエンティティを識別します（例：CN=*.example.com, O=Example Corp, C=US）。TLS証明書では、SubjectのCommon Name（CN）またはSubject Alternative Name（SAN）拡張機能によって、その証明書が有効なドメイン名を指定します。ブラウザーは、要求されたホスト名をこれらのフィールドと照合します。

有効期間は、証明書が有効になる期間を定義します。2つのタイムスタンプで構成されます。notBefore（この日時より前は証明書がまだ有効ではありません）とnotAfter（この日時を過ぎると証明書は期限切れになります）です。TLSクライアントは、現在時刻がこの期間内にあることを検証します。有効期間外の証明書が提示されると、ブラウザーで証明書エラーが発生するため、更新が必要です。秘密鍵が発行から有効期限までの間に侵害された場合の影響を抑えるため、現在のベストプラクティスでは、短期間だけ有効な証明書（Let's Encryptのように90日間）を発行します。

証明書の中核となる情報はSubject Public Key Infoフィールドです。このフィールドには、認証対象となる公開鍵と、その公開鍵で使用されるアルゴリズムが含まれます。RSA証明書の場合、このフィールドにはRSA公開鍵の法と指数、およびビット長（2048、4096）が含まれます。ECC証明書の場合は、曲線名（例：prime256v1）と公開鍵ポイントが含まれます。CAがこの鍵ペアを生成するわけではありません。証明書の申請者が自身の鍵ペアを生成し、Certificate Signing Request（CSR）には公開鍵だけを含めて送信します。

X.509 v3では、証明書の機能を大幅に拡張する拡張機能が導入されました。拡張機能には、critical（この拡張機能を処理できないクライアントは証明書を拒否しなければなりません）とnon-critical（理解できなくても無視できます）があります。主な拡張機能には、次のものがあります。Subject Alternative Name（SAN）：証明書の対象となる追加のドメイン名またはIPアドレス、Key Usage：鍵で実行できる操作（デジタル署名、鍵暗号化）を制限、Extended Key Usage：用途（TLSサーバー認証、クライアント認証、コード署名）をさらに制限、Basic Constraints：SubjectがCAであるかどうかを示します。

従来は、Subjectの識別フィールドにあるCommon Name（CN）フィールドで、主要なドメイン名を指定していました。現在の証明書では、代わりにSubject Alternative Name（SAN）を使用します。ブラウザーがCNベースの照合（RFC 2818）を廃止し、SANを優先するようになったためです。SANを使用すると、1つの証明書で複数のドメイン（マルチSAN証明書）や、あるドメインのすべてのサブドメイン（ワイルドカード証明書：*.example.com）を対象にできます。SANのワイルドカードが対象にできるのは1階層だけです。*.example.comはwww.example.comを対象にできますが、sub.www.example.comは対象になりません。

2つの重要な拡張機能により、クライアントは証明書の有効期限前に、その証明書が失効しているかどうかを確認する方法を把握できます。CRL Distribution Points（CDP）：CAのCertificate Revocation ListをダウンロードできるURLを含みます。Authority Information Access（AIA）：リアルタイムで失効確認を行うCAのOCSP（Online Certificate Status Protocol）レスポンダーのURLを含みます。CRLは大きなファイルになる可能性があるため、現在のクライアントはCRLのダウンロードよりもOCSPを優先します。OCSP応答に付けられたCAのデジタル署名により、クライアントは真正な失効ステータス情報を受け取れます。

X.509証明書には、実際の運用で遭遇する複数のエンコード形式があります。PEM（Privacy Enhanced Mail）：base64でエンコードしたDERを-----BEGIN CERTIFICATE-----ヘッダーで囲んだ形式です。人間が読みやすく、Linux/Apache/nginxで使用されます。DER（Distinguished Encoding Rules）：バイナリ形式です。Javaアプリケーションや一部のWindows環境で使用されます。PFX/PKCS#12：証明書、証明書チェーン、秘密鍵を1つのパスワード保護ファイルにまとめるコンテナ形式です。Windows IISや、秘密鍵付きで証明書をエクスポートする場合に使用されます。P7B/PKCS#7：証明書チェーンだけを含み、秘密鍵は含まない形式です。Windowsの証明書ストアで使用されます。

Certificate Transparency（CT）は、CAに対して、発行したすべての証明書を公開監査可能なログへ記録するよう求める仕組みです。これにより、誰でも自分のドメインに対して不正に発行された証明書を監視できます。ChromeとSafariでは、TLS証明書をCTログに登録することが必須です。SCT（Signed Certificate Timestamp）はログへの登録を証明するもので、証明書に埋め込むか、TLS拡張機能を介して提供します。CTログにより、誤発行は速やかに発見できます。CAが自分のドメイン用に誤って証明書を発行した場合、攻撃者に悪用される前にcrt.shなどのログで確認できます。

X.509証明書の最後の構成要素は、CAのデジタル署名です。CAは証明書データ（TBSCertificate）全体をハッシュ化し、そのハッシュに自身の秘密鍵で署名します。この署名によって証明書が信頼できるものになります。誰でもCAの公開鍵（CA自身の証明書に記載されています）を使って署名を検証できます。使用された署名アルゴリズムは、署名フィールドに記載されているものと、証明書の前半で指定されているものが一致していなければなりません。署名後に証明書が変更されると署名は無効になり、証明書の完全性が保証されます。

このレッスンで扱ったCompTIA Security+（SY0-701）の概念について、理解度を確認します。

このレッスンでは、X.509証明書にバージョン、シリアル番号、Issuer、Subject、有効期間、公開鍵、およびv3拡張機能が含まれること、SAN拡張機能が証明書の対象となるホスト名を制御すること、CDPおよびAIA拡張機能が失効確認エンドポイントを示すこと、そしてCTログが証明書発行の公開監査証跡を提供することを学びました。次は証明書のライフサイクルと失効について学びます。