X.509 – 日本語百科事典辞書

X.509
では、暗号化、X.509はの形式を定義標準である公開鍵証明書を。 X.509証明書は、HTTPSの基礎となるTLS / SSL、 Webを閲覧するための安全なプロトコルなどの多くのインターネットプロトコルで使用されています。また、電子署名などのオフラインアプリケーションでも使用されます。X.509証明書には、公開鍵とID（ホスト名、組織、または個人）が含まれており、認証局によって署名されています。または自己署名。証明書が信頼できる認証局によって署名されているか、他の方法で検証されている場合、その証明書を保持している人は、証明書に含まれている公開鍵を使用して、他の当事者との安全な通信を確立したり、対応する秘密鍵によってデジタル署名されたドキュメントを検証したりできます。 X.509 情報技術-オープンシステム相互接続-ディレクトリ：公開鍵および属性証明書フレームワーク
状態
有効（推奨）
初版
1988年11月25日1.0 ; 32年前（1988-11-25）
最新バージョン
9.0 2019年10月14日; 22ヶ月前（2019-10-14）
組織 ITU-T 委員会
ITU-T研究グループ17
シリーズ基本基準 ASN.1 関連規格
ISO / IEC 9594-8：2020、X.500
ドメイン
暗号化
Webサイト
www .itu .int / rec / T-REC-X .509
X.509は、署名機関によって無効と見なされた証明書に関する情報を配布する手段である証明書失効リストと、証明書が中間CA証明書によって署名されることを可能にする証明書パス検証アルゴリズムも定義します。次に、他の証明書によって署名され、最終的にトラストアンカーに到達します。
X.509は、国際電気通信連合の「標準化セクター」（ITU-T）によってITU-T研究グループ17で定義されており、別のITU-T標準であるASN.1に基づいています。

コンテンツ
1 歴史と使用法
2 証明書
2.1 証明書の構造 2.2 証明書の特定の使用法を通知する拡張機能 2.3 証明書のファイル名拡張子
3 証明書チェーンと相互認証
3.1 例
3.1.1 例1：2つのPKI間のルート認証局（CA）レベルでの相互認証
3.1.2 例2：CA証明書の更新
4 X.509証明書のサンプル
4.1 エンドエンティティ証明書 4.2 中間証明書 4.3 ルート証明書
5 安全
5.1 アーキテクチャの弱点 5.2 認証局の問題 5.3 実装の問題 5.4 暗号化の弱点
5.4.1 暗号化の弱点の緩和
6 X.509のPKI標準
7 PKIXワーキンググループ
8 X.509証明書を使用する主要なプロトコルと標準
9 も参照してください
10 参考文献
11 外部リンク

歴史と使用法
X.509は、1988年7月3日に最初に発行され、X.500標準に関連して開始されました。その最初のタスクは、ユーザーに情報リソースへの安全なアクセスを提供し、暗号化攻撃«中間者攻撃»を回避することでした。これは、証明書を発行するための認証局（CA）の厳密な階層システムを前提としています。これは、（特別なCAだけでなく）誰でも署名して他の人の鍵証明書の有効性を証明できるPGPのようなWeb ofTrustモデルとは対照的です。X.509のバージョン3には、ブリッジやメッシュなどの他のトポロジをサポートする柔軟性が含まれています。ピアツーピアのOpenPGPのような信頼のウェブで使用できますが、2004年の時点ではそのように使用されることはめったにありませんでした。X.500システムは、主権国家によってのみ実装されています州のアイデンティティ情報共有条約の履行を目的としており、IETFの公開鍵インフラストラクチャ（X.509）（PKIX）ワーキンググループは、インターネットのより柔軟な組織に標準を適合させました。実際、X.509証明書という用語は通常、RFC 5280で指定されているX.509 v3証明書標準のIETFのPKIX証明書とCRLプロファイルを指し、一般にPKIX for Public Key Infrastructure（X.509）と呼ばれます。

