509 の

暗号化技術において、X.509は公開鍵証明書の形式を定義する国際電気通信連合（ITU）標準です。^{[1] X.509証明書は、} Webを閲覧するための安全なプロトコルであるHTTPS ^[2]の基礎となるTLS/SSLを含む多くのインターネットプロトコルで使用されています。また、電子署名などのオフラインアプリケーションでも使用されています。^[3]

X.509 証明書は、デジタル署名を使用して ID を公開キーにバインドします。証明書には、ID (ホスト名、組織、または個人) と公開キー ( RSA、DSA、ECDSA、ed25519など) が含まれており、証明機関によって署名されているか、自己署名されています。証明書が信頼できる証明機関によって署名されているか、他の手段で検証されている場合、その証明書の所有者は、証明書に含まれる公開キーを使用して別の当事者と安全な通信を確立したり、対応する秘密キーでデジタル署名されたドキュメントを検証したりできます。

X.509 では、署名機関によって無効と判断された証明書に関する情報を配布する手段である証明書失効リストと、中間 CA 証明書によって証明書に署名し、その中間 CA 証明書がさらに他の証明書によって署名され、最終的に信頼アンカーに到達することを可能にする証明書パス検証アルゴリズムも定義されています。

X.509 は、ITU の「標準化部門」( ITU-TのSG17 ) の ITU-T 研究グループ 17 によって定義され、別の ITU-T 標準 である抽象構文記法 1 (ASN.1)に基づいています。

X.509 は 1988 年 7 月 3 日に最初に発行され、X.500標準と連携して開始されました。その最初のタスクは、ユーザーに情報リソースへの安全なアクセスを提供し、暗号化による中間者攻撃を回避することでした。証明書を発行するための認証局(CA)の厳格な階層システムを想定しています。これは、 PGPなどの信頼のウェブモデルとは対照的です。PGP では、特別な CA だけでなく誰でも署名して、他のキー証明書の有効性を証明できます。

X.509 バージョン 3 には、ブリッジやメッシュなどの他のトポロジーをサポートする柔軟性が含まれています。^[2]これは、ピアツーピアのOpenPGPのような信頼のウェブで使用できますが^[要出典] 、 2004 年の時点ではそのように使用されることはほとんどありませんでした。X.500 システムは、国家 ID 情報共有条約の履行目的で^{[アップデート]}主権国家によってのみ実装されており^{[どの国家? ] 、} IETFの公開鍵インフラストラクチャ (X.509) (PKIX) ワーキング グループは、この標準をインターネットのより柔軟な組織に適合させました。実際、X.509 証明書という用語は通常、 RFC 5280 で指定されている、一般に公開鍵インフラストラクチャ (X.509) の略称である PKIX と呼ばれる、X.509 v3 証明書標準のIETF PKIX 証明書とCRLプロファイルを指します。^[4]

公開鍵基盤(PKI) と X.509 証明書の初期の課題は、よく知られている「どのディレクトリか」問題でした。グローバル X.500 ディレクトリが実現しなかったため、クライアントは欠落している中間証明書をどこで取得すればよいか分からないという問題です。この問題は、すべての中間証明書をリクエストに含めることで軽減されました。たとえば、初期の Web サーバーは、Web サーバーの証明書のみをクライアントに送信していました。中間 CA 証明書が不足していたり​​、中間 CA 証明書を見つける場所が不明なクライアントは、CA からサーバーの証明書への有効なパスを構築できませんでした。この問題を回避するために、Web サーバーは現在、Web サーバーの証明書とともにすべての中間証明書を送信しています。^[5]

PKIX は IETF またはインターネットの PKI 標準を指しますが、異なるポリシーを持つ PKI は他にも多数あります。たとえば、米国政府には独自のポリシーを持つ PKI があり、CA/ブラウザ フォーラムにも独自のポリシーを持つ PKI があります。米国政府の PKI は 2500 ページを超える大冊です。組織の PKI が IETF または CA/ブラウザ フォーラムのものと大きく異なる場合、その組織はWeb ブラウザ、cURL、Wgetなどの一般的なツールとの相互運用性を失うリスクがあります。たとえば、PKI に月曜日にのみ証明書を発行するというポリシーがある場合、cURL や Wget などの一般的なツールはそのポリシーを強制せず、火曜日に発行された証明書を許可します。^[5]

X.509 証明書は、デジタル署名を使用して ID を公開キーにバインドします。X.509 システムには、2 種類の証明書があります。1 つ目は CA 証明書です。2 つ目はエンド エンティティ証明書です。CA 証明書は他の証明書を発行できます。最上位の自己署名 CA 証明書は、ルート CA 証明書と呼ばれることもあります。その他の CA 証明書は、中間 CA 証明書または下位 CA 証明書と呼ばれます。エンド エンティティ証明書は、個人、組織、企業などのユーザーを識別します。エンド エンティティ証明書は他の証明書を発行できません。エンド エンティティ証明書は、その下に他の証明書を発行できないため、リーフ証明書と呼ばれることもあります。