証明書
X.509システムでは、署名付き証明書が必要な組織は、証明書署名要求（CSR）を介して証明書を要求します。
これを行うには、それが最初の生成鍵ペアを保ち、秘密鍵秘密をし、CSRに署名するためにそれを使用します。これには、申請者を識別する情報と、CSRの署名を検証するために使用される申請者の公開鍵（および証明書の対象となる識別名（DN））が含まれます。CSRには、認証局が必要とする他の資格情報またはIDの証明が付随している場合が
認証機関は、特定の公開鍵証明書発行結合識別名を。
組織の信頼されたルート証明書をすべての従業員に配布して、会社のPKIシステムを使用できるようにすることができます。 Internet Explorer、Firefox、Opera、Safari、Chromeなどのブラウザには、事前に定義されたルート証明書のセットがプリインストールされているため、主要な認証局からのSSL証明書が即座に機能します。実際、ブラウザの開発者は、ブラウザのユーザーにとってどのCAが信頼できるサードパーティであるかを判断します。たとえば、Firefoxは、含まれているCAのリストを含むCSVファイルやHTMLファイルを提供します。
X.509および
RFC 5280には、証明書のための標準規格が含ま失効リスト（CRL）の実装を。証明書の有効性をチェックするもう1つのIETF承認の方法は、オンライン証明書ステータスプロトコル（OCSP）です。Firefox 3.0は、少なくともVista以降のバージョンのWindowsと同様に、デフォルトでOCSPチェックを有効にしました。

証明書の構造
標準によって予測される構造は、形式言語であるAbstract Syntax Notation One（ASN.1）で表現されます。
X.509v3デジタル証明書の構造は次のとおりです。
証明書
バージョンナンバー
シリアルナンバー
署名アルゴリズムID
発行者名
有効期間
以前ではない
後ではない
件名
件名公開鍵情報
公開鍵アルゴリズム
件名公開鍵
発行者の一意の識別子（オプション）
件名の一意の識別子（オプション）
拡張機能（オプション）
..。
証明書署名アルゴリズム
証明書の署名
各拡張機能には、オブジェクト識別子として表される独自のIDがこれは、値のセットであり、クリティカルまたは非クリティカルのいずれかを示します。証明書を使用するシステムは、認識できない重要な拡張機能、または処理できない情報を含む重要な拡張機能を検出した場合、証明書を拒否する必要が重要でない拡張は、認識されない場合は無視できますが、認識される場合は処理する必要が
バージョン1の構造は、で与えられる
RFC 1422。
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-ce19}、は、証明書がCAに属しているかどうかを示すために使用されます。
キーの使用法、{id-ce 15}、は、証明書に含まれている公開キーを使用して実行できる暗号化操作を指定するビットマップを提供します。たとえば、キーは署名には使用する必要があるが、暗号化には使用しないことを示している可能性が
拡張キーの使用法、{id-ce 37}、は、通常、リーフ証明書で使用され、証明書に含まれる公開キーの目的を示します。これには、許可された使用を示すOIDのリストが含まれています。たとえば、{id-pkix 3 1}は、TLSまたはSSL接続のサーバー側でキーを使用できることを示します。{id-pkix 3 4}は、キーを使用して電子メールを保護できることを示します。
一般に、証明書にその使用を制限する複数の拡張機能がある場合、特定の使用が適切であるためには、すべての制限を満たす必要がRFC 5280は、keyUsageとextendedKeyUsageの両方を含む証明書の特定の例を示しています。この場合、両方を処理する必要があり、証明書の使用法を指定する際に両方の拡張機能が一貫している場合にのみ、証明書を使用できます。たとえば、NSSは両方の拡張機能を使用して証明書の使用法を指定します。

証明書のファイル名拡張子
X.509証明書には、一般的に使用されるファイル名拡張子がいくつか残念ながら、これらの拡張機能の一部は、秘密鍵などの他のデータにも使用されます。
.pem –（プライバシーが強化された電子メール）Base64でエンコードされたDER証明書。「—– BEGINCERTIFICATE —–」と「—– ENDCERTIFICATE —–」で囲まれています。
.cer、.crt、.der –通常はバイナリDER形式ですが、Base64でエンコードされた証明書も一般的です（上記の.pemを参照）。
.P7B、.p7c – PKCS＃7のSignedDataデータのない構造、単に証明書（複数可）またはCRL（S）
.p12 – PKCS＃12、証明書（公開）と秘密鍵（パスワードで保護）を含めることができます
.pfx – PKCS＃12の前身であるPFX（通常、IISで生成されたPFXファイルを含むPKCS＃12形式のデータが含まれます）
PKCS＃7は、データの署名または暗号化（正式には「エンベロープ」と呼ばれます）の標準です。署名されたデータを検証するために証明書が必要なため、それらをSignedData構造に含めることができます。.P7Cのファイルが署名するための任意のデータなし、のSignedData構造を縮退です。
PKCS＃12は、個人情報交換（PFX）標準から発展し、単一のファイルでパブリックオブジェクトとプライベートオブジェクトを交換するために使用されます。

証明書チェーンと相互認証
証明書チェーン（によって定義された「認証パス」の等価概念参照
RFC 5280のセクション3.2）は、1つの以上続く証明書（通常はエンドエンティティ証明書から始まる）のリストであり、CAの証明書（通常は最後の一つが自己であります-署名付き証明書）、次のプロパティを使用します。
各証明書の発行者（最後の証明書を除く）は、リスト内の次の証明書のサブジェクトと一致します
各証明書（最後の証明書を除く）は、チェーン内の次の証明書に対応する秘密鍵によって署名されます（つまり、1つの証明書の署名は、次の証明書に含まれる公開鍵を使用して検証できます）
リストの最後の証明書はトラストアンカーです。信頼できる手順で配信されたために信頼できる証明書です。
証明書チェーンは、ターゲット証明書（チェーンの最初の証明書）に含まれる公開鍵（PK）およびそれに含まれるその他のデータが事実上そのサブジェクトに属していることを確認するために使用されます。これを確認するために、ターゲット証明書の署名は、次の証明書に含まれるPKを使用して検証され、その署名は次の証明書を使用して検証されます。以下同様に、チェーンの最後の証明書に到達します。最後の証明書はトラストアンカーであるため、正常に到達すると、ターゲット証明書が信頼できることが証明されます。
前の段落の説明は、RFC 5280セクション6で定義され
ている証明書パス検証プロセスの簡略化されたビューであり、証明書の有効日の検証、CRLの検索などの追加のチェックが含まれます。

例1：2つのPKI間の相互認証

例2：CA証明書の更新
証明書チェーンがどのように構築および検証されるかを調べると、具体的な証明書が非常に異なる証明書チェーンの一部になる可能性があることに注意することが重要です（それらはすべて有効です）。これは、同じサブジェクトと公開鍵に対して複数のCA証明書を生成できますが、（異なるCAからの、または同じCAからの異なる秘密鍵からの）異なる秘密鍵で署名できるためです。したがって、1つのX.509証明書に含めることができる発行者とCA署名は1つだけですが、複数の証明書に有効にリンクして、まったく異なる証明書チェーンを構築できます。これは、PKIと他のアプリケーション間の相互認証にとって非常に重要です。次の例を参照して

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

例1：2つのPKI間のルート認証局（CA）レベルでの相互認証
PKI 2に存在するユーザー証明書（「ユーザー2」など）がPKI 1によって信頼されていることを管理するために、CA1はCA2の公開鍵を含む証明書（cert2.1）を生成します。「cert2とcert2.1（緑色）の両方が同じサブジェクトと公開鍵を持っているため、cert2.2（ユーザー2）には「cert2.2cert2」と「cert2.2」の2つの有効なチェーンが cert2.1cert1 “”。
同様に、CA2はCA1の公開鍵を含む証明書（cert1.1）を生成できるため、PKI 1に存在するユーザー証明書（「ユーザー1」など）はPKI2によって信頼されます。