署名付き証明書を希望する組織は、証明書署名要求 (CSR)、簡易証明書登録プロトコル (SCEP)、証明書管理プロトコル (CMP)などのプロトコルを使用して CA に証明書を要求します。組織は最初にキー ペアを生成し、秘密キーを秘密に保持してそれを使用して CSR に署名します。CSR には、申請者を識別する情報と、CSR の署名を確認するために使用される申請者の公開キー、および個人、組織、または企業に固有の識別名(DN) が含まれます。CSR には、証明機関が要求するその他の資格情報または身元証明が添付される場合があります。

CSR は登録機関 (RA) を使用して検証され、その後、認証機関は公開キーを特定の識別名に結び付ける証明書を発行します。登録機関と認証機関の役割は、通常、詐欺のリスクを軽減するために職務の分離に基づく別々のビジネス ユニットです。

組織の信頼されたルート証明書は、全従業員に配布して、会社の PKI システムを使用できるようにすることができます。Internet Explorer、Firefox、Opera、Safari、Chromeなどのブラウザには、事前に設定されたルート証明書のセットがプリインストールされているため、主要な認証局のSSL証明書はすぐに機能します。つまり、ブラウザの開発者が、ブラウザのユーザーにとってどの CA が信頼できるサードパーティであるかを決定します。たとえば、Firefox は、含まれる CA のリストを含む CSV および/または HTML ファイルを提供します。^[8]

X.509 および RFC 5280 には、証明書失効リスト(CRL) の実装 に関する標準も含まれています。証明書の有効性を確認するためのIETF承認の別の方法は、オンライン証明書ステータス プロトコル(OCSP) です。Firefox 3.0 では、少なくともVista以降のバージョンのWindowsと同様に、OCSP チェックがデフォルトで有効になっています。^[9]

標準によって想定される構造は、形式言語である抽象構文記法 1 (ASN.1) で表現されます。

X.509 v3デジタル証明書の構造は次のとおりです。

• 証明書
  • バージョン番号
  • シリアルナンバー
  • 署名アルゴリズムID
  • 発行者名
  • 有効期間
    • これまでは
    • その後ではない
  • 件名
  • サブジェクト公開鍵情報
    • 公開鍵アルゴリズム
    • サブジェクト公開鍵
  • 発行者固有識別子（オプション）
  • サブジェクト固有識別子（オプション）
  • 拡張機能（オプション）
    • ...
• 証明書署名アルゴリズム
• 証明書の署名

Extensions フィールドは、存在する場合、1 つ以上の証明書拡張機能のシーケンスです。^{[10] : §4.1.2.9: 拡張機能}各拡張機能には、オブジェクト識別子 (OID)として表現される独自の一意の ID があります。これは、クリティカルまたは非クリティカルのいずれかの指示を伴う値の集合です。証明書を使用するシステムは、認識できないクリティカルな拡張機能、または処理できない情報を含むクリティカルな拡張機能に遭遇した場合、証明書を拒否する必要があります。非クリティカルな拡張機能は、認識されない場合は無視できますが、認識された場合は処理する必要があります。^{[10] : §4.2: 証明書の拡張機能}

バージョン 1 の構造はRFC  1422 に記載されています。

X.520 ディレクトリ: 選択された属性タイプの推奨事項で指定されている発行者およびサブジェクトの一意の識別子の内部形式。

ITU-T は、発行者とサブジェクトの一意の識別子をバージョン 2 で導入し、発行者またはサブジェクト名を一定期間後に再利用できるようにしました。再利用の例としては、CA が破産し、その名前が国の公開リストから削除された場合が挙げられます。一定期間後に、最初の CA とは関係がなくても、同じ名前の別の CA が登録される可能性があります。ただし、IETF は発行者とサブジェクト名を再利用しないことを推奨しています。そのため、バージョン 2 はインターネットで広く採用されていません。^{[引用が必要]}

拡張機能はバージョン 3 で導入されました。CA は拡張機能を使用して、特定の目的 (デジタル オブジェクトの署名のみなど) に対してのみ証明書を発行できます。

すべてのバージョンにおいて、シリアル番号は特定の CA によって発行された証明書ごとに一意である必要があります ( RFC  5280 に記載されているとおり)。

RFC  5280 (およびその前身) では、証明書の使用方法を示す証明書拡張機能がいくつか定義されています。そのほとんどはjoint-iso-ccitt(2) ds(5) id-ce(29)OID からのアークです。セクション 4.2.1 で定義されている最も一般的な拡張機能のいくつかを次に示します。

• 基本制約、{ id-ce 19 }[ ^{10] ：§4.2.1.9は、}証明書がCA証明書であるかどうか、および他の証明書を認証または発行できるかどうかを示すために使用されます。制約はクリティカルとしてマークできます。制約がクリティカルとしてマークされている場合、エージェントは制約を理解していない場合、証明書の処理に失敗しなければなりません。エージェントは、理解していない非クリティカルな制約の処理を続行できます。
• 鍵の使用法{ id-ce 15 }、^{[10] ：§4.2.1.3は}、証明書に含まれる公開鍵を使用して実行できる暗号化操作を指定するビットマップを提供します。たとえば、鍵は署名には使用すべきだが暗号化には使用すべきではないことを示すことができます。
• 拡張キー使用法{ id-ce 37 }、^{[10] ：§4.2.1.12}は、通常、リーフ証明書で、証明書に含まれる公開キーの目的を示すために使用されます。これにはOIDのリストが含まれており、それぞれが許可された用途を示しています。たとえば、は、{ id-pkix 3 1 }キーがTLSまたはSSL接続のサーバー側で使用できることを示します。{ id-pkix 3 4 }キーが電子メールのセキュリティ保護に使用できることを示します。