例2：CA証明書の更新
認定パスの構築について（PDF）。PKIフォーラム。2002年9月。古い署名鍵ペアから新しい署名鍵ペアへの正常な移行を可能にするために、CAは、新しい秘密署名鍵によって署名された古い公開鍵を含む証明書と、署名された新しい公開鍵を含む証明書を発行する必要が古い秘密署名鍵による。これらの証明書は両方とも自己発行ですが、どちらも自己署名されこれらは、2つの自己署名証明書（1つは古い証明書、もう1つは新しい証明書）に追加されることに注意して
cert1とcert3の両方に同じ公開鍵（古いもの）が含まれているため、cert5には「cert5cert1」と「cert5cert3cert2」の2つの有効な証明書チェーンがあり、同様にcert6にもこれにより、新しいCAキーへの移行中に、新しいルートCA証明書または古い証明書をトラストアンカーとして持つ当事者が、古いユーザー証明書（cert5など）と新しい証明書（cert6など）を無差別に信頼できるようになります。

X.509証明書のサンプル
これは、wikipedia.orgおよび他のいくつかのWebサイトで使用されたデコードされたX.509証明書の例です。フィールドに記載されているように、GlobalSignによって発行されました。そのサブジェクトフィールドはを組織として記述し、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 = US、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
CPS：https：//www.globalsign.com/repository/
ポリシー：2.23.140.1.2.2
X509v3の基本的な制約： CA：FALSE 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：*。 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：*。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サーバー認証、TLSWebクライアント認証
X509v3サブジェクトキー識別子：
28：2A：26：2A：57：8B：3B：CE：B4：D6：AB：54：EF：D7：38：21：2C：49：5C：36
X509v3権限キー識別子：
keyid：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：
..。
このエンドエンティティ証明書を検証するには、発行者と機関のキー識別子に一致する中間証明書が必要です。
発行者 C = BE、O = GlobalSign nv-sa、CN = GlobalSign組織検証CA-SHA256-G2
権限キー識別子 96：DE：61：F1：BD：1C：16：29：53：1C：C0：CC：7D：3B：83：00：40：E6：1A：7C
TLS接続では、適切に構成されたサーバーがハンドシェイクの一部として中間体を提供します。ただし、エンドエンティティ証明書から「CA発行者」URLを取得することにより、中間証明書を取得することもできます。

中間証明書
これは、認証局に属する中間証明書の例です。この証明書は、上記のエンドエンティティ証明書に署名し、以下のルート証明書によって署名されました。この中間証明書のサブジェクトフィールドは、署名したエンドエンティティ証明書の発行者フィールドと一致することに注意してまた、中間の「サブジェクトキー識別子」フィールドは、エンドエンティティ証明書の「オーソリティキー識別子」フィールドと一致します。
証明書：データ：
バージョン：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
有効
前ではない：2月20日10:00:00 2014 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、pathlen：0
X509v3サブジェクトキー識別子：
96：DE：61：F1：BD：1C：16：29：53：1C：C0：CC：7D：3B：83：00：40：E6：1A：7C
X509v3証明書ポリシー：
ポリシー：X509v3任意のポリシー
CPS：https：//www.globalsign.com/repository/
X509v3 CRL配布ポイント：
フルネーム：
URI：http：//crl.globalsign.net/root.crl
当局情報アクセス：
OCSP-URI：http：//ocsp.globalsign.com/rootr1
X509v3権限キー識別子：
keyid：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接続での使用が信頼されていると見なすことができます。それ以外の場合、エンドエンティティ証明書は信頼できないと見なされます。
証明書：データ：
バージョン：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
有効
以前ではない：9月1日12:00:00 1998 GMT
後ではない：1月28日12:00:00 2028 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：TRUE 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：
..。

安全
Bruce Schneier、Peter Gutmann、およびその他のセキュリティ専門家によるPKIの問題に関する多くの出版物が

アーキテクチャの弱点
無効な証明書のブロックリストの使用（CRLおよびOCSPを使用）、
クライアントがCRLが使用可能な場合にのみ証明書を信頼する場合、クライアントはPKIを魅力的にするオフライン機能を失います。そのため、ほとんどのクライアントはCRLが利用できないときに証明書を信頼しますが、その場合、通信チャネルを制御する攻撃者がCRLを無効にする可能性がGoogleのAdamLangleyは、ソフトフェイルCRLチェックは、事故が発生した場合を除いて機能する安全ベルトのようなものだと述べています。
CRLは、サイズが大きく、分布パターンが複雑であるため、特に不適切な選択です。
あいまいなOCSPセマンティクスと履歴失効ステータスの欠如、
ルート証明書の失効は対処されていません、
集約の問題：IDクレーム（識別子で認証）、属性クレーム（精査された属性のバッグを送信）、およびポリシークレームが1つのコンテナーに結合されます。これにより、プライバシー、ポリシーマッピング、およびメンテナンスの問題が発生します。
委任の問題：CAは、下位のCAが制限された名前空間または属性セットの外部で証明書を発行することを技術的に制限できません。X.509のこの機能は使用されしたがって、インターネット上には多数のCAが存在し、それらとそのポリシーを分類することは克服できない作業です。組織内の権限の委任は、一般的なビジネス慣行のように、まったく処理できません。
フェデレーションの問題：下位CA、ブリッジCA、およびクロス署名の結果である証明書チェーンは、検証を複雑にし、処理時間の点でコストがかかります。パス検証のセマンティクスはあいまいな場合がサードパーティの信頼できるパーティとの階層が唯一のモデルです。二国間信頼関係がすでに確立されている場合、これは不便です。
発行拡張検証（EV）証明書EVの高い検証レベルに対して保護しないことを意味し、同じホスト名に有効な低検証証明書の発行を、防止しないホスト名のman-in-the-middle攻撃。

認証局の問題
証明書を購入するのは、証明書利用者ではなく、対象者です。主題はしばしば最も安い発行者を利用するでしょう、それで品質は競争する市場で支払われこれは、Extended Validation証明書によって部分的に対処されていますが、セキュリティ専門家から見た信頼の価値は低下しています。
認証局は、ユーザーに対するほとんどすべての保証を拒否します（サブジェクトまたは依拠当事者を含む）
「ユーザーは、未定義の認証要求プロトコルを使用して、存在しないディレクトリの不明確な場所に公開されている証明書を取得しますが、それを取り消す実際の手段はありません」
すべての企業と同様に、CAは、その事業を行う法域の対象であり、顧客とユーザーの利益を侵害することを法的に強制される場合が諜報機関はまた、のようなCAの法外妥協を通じて発行された偽の証明書を使用してきたDigiNotar実行するために、man-in-the-middle攻撃を。もう1つの例は、2018年1月1日から新しいオランダの法律が施行され、オランダの諜報機関とセキュリティサービスに新しい権限が与えられたため、オランダ政府のCAの取り消し要求です。

実装の問題
実装には、設計上の欠陥、バグ、標準のさまざまな解釈、さまざまな標準の相互運用性の欠如がいくつかの問題は次のとおりです。
多くの実装では、失効チェックがオフになっています。
障害と見なされ、ポリシーは実施されません
コード署名を含むすべてのブラウザでデフォルトでオンになっていると、インフラストラクチャがクラッシュする可能性があります
DNは複雑で、ほとんど理解されていません（正規化の欠如、国際化の問題）
rfc822Nameには2つの表記があります
名前とポリシーの制約はほとんどサポートされていません
キーの使用は無視され、リストの最初の証明書が使用されています
カスタムOIDの実施は困難です
クライアントをクラッシュさせるため、属性を重要にするべきではありません
属性の長さが指定されていない場合、製品固有の制限が発生します
X.509には実装エラーがあり、たとえば、nullで終了する文字列を使用したサブジェクト名の改ざんや、証明書でのコードインジェクション攻撃が可能です。
攻撃者は、オブジェクト識別子の不正な 0x80埋め込みサブ識別子、誤った実装、またはクライアントのブラウザの整数オーバーフローを使用することにより、未知の属性をCSRに含めることができます。これは、CAが署名し、クライアントが誤って「CN」と解釈します。 “”（OID = 2.5.4.3）。第26回カオスコミュニケーションコングレス「PKIのブラックOP」でのダンカミンスキー