一般的に、RFC  5280 を使用する場合、証明書にその使用を制限する複数の拡張機能がある場合、特定の使用が適切であるためにはすべての制限を満たす必要があります。RFC では、keyUsage と extendedKeyUsage の両方を含む証明書の具体的な例を示しています。この場合、両方を処理する必要があり、両方の拡張機能が証明書の使用法を指定する際に一貫している場合にのみ証明書を使用できます。たとえば、NSS は両方の拡張機能を使用して証明書の使用法を指定します。^[11]

CA/ブラウザ フォーラムの PKI に基づいて運営されている認証局は、さまざまなレベルの検証を伴う証明書を発行します。検証が異なると、証明書が想定どおりのものであるという保証のレベルも異なります。たとえば、Web サーバーは、ドメイン検証 (DV)と呼ばれる電子メールを使用して、最低レベルの保証で検証できます。または、Web サーバーは、拡張検証 (EV)と呼ばれるより詳細な方法を使用して、より高いレベルの保証で検証できます。

実際には、DV 証明書は、example.comに送信された電子メールに誰かが返信した後にwebmaster@example.com、 のようなドメインに対して証明書が発行されたことを意味します。EV 証明書は、 のようなドメインに対して証明書が発行されexample.com、Example, LLC のような会社がドメインの所有者であり、所有者が定款によって確認されたことを意味します。

拡張検証では追加のセキュリティ制御は追加されないため、EV 証明書を使用したセキュリティ チャネル設定は、DV などの異なるレベルの検証を使用したチャネル設定よりも「強力」ではありません。

拡張検証は、X.509 v3 拡張機能を使用して証明書で通知されます。各 CA は、異なるオブジェクト識別子 (OID) を使用して拡張検証をアサートします。拡張検証を示す単一の OID は存在しないため、ユーザー エージェントのプログラミングが複雑になります。各ユーザー エージェントには、拡張検証を示す OID のリストが必要です。

CA/ブラウザ フォーラムの PKI は拡張検証を認識しており、多くのブラウザは、サイトが EV 証明書を提供していることを示す視覚的なフィードバックをユーザーに提供します。インターネットの PKI (PKIX) などの他の PKI では、拡張検証は特に重視されていません。cURL や Wget などの PKIX ポリシーを使用するツールは、EV 証明書を他の証明書と同様に扱います。

セキュリティ専門家のピーター・ガットマンは、CA が EV 証明書を作成した理由は、競争の激化により利益が減った後に利益レベルを回復するためだと述べています。競争の激化中、CA は消費者に証明書を購入させるために価格を下げました。その結果、利益は減り、CA は証明書の保証がほとんどなくなるまで検証レベルを下げました。^[5]

X.509 証明書には、一般的に使用されるファイル名拡張子がいくつかあります。これらの拡張子の一部は、秘密鍵などの他のデータにも使用されます。

• .pem– (プライバシー強化電子メール) Base64でエンコードされたDER証明書-----BEGIN CERTIFICATE-----。-----END CERTIFICATE-----
• .cer、、– 通常はバイナリDER.crt形式ですが、Base64 でエンコードされた証明書も一般的です (上記を参照).der.pem
• .p8、、.p8e– PKCS#8.pk8で指定されているエクスポートされた秘密キー。 で始まる DER または PEM 形式である場合があります。暗号化されたキーは で始まり、拡張子が である場合があります。-----BEGIN PRIVATE KEY----------BEGIN ENCRYPTED PRIVATE KEY-----.p8e
• .p10, .csr– PKCS#10証明書署名要求(CSR)。PEM 形式では で始まります-----BEGIN CERTIFICATE REQUEST-----。これらは、証明機関 (CA) に提出するために生成されます。これには、要求された証明書の共通名 (/CN)、サブジェクト、組織、州、国、および署名する証明書の公開鍵などの重要な詳細が含まれます。これらは CA によって署名され、証明書が返されます。返される証明書は公開証明書(公開鍵は含まれますが秘密鍵は含まれません) で、それ自体の形式はいくつかありますが、通常は です.p7r。^[12]
• .p7r– CSR に対するPKCS#7応答。新しく署名された証明書と CA 独自の証明書が含まれます。
• .p7s– PKCS#7デジタル署名。元の署名されたファイルまたはメッセージが含まれる場合があります。電子メールの署名にS/MIMEで使用されます。RFC 2311 で定義されています。
• .p7m– PKCS#7 (SignedData、EnvelopedData) メッセージ (例: 暗号化された ("エンベロープ") ファイル、メッセージ、または MIME 電子メール レター)。RFC 2311 で定義されています。
• .p7c– PKCS#7 は、署名するデータがない、SignedData「証明書のみ」の構造を縮退しました。RFC 2311 で定義されています。
• .p7b, .keystore– PKCS#7 SignedData 構造、データなし、証明書バンドルおよび/またはCRL (まれ) のみ、秘密キーなし。で始まるDER形式、BER-----BEGIN PKCS7----- 、または PEM を使用します。Windows が証明書交換に使用する形式です。Java でサポートされていますが、.keystore代わりに が拡張子として使用されることがよくあります。スタイル証明書とは異なり.pem、この形式では、証明パス証明書を含める方法が定義されています。
• .p12、、– PKCS#12.pfxでは、証明書 (公開) と秘密キー (パスワードで保護) が 1 つのファイルに含まれている場合があります。– Personal Information eXchange PFX は、PKCS#12 の前身です (通常、 IISで生成された PFX ファイルなど、PKCS#12 形式のデータが含まれています)。.pkcs12.pfx
• .crl–証明書失効リスト(CRL)。証明機関は、有効期限が切れる前に証明書の認証を取り消す方法としてこれを作成します。

PKCS#7 は、データの署名または暗号化 (正式には「エンベロープ」と呼ばれます) の標準です。署名されたデータを検証するには証明書が必要なので、SignedData 構造に証明書を含めることができます。

証明書チェーン( RFC 5280 セクション 3.2で定義されている「証明書パス」の同等の概念を参照) は、証明書のリスト (通常はエンド エンティティ証明書で始まる) と、それに続く 1 つ以上のCA証明書 (通常は最後の証明書が自己署名証明書) で構成され、次のプロパティを持ちます。

1. 各証明書の発行者（最後のものを除く）は、リスト内の次の証明書の件名と一致します。
2. 各証明書（最後のものを除く）は、チェーン内の次の証明書に対応する秘密鍵によって署名されます（つまり、1 つの証明書の署名は、次の証明書に含まれる公開鍵を使用して検証できます）。
3. リストの最後の証明書はトラストアンカーです。これは、信頼できる手順で配信されたため信頼できる証明書です。

証明書チェーンは、ターゲット証明書 (チェーンの最初の証明書) に含まれる公開キー (PK) と、それに含まれるその他のデータが、そのサブジェクトに実際に属しているかどうかを確認するために使用されます。これを確認するには、ターゲット証明書の署名を次の証明書に含まれる PK を使用して検証し、その署名を次の証明書を使用して検証するという手順を、チェーンの最後の証明書に到達するまで繰り返します。最後の証明書は信頼アンカーであるため、そこに到達すると、ターゲット証明書が信頼できることが証明されます。

前の段落の説明は、RFC 5280 セクション 6で定義されている証明書パス検証プロセスの簡略化されたビューであり、証明書の有効期限の確認、 CRL の検索など  の追加のチェックが含まれます。

証明書チェーンの構築と検証方法を検討する際、具体的な証明書が、非常に異なる証明書チェーン（すべて有効）の一部になる可能性があることに注意することが重要です。これは、同じサブジェクトと公開鍵に対して複数の CA 証明書を生成できるが、異なる秘密鍵（異なる CA から、または同じ CA からの異なる秘密鍵）で署名できるためです。したがって、単一の X.509 証明書には 1 つの発行者と 1 つの CA 署名しか含めることができませんが、複数の証明書に有効にリンクして、完全に異なる証明書チェーンを構築することができます。これは、PKI と他のアプリケーション間の相互認証にとって重要です。^[13] 次の例を参照してください。

これらの図では、

• 各ボックスは証明書を表し、その件名は太字で表示されます。
• A → B は、「A は B によって署名されている」(より正確には、「A は B に含まれる公開鍵に対応する秘密鍵によって署名されている」) ことを意味します。
• 同じ色（白/透明ではない）の証明書には同じ公開鍵が含まれています

PKI 2 に存在するユーザー証明書 (「ユーザー 2」など) が PKI 1 によって信頼されるようにするために、CA1 は CA2 の公開鍵を含む証明書 (cert2.1) を生成します。^[14] これで、「cert2」と「cert2.1」(緑色) の両方が同じサブジェクトと公開鍵を持つため、cert2.2 (ユーザー 2) には「cert2.2 → cert2」と「cert2.2 → cert2.1 → cert1」という 2 つの有効なチェーンが存在します。

同様に、CA2 は CA1 の公開キーを含む証明書 (cert1.1) を生成して、PKI 1 に存在するユーザー証明書 (「ユーザー 1」など) が PKI 2 によって信頼されるようにすることができます。

認証パス構築の理解(PDF)。PKI フォーラム。2002 年 9 月。古い署名キー ペアから新しい署名キー ペアへのスムーズな移行を可能にするために、CA は、新しい秘密署名キーで署名された古い公開キーを含む証明書と、古い秘密署名キーで署名された新しい公開キーを含む証明書を発行する必要があります。これらの証明書は両方とも自己発行されますが、どちらも自己署名ではありません。これらは、2 つの自己署名証明書 (1 つは古い、もう 1 つは新しい) に加えて発行されることに注意してください。