暗号化の弱点
デジタル署名システムは、安全な暗号化ハッシュ関数に依存して機能します。公開鍵インフラストラクチャが安全ではなくなったハッシュ関数の使用を許可すると、攻撃者はハッシュ関数の弱点を悪用して証明書を偽造する可能性が具体的には、攻撃者がハッシュコリジョンを生成できる場合、CAを説得して、無害なコンテンツを含む証明書に署名させることができます。これらのコンテンツのハッシュは、攻撃者によって作成された別の悪意のある証明書コンテンツのセットのハッシュと同じです。選択した値で。攻撃者は、CAが提供する署名を悪意のある証明書の内容に追加して、CAによって署名されているように見える悪意のある証明書を作成する可能性が悪意のある証明書の内容は攻撃者によってのみ選択されるため、無害な証明書とは異なる有効日またはホスト名を持つ可能性が悪意のある証明書には「CA：true」フィールドが含まれている可能性があり、さらに信頼できる証明書を発行できるようになります。
MD2ベースの証明書は長い間使用されており、原像攻撃に対して脆弱でした。ルート証明書にはすでに自己署名があるため、攻撃者はこの署名を使用して中間証明書に使用する可能性が
2005年には、アリエン・レンストラとBENNEデWegerのが実証され、「同じシグネチャを含む2つのX.509証明書を構築するために、ハッシュ衝突を使用する方法と公開鍵のみが異なるもの」、使用して達成衝突攻撃にMD5のハッシュ関数を。
2008年、アレクサンダー・ソーティロブとマーク・スティーブンスは、で発表されたカオス通信議会彼らは、RapidSSLのは、まだMD5に基づいてX.509証明書を発行したという事実を利用することにより、すべての一般的なブラウザで受け入れ不正な認証局を作成することができ実用的な攻撃を。
2009年4月のEurocrypt会議で、マッコーリー大学のオーストラリアの研究者は「SHA-1の自動差動パス検索」を発表しました。研究者たちは、衝突の可能性を数桁増加させる方法を推測することができました。
2017年2月、マークスティーブンスが率いる研究者グループが、SHA-1の衝突を引き起こし、SHA-1の弱点を実証しました。

暗号化の弱点の緩和
ハッシュ衝突を悪用してX.509署名を偽造するには、攻撃者が認証局が署名するデータを予測できる必要がこれは、CAが署名する証明書にランダムなコンポーネント（通常はシリアル番号）を生成することで、ある程度軽減できます。CA /ブラウザフォーラムは、 2011年以来、ベースライン要件セクション7.1にシリアル番号エントロピーを必要としていた
2016年1月1日の時点で、ベースライン要件はSHA-1を使用した証明書の発行を禁止しています。2017年の初めの時点で、Chrome とFirefox はSHA-1を使用する証明書を拒否します。2017年5月の時点で、Edge とSafari の両方もSHA-1証明書を拒否しています。非ブラウザーX.509バリデーターは、SHA-1証明書をまだ拒否し

X.509のPKI標準
PKCS7（暗号化メッセージ構文標準— PKIの署名付きおよび/または暗号化されたメッセージのIDを証明する公開鍵）
トランスポート層セキュリティ（TLS）とその前身のSSL —インターネットで安全な通信のための暗号化プロトコル。
オンライン証明書ステータスプロトコル（OCSP） /証明書失効リスト（CRL） —これは証明書失効ステータスを確認するためのものです
PKCS12（Personal Information Exchange Syntax Standard）—適切な公開鍵証明書とともに秘密鍵を格納するために使用されます

PKIXワーキンググループ
1995年、米国国立標準技術研究所と共同で、インターネット技術特別調査委員会が公開鍵インフラストラクチャ（X.509）ワーキンググループを結成しました。2014年6月に締結されたワーキンググループは、一般に「PKIX」と呼ばれています。これは、生産のRFC使用して、実際にX.509の展開にし、他の標準ドキュメントを。特に、インターネットプロトコルでX.509を使用する方法を定義するRFC3280とその後継のRFC5280を作成し
ました。