cert1 と cert3 の両方に同じ公開鍵 (古いもの) が含まれているため、cert5 には 2 つの有効な証明書チェーン (「cert5 → cert1」と「cert5 → cert3 → cert2」) があり、cert6 についても同様です。これにより、新しい CA キーへの移行中に、新しいルート CA 証明書または古い証明書のいずれかを信頼アンカーとして持つ当事者は、古いユーザー証明書 (cert5 など) と新しい証明書 (cert6 など) を区別なく信頼できます。^[15]

これは、過去に wikipedia.org および他のいくつかの Wikipedia Web サイトで使用された、デコードされた X.509 証明書の例です。発行者フィールドに記載されているように、これはGlobalSignによって発行されました。その件名フィールドには組織としての Wikipedia が記述され、DNS の件名代替名 (SAN) フィールドには、使用できるホスト名が記述されています。件名公開鍵情報フィールドにはECDSA公開鍵が含まれ、下部の署名は GlobalSign のRSA秘密鍵によって生成されました。(これらの例の署名は切り詰められています。)

証明書：
   データ：
       バージョン: 3 (0x2)
       シリアルナンバー：
           10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6
       署名アルゴリズム: sha256WithRSAEncryption
       発行者: C=BE、O=GlobalSign nv-sa、CN=GlobalSign 組織検証 CA - SHA256 - G2
       有効
           2016 年 11 月 21 日 08:00:00 GMT 以前
           それ以降: 2017年11月22日 07:59:59 GMT
       件名: C=米国、ST=カリフォルニア、L=サンフランシスコ、O=ウィキメディア財団、CN=*.wikipedia.org
       サブジェクト公開鍵情報:
           公開鍵アルゴリズム: id-ecPublicKey
               公開鍵: (256 ビット)
           パブ：
                   00:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:
                   af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:
                   9d:3b:ef
               ASN1 OID: prime256v1
               NIST 曲線: P-256
       X509v3 拡張:
           X509v3 キーの使用法: 重要
               デジタル署名、鍵合意
           権限情報アクセス:
               CA 発行者 - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
               OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2
           X509v3 証明書ポリシー:
               ポリシー: 1.3.6.1.4.1.4146.1.20
                 プライバシーポリシー: https://www.globalsign.com/repository/
               ポリシー: 2.23.140.1.2.2
           X509v3 基本制約:
               CA:偽
           X509v3 CRL配布ポイント:
               フルネーム：
                 URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl
           X509v3 サブジェクト別名:
               DNS:*.wikipedia.org、DNS:*.m.mediawiki.org、DNS:*.m.wikibooks.org、DNS:*.m.wikidata.org、DNS:*.m.wikimedia.org、DNS: *.m.wikimediafoundation.org、DNS:*.m.wikinews.org、DNS:*.m.wikipedia.org、DNS:*.m.wikiquote.org、DNS:*.m.wikisource.org、 DNS:*.m.wikiversity.org、DNS:*.m.wikivoyage.org、DNS:*.m.wiktionary.org、DNS:*.mediawiki.org、DNS:*.planet.wikimedia.org、DNS: *.wi​​kibooks.org、DNS:*.wikidata.org、DNS:*.wikimedia.org、DNS:*.wikimediafoundation.org、DNS:*.wikinews.org、DNS:*.wikiquote.org、 DNS:*.wikisource.org、 DNS:*.wikiversity.org、DNS:*.wikivoyage.org、DNS:*.wiktionary.org、DNS:*.wmfusercontent.org、DNS:*.zero.wikipedia.org、DNS:mediawiki.org、DNS: w.wiki、DNS:wikibooks.org、DNS:wikidata.org、DNS:wikimedia.org、DNS:wikimediafoundation.org、DNS:wikinews.org、DNS:wikiquote.org、 DNS:wikisource.org、DNS:wikiversity.org、DNS:wikivoyage.org、DNS:wiktionary.org、DNS:wmfusercontent.org、DNS:wikipedia.org
           X509v3 拡張キー使用法:
               TLS Web サーバー認証、TLS Web クライアント認証
           X509v3 サブジェクトキー識別子:
               28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36
           X509v3 権限キー識別子:
               キーID:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

   署名アルゴリズム: sha256WithRSAEncryption
        8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35:
        ...

このエンド エンティティ証明書を検証するには、発行者と認証局のキー識別子に一致する中間証明書が必要です。

TLS 接続では、適切に構成されたサーバーがハンドシェイクの一部として中間証明書を提供します。ただし、エンドエンティティ証明書から「CA 発行者」URL を取得して中間証明書を取得することもできます。

これは、証明機関に属する中間証明書の例です。この証明書は、上記のエンド エンティティ証明書に署名し、以下のルート証明書によって署名されました。この中間証明書の subject フィールドは、署名したエンド エンティティ証明書の issuer フィールドと一致していることに注意してください。また、中間証明書の「subject key identifier」フィールドは、エンド エンティティ証明書の「authority key identifier」フィールドと一致しています。

証明書：
    データ：
        バージョン: 3 (0x2)
        シリアルナンバー：
            04:00:00:00:00:01:44:4e:f0:42:47
        署名アルゴリズム: sha256WithRSAEncryption
        発行者: C=BE、O=GlobalSign nv-sa、OU=ルート CA、CN=GlobalSign ルート CA
        有効
            2014 年 2 月 20 日 10:00:00 GMT 以前
            それ以降: 2月20日 10:00:00 2024 GMT
        件名: C=BE、O=GlobalSign nv-sa、CN=GlobalSign 組織検証 CA - SHA256 - G2
        サブジェクト公開鍵情報:
            公開鍵アルゴリズム: rsaEncryption
                公開鍵: (2048 ビット)
                係数:
                    00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e:
                    ...
                指数: 65537 (0x10001)
        X509v3 拡張:
            X509v3 キーの使用法: 重要
                証明書サイン、CRLサイン
            X509v3 基本制約: 重要
                CA:TRUE、パス長:0
            X509v3 サブジェクトキー識別子:
                96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
            X509v3 証明書ポリシー:
                ポリシー: X509v3 任意のポリシー
                  プライバシーポリシー: https://www.globalsign.com/repository/

            X509v3 CRL配布ポイント:

                フルネーム：
                  URI:http://crl.globalsign.net/root.crl

            権限情報アクセス:
                OCSP - URI:http://ocsp.globalsign.com/rootr1

            X509v3 権限キー識別子:
                キーID:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B

    署名アルゴリズム: sha256WithRSAEncryption
         46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8:
         ...

これは、証明機関を表す自己署名ルート証明書の例です。発行者フィールドとサブジェクト フィールドは同じで、署名は独自の公開キーで検証できます。信頼チェーンの検証はここで終了する必要があります。検証プログラムの信頼ストアにこのルート証明書がある場合、エンド エンティティ証明書は TLS 接続での使用に信頼できると見なすことができます。そうでない場合、エンド エンティティ証明書は信頼できないと見なします。

証明書: [16]
    データ：
        バージョン: 3 (0x2)
        シリアルナンバー：
            04:00:00:00:00:01:15:4b:5a:c3:94
        署名アルゴリズム: sha1WithRSAEncryption
        発行者: C=BE、O=GlobalSign nv-sa、OU=ルート CA、CN=GlobalSign ルート CA
        有効
            以前: 1998 年 9 月 1 日 12:00:00 GMT
            それ以降: 2028年1月28日 12:00:00 GMT
        件名: C=BE、O=GlobalSign nv-sa、OU=ルート CA、CN=GlobalSign ルート CA
        サブジェクト公開鍵情報:
            公開鍵アルゴリズム: rsaEncryption
                公開鍵: (2048 ビット)
                係数:
                    00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:
                    ...
                指数: 65537 (0x10001)
        X509v3 拡張:
            X509v3 キーの使用法: 重要
                証明書サイン、CRLサイン
            X509v3 基本制約: 重要
                CA:真実
            X509v3 サブジェクトキー識別子:
                60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B
    署名アルゴリズム: sha1WithRSAEncryption
         d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5:
         ...

PKIの問題については、ブルース・シュナイアー、ピーター・ガットマン、その他のセキュリティ専門家による多数の出版物がある。 ^{[17] [18] [19]}

• 無効な証明書のブロックリストの使用（CRLとOCSPを使用）
  • クライアントが CRL が利用できる場合にのみ証明書を信頼する場合、PKI を魅力的なものにしているオフライン機能が失われます。そのため、ほとんどのクライアントは CRL が利用できない場合でも証明書を信頼しますが、その場合、通信チャネルを制御する攻撃者は CRL を無効にすることができます。Google の Adam Langley は、ソフト フェイル CRL チェックは事故が起きない限り機能する安全ベルトのようなものだと述べています。^[20]
• CRLはサイズが大きく、配布パターンが複雑であるため、特に不適切な選択です。
• OCSPのセマンティクスが曖昧で、失効ステータスの履歴が欠如している。
• ルート証明書の失効については触れられていない。
• 集約の問題: アイデンティティクレーム (識別子による認証)、属性クレーム (検証済みの属性のバッグを送信)、およびポリシークレームが 1 つのコンテナーに結合されます。これにより、プライバシー、ポリシーマッピング、およびメンテナンスの問題が発生します。^{[説明が必要]}
• 委任問題: CA は、下位 CA が限定された名前空間または属性セットの外で証明書を発行することを技術的に制限することはできません。X.509 のこの機能は使用されていません。そのため、インターネット上には多数の CA が存在し、それらとそのポリシーを分類することは困難な作業です。組織内での権限の委任は、一般的なビジネス慣行のようにはまったく処理できません。^{[21] [検証失敗]}
• フェデレーションの問題: 下位 CA、ブリッジ CA、および相互署名の結果としての証明書チェーンは、検証を複雑にし、処理時間の点でコストがかかります。パス検証のセマンティクスはあいまいになる可能性があります。サードパーティの信頼できる当事者との階層が唯一のモデルです。これは、双方向の信頼関係がすでに確立されている場合には不便です。
• ホスト名に対して拡張認証（EV）証明書を発行しても、同じホスト名に対して有効なより低い認証レベルの証明書の発行を防ぐことはできません。つまり、EVのより高い認証レベルでは、中間者攻撃から保護されないということです。^[22]