X.509証明書を使用する主要なプロトコルと標準
TLS / SSLおよびHTTPSは、S / MIME（Secure Multipurpose Internet Mail Extensions）およびWiFi認証用のEAP-TLS方式と同様に、X.509のRFC5280プロファイルを使用し
ます。SMTP、POP、IMAP、LDAP、XMPPなどのTLSを使用するプロトコルはすべて、本質的にX.509を使用します。
IPSecは、RFC4945プロファイルを使用してピアを認証できます。オープンケーブルセキュリティ仕様は、ケーブル業界で使用するためにX.509の独自のプロファイルを定義します。
スマートカードやTPMなどのデバイスは、多くの場合、自分自身またはその所有者を識別するための証明書を持っています。これらの証明書はX.509形式です。
WS-SecurityのTLS経由または独自の証明書プロファイルのいずれかを介して、標準の定義認証。どちらの方法もX.509を使用します。
マイクロソフトのAuthenticodeコード署名システムは、コンピュータプログラムの作成者を識別するために、X.509を使用しています。
OPC UA産業オートメーション通信規格は、X.509を使用しています。
SSHは通常、Trust On First Useセキュリティモデルを使用しており、証明書は必要ありません。ただし、一般的なOpenSSH実装は、独自の非X.509証明書形式に基づくCA署名付きIDモデルをサポートします。

も参照してください
抽象構文表記1
証明書ポリシー
コードアクセスセキュリティ
通信セキュリティ
情報セキュリティー
ISO / IEC JTC 1
PKIリソースクエリプロトコル
公開鍵暗号
タイムスタンププロトコル
信頼できるタイムスタンプ
EdDSA