• 証明書を購入する個人または組織は、多くの場合、最も安価な認証局を利用します。これに対応して、CA は価格を下げ、より高価な検証チェックを削除しました。これは、 Race to the Bottomとして知られています。Race to the Bottom は、 Extended Validation (EV)証明書によって部分的に対処されていますが、セキュリティ専門家の目から見た信頼の価値は低下しています。^[23] Peter Gutmannによると、EV 証明書は追加のセキュリティ制御を追加するものではありません。むしろ、EV 証明書は、CA がずっと提供すべきだったサービスに対してより高い料金を請求できるようにすることで、CA の利益を Race to the Bottom 以前のレベルに戻すだけです。^[5]
• 認証機関は、認証業務規定（CPS）において、ユーザーおよび依拠当事者に対するほぼすべての保証を否定しようとしています。たとえば、Apple Inc.はCPSで、「適用法で認められる範囲において、加入者契約書は、該当する場合、商品性や特定目的への適合性に関する保証を含め、Appleからの保証を否認します」と述べています。^[24]
• ピーター・ガットマンによれば、「ユーザーは定義されていない証明書要求プロトコルを使用して、存在しないディレクトリの不明瞭な場所に公開された証明書を取得し、それを失効させる実際の手段がない」^[19]
• 他のすべての企業と同様に、CA は運営する法域の管轄下にあり、顧客やユーザーの利益を侵害するよう法的に強制される可能性があります。諜報機関はまた、DigiNotarなどの CA の法外な侵害を通じて発行された偽の証明書を利用して、中間者攻撃を実行しました。^[要出典]もう 1 つの例は、2018 年に可決されたオランダの法律により、オランダ政府の CA の失効要求です。この法律により、オランダの諜報機関とセキュリティ サービスに新しい権限が与えられました^[25]

実装には、設計上の欠陥、バグ、標準の異なる解釈、異なる標準間の相互運用性の欠如などの問題があります。問題には次のようなものがあります。

• 多くの実装では失効チェックをオフにします。
  • 障害とみなされ、政策は施行されない
  • コード署名を含め、すべてのブラウザでデフォルトで有効にすると、おそらくインフラストラクチャがクラッシュするでしょう。
• DN は複雑で、あまり理解されていない (正規化の欠如、国際化の問題)
• rfc822Nameには2つの表記法がある
• 名前とポリシーの制約はほとんどサポートされていない
• キーの使用は無視され、リストの最初の証明書が使用されています
• カスタムOIDの適用は難しい
• 属性はクライアントがクラッシュする可能性があるため、クリティカルにしないでください。
• 属性の長さが指定されていない場合、製品固有の制限が発生します。
• X.509には実装上の誤りがあり、例えば、ヌル終端文字列^[26]を使用した偽のサブジェクト名や証明書へのコードインジェクション攻撃などが可能になる。
• 不正な^[27] 0x80パディングされたオブジェクト識別子のサブ識別子、間違った実装、またはクライアントのブラウザの整数オーバーフローを使用することで、攻撃者はCSRに未知の属性を含めることができます。CAはそれを署名しますが、クライアントはそれを誤って「CN」（OID = 2.5.4.3）と解釈します。Dan Kaminskyはこれを第26回Chaos Communication Congress「PKIのブラックOP」^{[28]で実証しました。}

デジタル署名システムは、安全な暗号化ハッシュ関数に依存して機能します。公開鍵インフラストラクチャが、もはや安全ではないハッシュ関数の使用を許可している場合、攻撃者はハッシュ関数の弱点を利用して証明書を偽造できます。具体的には、攻撃者がハッシュ衝突を生成できる場合、攻撃者は CA に無害な内容の証明書に署名させることができます。この場合、その内容のハッシュは、攻撃者が任意の値で作成した別の悪意のある証明書内容セットのハッシュと同一です。攻撃者は、その後、CA が提供した署名を悪意のある証明書内容に追加して、CA によって署名されたように見える悪意のある証明書を作成できます。悪意のある証明書内容は攻撃者によってのみ選択されるため、無害な証明書とは異なる有効期限やホスト名を持つことができます。悪意のある証明書には、「CA: true」フィールドが含まれることさえあり、これによりさらに信頼できる証明書を発行できるようになります。

• MD2 ベースの証明書は長い間使用されていましたが、プリイメージ攻撃に対して脆弱でした。ルート証明書にはすでに自己署名があったため、攻撃者はこの署名を使用して中間証明書として使用することができました。
• 2005年、Arjen LenstraとBenne de Wegerは、 MD5ハッシュ関数に対する衝突攻撃を使用して、「ハッシュ衝突を利用して、同一の署名を含み、公開鍵のみが異なる2つのX.509証明書を構築する方法」を実証しました。^[29]
• 2008年、アレクサンダー・ソティロフとマーク・スティーブンスはカオスコミュニケーション会議で、RapidSSLが依然としてMD5に基づくX.509証明書を発行しているという事実を悪用して、すべての一般的なブラウザで受け入れられる不正な証明機関を作成できる実用的な攻撃を発表しました。^[30]
• 2009年4月のEurocryptカンファレンス^{[31]で、マッコーリー大学のオーストラリアの研究者が「} SHA-1の自動差分パス検索」を発表しました。^[32]研究者は衝突の可能性を数桁増やす方法を導き出すことができました。^[33]
• 2017年2月、マーク・スティーブンス率いる研究者グループがSHA-1衝突を起こし、SHA-1の弱点を実証した。^[34]