参考文献
^ 「X.509：情報技術-オープンシステム相互接続-ディレクトリ：公開鍵および属性証明書フレームワーク」。ITU 。
^ RFC 4158
^ 「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル」。2008年5月。以下は、X.509（PKIX）仕様を使用して公開鍵インフラストラクチャによって想定されるアーキテクチャモデルの簡略図です。
^ 「CA：IncludedCAs」。MozillaWiki 。
^ 「バグ110161-（ocspdefault）デフォルトでOCSPを有効にする」。Mozilla 。取得した3月17日に2016。
^ 「RFC5280セクション4.2」。ツール。IETF。2008年5月。取得した12年2月2013。
^ “”RFC 5280、セクション ‘基本的な制約’ “”。
^ “” ‘ RFC 5280、セクション’キーの使用法” “”。
^ “”RFC 5280、セクション ‘拡張キーの使用法’ “”。
^ ネルソンBボヤード（2002年5月9日）。「証明書拡張のすべて」。Mozilla 。
^ ロイド、スティーブ。認定パスの構築について（PDF）。PKIフォーラム。
^ 「ルートCA間の相互認証」。適格な従属展開シナリオ。マイクロソフト。2009年8月。
^ ナッシュ; デュアン; ジョセフ; ブリンク（2001）。「キーと証明書のライフサイクル。CA証明書の更新」。PKI：E-Securityの実装と管理。RSAプレス-オズボーン/マグロウヒル。ISBN 0-07-213123-3。
^ “WebサービスセキュリティX.509トークンプロファイルバージョン1.1.1″。オアシス。
^ カール・エリソンとブルース・シュナイアー。「トップ10のPKIリスク」（PDF）。Computer Security Journal（Volume XVI、Number 1、2000）。
^ ピーター・ガットマン。「PKI：死んでいない、ただ休んでいる」（PDF）。IEEEコンピュータ（巻：35、発行：8）。
^ ガットマン、ピーター。「PKIについて知りたくなかったが、知ることを余儀なくされたすべて」（PDF）。取得した14年11月2011。
^ ラングレー、アダム（2012年2月5日）。「失効チェックとChromeのCRL」。インペリアルバイオレット。
^ 「セキュリティシステムビジネスプランサンプル」。OGScapital。2014-01-27 。
^ Michael Zusman; アレクサンダーソティロフ。「サブプライムPKI：拡張検証SSLへの攻撃」（PDF）。ブラックハット。
^ ハント、トロイ。「ExtendedValidationCertificatesは無効です」。TroyHunt.com 。
^ ヴァンペルト、クリス。「Logius：オランダ政府のCAの信頼の問題」。Bugzilla 。
^ モクシーマーリンスパイク（2009）。「実際にSSLを打ち負かすためのその他の秘訣」（PDF）。破壊的研究所。ブラックハット。
^ Rec。ITU-T X.690、条項8.19.2
^ ダンカミンスキー（2009年12月29日）。「26C3：PKIのブラックオプス」。CCCイベントブログ。Der Chaos ComputerClub 。取得した29年9月2013。
^ レンズトラ、アリエン; de Weger、Benne（2005年5月19日）。公開鍵に対して意味のあるハッシュ衝突を構築する可能性について（PDF）（テクニカルレポート）。Lucent Technologies、Bell Laboratories＆Technische UniversiteitEindhoven。2013年5月14日のオリジナルからアーカイブ（PDF）。取得した28年9月2013。
^ 「MD5は今日有害であると考えられています」。アイントホーフェン工科大学。2011年6月16日。取得した29年9月2013。
^ 「Eurocrypt2009」。国際暗号学会。
^ キャメロンマクドナルド; フィリップホークス; Josef Pieprzyk（2009）。「SHA-1の衝突が発生しました」（PDF）。マッコーリー大学とクアルコム。
^ nnis Dwyer（2009年6月2日）。「SHA-1衝突攻撃は今252」。SecureWorksInsights 。取得した24年2月2016。
^ マークスティーブンス; エリ・ブルツタイン; ピエール・カープマン; アンジュアルベルティーニ; ヤリックマルコフ。「完全なSHA-1の最初の衝突」（PDF）。CWIアムステルダム＆グーグルリサーチ。2020年9月10日取得–Shattered経由。
^ 「ベースライン要件ドキュメント」。CAブラウザフォーラム。
^ Andrew Whalley（2016年11月16日）。「ChromeのSHA-1証明書」。Googleオンラインセキュリティブログ。
^ 「パブリックWeb上のSHA-1の終わり」。Mozillaセキュリティブログ。
^ 「Microsoftセキュリティアドバイザリ4010323」。Technet。Microsoft 。
^ 「SafariとWebKitはSHA-1証明書をサポートしていません」。Appleサポート。2018年8月16日。
^ ダニエルステンバーグ（2017年1月10日）。「ブラウザ以外のHTTPSが少ない」。ダニエルハックス。
^ Kaliski（1998年3月）。「PKCS＃7：暗号化メッセージ構文バージョン1.5」。IETF 。
^ T Dierks。「トランスポート層セキュリティ（TLS）プロトコルバージョン1.2」。IETF 。
^ Stefan Santesson; マイケルマイヤーズ; リッチアンキー; スラバガルペリン; カーライルアダムズ。「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル-OCSP」。ツール。IETF 。
^ デビッドクーパー; ステファンサンテソン; スティーブンファレル; Sharon Boeyen; Russell Housley; ティムポーク。「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル」。ツール。IETF 。
^ 「PKCS12：個人情報交換構文標準」。EMC.com。RSAラボラトリーズ。
^ 「公開鍵インフラストラクチャ（X.509）（pkix）-憲章」。IETFデータトラッカー。インターネットエンジニアリングタスクフォース。
^ 「Pkixステータスページ」。IETFツール。
^ 「Ubuntuでホストとクライアントを検証するためのSSHCAを作成する方法」。DigitalOcean 。

外部リンク
ITU-TのX.509標準
Peter Gutmannの記事：
PKIの概要
X.509実装ノートとスタイルガイド
「RSAラボからの暗号FAQ」。RSAラボラトリーズ。2006年12月30日にオリジナルからアーカイブされました。
安全なコードガイドラインSun
RFC 4158-インターネットX.509公開鍵インフラストラクチャ：認証パスの構築
RFC 5280-インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル
CSRデコーダーと証明書デコーダー-エンコードされたCSRまたは証明書をデコードおよび検査するために使用できます
phpseclib：X.509デコーダー-キーがX.509のASN.1記述に対応する連想配列にデコードします
SeSeLe、SSL自己署名証明書のウィザード
デジタル証明書についてMicrosoftTechNet”