ハッシュ衝突を利用してX.509署名を偽造するには、攻撃者が認証局が署名するデータを予測できる必要があります。これは、認証局が署名する証明書にランダムなコンポーネント（通常はシリアル番号）を生成することで、ある程度軽減できます。CA /ブラウザフォーラムは、2011年以来、基本要件セクション7.1でシリアル番号のエントロピーを要求しています。 ^[35]

2016年1月1日現在^{[アップデート]}、ベースライン要件ではSHA-1を使用した証明書の発行が禁止されています。2017年初頭現在^{[アップデート]}、Chrome ^[36]とFirefox ^{[37] は}SHA-1を使用した証明書を拒否しています。2017年5月現在、^{[アップデート]}Edge ^[38]とSafari ^[39]もSHA-1証明書を拒否しています。ブラウザ以外のX.509検証ツールはまだSHA-1証明書を拒否していません。^[40]

• PKCS7（暗号メッセージ構文標準 - PKI用の署名および/または暗号化されたメッセージの身元証明付き公開鍵）^[41]
• トランスポート層セキュリティ（TLS）とその前身であるSSL — インターネットの安全な通信のための暗号化プロトコル。^[42]
• オンライン証明書ステータスプロトコル（OCSP）^[43] / 証明書失効リスト（CRL）^[10]  — 証明書失効ステータスを確認するためのもの
• PKCS12（個人情報交換構文標準）—適切な公開鍵証明書とともに秘密鍵を保存するために使用される^[44]
• RFC  4158 — 認証パス構築 — アプリケーション内で X.509 公開鍵認証パスを構築するためのガイダンスと推奨事項 (つまり、CA 証明書を使用してエンド エンティティ証明書を検証する)

1995年、インターネット技術特別調査委員会は、米国国立標準技術研究所^[45]と共同で、公開鍵基盤(X.509)ワーキンググループを結成しました。2014年6月に終了したこのワーキンググループ^[46]は、一般に「PKIX」と呼ばれています。このワーキンググループは、 X.509の実際の使用と展開に関するRFCやその他の標準文書を作成しました。特に、インターネットプロトコルでX.509を使用する方法を定義したRFC  3280とその後継のRFC 5280を作成しました。

TLS/SSLとHTTPS は、 WiFi 認証用のS/MIME (Secure Multipurpose Internet Mail Extensions) やEAP-TLS方式と同様に、X.509 のRFC  5280 プロファイルを使用します。SMTP、POP、IMAP、LDAP、XMPP など、TLS を使用するプロトコルはすべて、本質的に X.509 を使用します。

IPsec はピアの認証にRFC 4945 プロファイルを使用できます 。

OpenCable セキュリティ仕様は、ケーブル業界で使用するための独自の X.509 プロファイルを定義します。

スマート カードやTPMなどのデバイスには、デバイス自体や所有者を識別するための証明書が含まれていることがよくあります。これらの証明書は X.509 形式です。

WS -Security標準では、TLSまたは独自の証明書プロファイルを介して認証を定義します。^[16]どちらの方法でもX.509が使用されます。

Microsoft Authenticodeコード署名システムは、X.509 を使用してコンピュータ プログラムの作成者を識別します。

OPC UA産業オートメーション通信規格では、X.509 が使用されます。

SSHは一般的にTrust On First Useセキュリティモデルを使用し、証明書を必要としません。ただし、一般的なOpenSSH実装では、独自の非X.509証明書形式に基づくCA署名IDモデルをサポートしています。^[47]

• 抽象構文記法 1
• 証明書ポリシー
• コードアクセスセキュリティ
• 通信セキュリティ
• 情報セキュリティ
• ISO/IEC JTC 1
• PKI リソース クエリ プロトコル
• 公開鍵暗号
• 公開鍵インフラストラクチャ
• タイムスタンププロトコル
• 信頼できるタイムスタンプ
• エドDSA

• ITU-TのX.509標準
• Peter Gutmann の記事:
  • PKIの概要
  • X.509 実装ノートとスタイルガイド
• 「RSA Labs の暗号に関する FAQ」。RSA Laboratories。2006 年 12 月 30 日時点のオリジナルよりアーカイブ。
• セキュアコードガイドライン Sun
• RFC 4158 - インターネット X.509 公開鍵インフラストラクチャ: 認証パスの構築
• RFC 5280 - インターネット X.509 公開鍵インフラストラクチャ証明書および証明書失効リスト (CRL) プロファイル
• CSRデコーダーと証明書デコーダー - エンコードされたCSRまたは証明書をデコードして検査するために使用できます。
• phpseclib: X.509 デコーダー - キーが X.509 の ASN.1 記述に対応する連想配列にデコードします
• デジタル証明書の理解 Microsoft TechNet