X.509
X.509
情報技術 - オープンシステム相互接続 - ディレクトリ: 公開鍵証明書と属性証明書のフレームワーク
状態施行中（勧告）
初版1988年11月25日 1.0 （1988年11月25日）
最新バージョン9.2 2023年10月29日 ( 2023-10-29 )
組織ITU-T
委員会ITU-T研究グループ17
シリーズX
基本基準ASN.1
関連規格ISO/IEC 9594-8:2020、X.500
ドメイン暗号化
Webサイトwww .itu .int /rec /T-REC-X .509

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

X.509 証明書は、デジタル署名を使用して、ID を公開鍵に結び付けます。証明書には、ID（ホスト名、組織名、個人名）と公開鍵（RSA、DSA、ECDSA、ed25519など）が含まれており、証明機関によって署名されるか、自己署名されます。証明書が信頼できる証明機関によって署名されるか、または他の手段によって検証されると、その証明書の所有者は、証明書に含まれる公開鍵を使用して、別の相手との安全な通信を確立したり、対応する秘密鍵によってデジタル署名された文書を検証したりすることができます。

X.509 では、署名機関によって無効と判断された証明書に関する情報を配布する手段である証明書失効リストと、中間 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で指定されているIETF の PKIX 証明書とX.509 v3 証明書標準のCRLプロファイルを指し、一般に PKIX は公開鍵インフラストラクチャ (X.509)と呼ばれます。[ 3 ] 

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

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

証明書

X.509証明書
インターネットメディアの種類
アプリケーション/pkix-cert [ 5 ]
統一型識別子（UTI）公開.x509証明書[ 6 ]

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などのブラウザには、事前に設定されたルート証明書のセットがプリインストールされているため、主要な認証局（CA）のSSL証明書は即座に機能します。つまり、ブラウザの開発者が、ブラウザのユーザーにとってどのCAが信頼できる第三者機関であるかを決定します。例えば、Firefoxは、含まれるCAのリストを含むCSVファイルまたはHTMLファイルを提供しています。[ 7 ]

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

証明書の構造

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

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

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

Extensionsフィールドは、存在する場合、1つ以上の証明書の拡張機能のシーケンスです。[ 9 ]：§4.1.2.9：拡張機能 各拡張機能には、オブジェクト識別子（OID）として表現される独自の一意のIDがあります。これは、重要な拡張機能または重要でない拡張機能のいずれかを示す値の集合です。証明書を使用するシステムは、認識できない重要な拡張機能、または処理できない情報を含む重要な拡張機能に遭遇した場合、証明書を拒否する必要があります。重要でない拡張機能は認識されない場合は無視できますが、認識された場合は処理する必要があります。[ 9 ]：§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 }[ 9 ] : §4.2.1.9 は、証明書がCA証明書であり、他の証明書を認証または発行できるかどうかを示すために使用されます。制約はクリティカルとしてマークすることができます。制約がクリティカルとしてマークされている場合、エージェントは、その制約を理解していない場合、証明書の処理を失敗しなければなりません。エージェントは、理解できないクリティカルではない制約の処理を続行できます。
  • 鍵使用法、{ id-ce 15 }[ 9 ] ： §4.2.1.3は 、証明書に含まれる公開鍵を使用して実行できる暗号化操作を指定するビットマップを提供します。たとえば、鍵は署名には使用すべきだが暗号化には使用すべきではないことを示すことができます。
  • 拡張鍵用途（Extended Key Usage）[{ id-ce 37 } 9 ] ： §4.2.1.12 は、通常リーフ証明書において、証明書に含まれる公開鍵の用途を示すために使用されます。この仕様にはOIDのリストが含まれており、各OIDは許可された用途を示します。例えば、は鍵がTLSまたはSSL接続のサーバー側で使用できることを示します。は鍵が電子メールのセキュリティ保護に使用できることを示します。{ id-pkix 3 1 }{ id-pkix 3 4 }

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

拡張認証証明書

CA/ブラウザフォーラムのPKIに基づいて運営されている認証局は、様々なレベルの検証を伴う証明書を発行します。これらの検証は、証明書が本来の目的を果たせるという保証のレベルが異なります。例えば、Webサーバーは、ドメイン検証（DV）と呼ばれる電子メールを用いた最も低いレベルの保証で検証できます。また、より詳細な方法である拡張検証（EV）を用いた、より高いレベルの保証で検証することもできます。

実際には、DV証明書とは、 のようなドメインに対してexample.com、例えば 宛てのメールへの返信などにより、そのドメインに対する制御権が主張された後に証明書が発行されたことwebmaster@example.comを意味します。EV証明書とは、 のようなドメインに対して証明書が発行されexample.com、Example, LLC のような会社がドメインの所有者であり、その所有者が定款によって確認されたことを意味します。

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

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

CA/ブラウザフォーラムのPKIは、拡張検証を認識しています。インターネットのPKI（PKIX）などの他のPKIは、拡張検証を特に重視していません。cURLやWgetなどのPKIXポリシーを使用するツールは、EV証明書を他の証明書と同様に扱います。2019年まで、多くのブラウザは、サイトがEV証明書を提供していることを示すために、URLバーに強力な視覚的フィードバックをユーザーに提供していました。EV証明書の無効性と、犯罪者がブラウザのUIの中央部分に誤解を招く要素を挿入するためにEV証明書が有用であることを示す研究とレポートを受けて、すべての主要ブラウザは、以前の目立つ視覚的フィードバックをURLバーから削除しました。[ 11 ] [ 12 ] [ 13 ]代わりに、2019年以降、 ChromiumやFirefox などのブラウザは、EV発行先情報をサブメニューに隠し、拡張検証を強調表示したり言及したりすることなく、中立的な方法で表示しています。

セキュリティ専門家のピーター・ガットマン氏は、CAがEV証明書を作成した理由は、価格競争による利益減少の後、利益水準を回復するためだと述べています。価格競争が続く中、CAは消費者に証明書を購入させるために価格を引き下げました。その結果、利益は減少し、CAは証明書の検証レベルを低下させ、証明書の信頼性がほぼ失われました。[ 4 ]

証明書ファイル名拡張子

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

  • .pem– (プライバシー強化電子メール) Base64エンコードされたDER証明書（-----BEGIN CERTIFICATE-----との間に囲まれている）-----END CERTIFICATE-----
  • .cer、、.crt–.der通常はバイナリDER形式ですが、Base64 でエンコードされた証明書も一般的です (.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。[ 14 ]
  • .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、、.pfx– PKCS#12では、証明書 (公開) と秘密キー (パスワードで保護) が 1 つのファイルに含まれている場合があります。.pkcs12– Personal Information eXchange PFX は、PKCS#12 の前身です (通常は PKCS#12 形式のデータが含まれます ( IISで生成された PFX ファイルなど))。.pfx
  • .crl–証明書失効リスト（CRL）。証明機関は、有効期限が切れる前に証明書の認証を取り消すためにCRLを作成します。

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

証明書チェーンと相互認証

証明書チェーン（「証明書パス」[ 9 ]：§3.2 とも呼ばれる）は、証明書のリスト（通常はエンドエンティティ証明書から始まる）と、それに続く1つ以上のCA証明書（通常は最後の証明書は自己署名証明書）で構成され、次の特性を持つ：

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

証明書チェーンは、対象証明書（チェーンの最初の証明書）に含まれる公開鍵（PK）と、それに含まれるその他のデータが、その対象者に事実上属していることを確認するために使用されます。これを確認するため、対象証明書の署名は、次の証明書に含まれるPKを使用して検証され、その署名はさらに次の証明書を使用して検証されます。これを繰り返し、チェーンの最後の証明書に到達します。最後の証明書はトラストアンカーであるため、そこに到達できれば、対象証明書が信頼できることが証明されます。

前の段落の説明は、証明書パス検証プロセスに関する簡略化された見解であり、[ 9 ]：§6 には、証明書の有効期限の検証、 CRLの検索などの追加のチェックが含まれます。

例1: 2つのPKI間の相互認証
例2: CA証明書の更新

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

例

これらの図では、

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

例1: 2つのPKI間のルート認証局(CA)レベルでの相互認証

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

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

例2: CA証明書の更新

証明パス構築の理解（PDF）。PKIフォーラム。2002年9月。オリジナル（PDF）から2019年2月4日にアーカイブ。 2014年11月7日閲覧。古い署名鍵ペアから新しい署名鍵ペアへのスムーズな移行を可能にするために、CAは、新しい秘密署名鍵で署名された古い公開鍵を含む証明書と、古い秘密署名鍵で署名された新しい公開鍵を含む証明書を発行する必要があります。これらの証明書はどちらも自己発行されますが、どちらも自己署名ではありません。これらは、2つの自己署名証明書（1つは古いもの、もう1つは新しいもの）に加えて発行されることに注意してください。

cert1とcert3はどちらも同じ公開鍵（古いもの）を持っているため、cert5には「cert5 → cert1」と「cert5 → cert3 → cert2」という2つの有効な証明書チェーンがあり、cert6についても同様です。これにより、新しいCA鍵への移行期間中、新しいルートCA証明書または古い証明書をトラストアンカーとして持つ当事者は、古いユーザー証明書（cert5など）と新しい証明書（cert6など）を区別なく信頼することができます。[ 17 ]

サンプルX.509証明書

これは、wikipedia.org および他のいくつかの Wikipedia ウェブサイトで過去に使用されていた、デコードされた X.509 証明書の例です。発行者フィールドに記載されているように、 GlobalSignによって発行されました。Subject フィールドには組織名として Wikipedia が記述され、DNS の Subject Alternative Name (SAN) フィールドには、証明書が使用可能なホスト名が記述されています。Subject Public Key Info フィールドには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 CPS: 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:*.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サーバー認証、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: ...

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

発行者 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 Issuers」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 有効 2014年2月20日 10:00:00 GMT 以前ではありません 2024年2月20日 10:00:00 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 任意のポリシー CPS: 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接続での使用に信頼できるとみなされます。そうでない場合、エンドエンティティ証明書は信頼できないとみなされます。 

証明書: [ 18 ] データ： バージョン: 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: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: ...

安全

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

アーキテクチャ上の弱点

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

認証機関の問題

  • 証明書を購入する個人または組織は、多くの場合、最も安価な認証局を利用します。これに対応して、認証局は価格を下げ、高価な検証チェックを廃止し、いわゆる「底辺への競争」に取り組んできました。この底辺への競争は、拡張認証 (EV)証明書によって部分的には解決されていますが、セキュリティ専門家の目から見ると信頼の価値は低下しています。[ 25 ] Peter Gutmannによると、EV証明書は追加のセキュリティ制御を追加するものではありません。むしろ、EV証明書は、CAが本来提供すべきサービスに対してより高い料金を請求できるようにすることで、CAの利益を底辺への競争以前のレベルに戻すだけです。[ 4 ]また、この底辺への競争は、Let's Encryptのような証明書を無料で提供する認証局によっても部分的に解決されています。[ 26 ] Let's Encrypt は、5億を超えるウェブサイトが使用する最大の証明書プロバイダーにもなっています。[ 27 ] [ 28 ]
  • 認証局は、認証業務規定（CPS）において、ユーザーおよび依拠当事者に対するほぼすべての保証を否定しようと試みています。例えば、Apple社はCPSにおいて、「適用法の許す範囲において、加入者契約（該当する場合）は、商品性または特定目的への適合性に関する保証を含め、Apple社からの保証を否認する」と述べています。[ 29 ]
  • ピーター・ガットマンによれば、「ユーザーは定義されていない証明書要求プロトコルを使用して、存在しないディレクトリの不明な場所に公開された証明書を取得し、それを失効させる実際の手段はありません」[ 21 ]。
  • 他の企業と同様に、認証局（CA）は事業を展開する法域の管轄権に服しており、顧客やユーザーの利益を損なう法的強制力を持つ場合があります。また、情報機関は、DigiNotarなどのCAへの違法な侵害によって発行された偽の証明書を利用して、中間者攻撃を実行した事例もあります。別の例としては、2018年に可決されたオランダの法律により、オランダの情報機関および治安機関に新たな権限が与えられたことを受けて、オランダ政府の認証局（CA）の失効要請が挙げられます[ 30 ]。

実装上の問題

実装には、設計上の欠陥、バグ、標準規格の解釈の違い、そして異なる標準規格間の相互運用性の欠如といった問題が伴います。例えば、以下のような問題が挙げられます。

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

暗号の弱点

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

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

暗号の脆弱性に対する緩和策

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

2016年1月1日現在、ベースライン要件ではSHA-1を使用した証明書の発行が禁止されています。2017年初頭現在、Chrome [ 41 ]とFirefox [ 42 ]はSHA-1を使用した証明書を拒否しています。2017年5月現在、Edge [ 43 ]とSafari [ 44 ]もSHA-1証明書を拒否しています。OpenSSLは、2021年9月にリリースされたバージョン3.0から、SHA-1証明書をデフォルトで拒否するようになりました。[ 45 ]

X.509のPKI標準

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

PKIXワーキンググループ

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

X.509証明書を使用する主要なプロトコルと標準

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

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

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

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

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

Microsoft Authenticodeコード署名システムは、X.509を使用してコンピュータプログラムの作者を識別します。UEFIのセキュアブート機能は、起動時にX.509を使用してUEFIドライバまたはブートローダを認証し、ブロックリストに登録されたドライバまたはブートローダを（Forbidden Key Exchangeまたはdbxデータベースを使用して）禁止します。[ 52 ]

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

SSHは一般的にTrust On First Use（初回使用時の信頼）セキュリティモデルを採用しており、証明書は必要ありません。しかし、広く普及しているOpenSSH実装は、独自の非X.509証明書形式に基づくCA署名IDモデルをサポートしています。[ 53 ]

参照

参考文献

  1. ^ a b「X.509: 情報技術 - 開放型システム間相互接続 - ディレクトリ: 公開鍵証明書と属性証明書のフレームワーク」 ITU . 2019年11月6日閲覧。
  2. ^ a b Hesse, Peter; Cooper, Matt; Dzambasow, Yuriy A.; Joseph, Susan; Nicholas, Richard (2005年9月).インターネットX.509公開鍵基盤：認証パス構築. ネットワークワーキンググループ. doi : 10.17487/RFC4158 . RFC 4158 .情報提供。
  3. ^ Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (2008年5月).インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル. doi : 10.17487/RFC5280 . RFC 5280 .提案された標準。RFC 9549、9598、8398、8399  、および6818 によって更新されました。RFC 4630、4325、および3280は廃止されました。 以下は、X.509（PKIX ）仕様を用いた公開鍵基盤で想定されるアーキテクチャモデルの簡略図である。
  4. ^ a b c d Gutmann, Peter (2014年4月). 「エンジニアリングセキュリティ」(PDF) .
  5. ^ Housley, R.; Hoffman, P. (1999年5月).インターネットX.509公開鍵基盤運用プロトコル：FTPおよびHTTP . ネットワークワーキンググループ. doi : 10.17487/RFC2585 . RFC 2585 .提案された標準。セクション 4: MIME 登録。
  6. ^ "x509Certificate" . Apple開発者向けドキュメント: Uniform Type Identifiers . Apple Inc.
  7. ^ "CA:IncludedCAs" . Mozilla Wiki . 2017年1月17日閲覧。
  8. ^ 「バグ 110161 - (ocspdefault) OCSP をデフォルトで有効にする」 Mozilla . 2016年3月17日閲覧。
  9. ^ a b c d e f g h Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (2008年5月).インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル. doi : 10.17487/RFC5280 . RFC 5280 .提案 された標準。RFC 9549、9598、8398、8399、6818 により更新。RFC 4630、4325、3280 は廃止。​​​​​​
  10. ^ Nelson B Boyard (2002年5月9日). 「All About Certificate Extensions」 . Mozilla. 2018年12月15日時点のオリジナルよりアーカイブ。2020年9月10日閲覧。
  11. ^ 「EV UI がページ情報に移動」 Chromium Docs 2021年。 2025年7月12日閲覧。
  12. ^ 「Firefox 70のセキュリティとプライバシーのインジケーターが改善」 Mozillaセキュリティブログ2019年10月15日閲覧。 2025年7月12日閲覧。
  13. ^ 「Extended Validation Certificatesは（本当に、本当に）死んだ」 Troy Hunt . 2019年8月13日. 2025年7月12日閲覧。
  14. ^ sysadmin1138 (2009年5月19日). 「PEMファイルとは何か？他のOpenSSL生成キーファイル形式とどう違うのか？」 Server Fault . 2023年10月19日閲覧。{{cite web}}: CS1 maint: 数値名: 著者リスト (リンク)この記事には、 CC BY-SA 2.5ライセンス の下で利用可能なこのソースからのテキストが組み込まれています。
  15. ^ Lloyd, Steve (2002年9月). 「証明パスの構築について」 (PDF) . PKIフォーラム. 2019年2月4日時点のオリジナル(PDF)からアーカイブ。 2014年11月7日閲覧。
  16. ^「ルートCA間の相互認証」。限定従属の展開シナリオ。Microsoft。2009年8月。
  17. ^ Nash、Duane、Joseph、Brink (2001)。「鍵と証明書のライフサイクル。CA証明書の更新」。PKI ：電子セキュリティの実装と管理。RSA Press - Osborne/McGraw-Hill。ISBN 0-07-213123-3。
  18. ^ a b「Web Services Security X.509 Token Profile Version 1.1.1」 Oasis . 2017年3月14日閲覧。
  19. ^ Carl Ellison、Bruce Schneier 「PKIリスクトップ10」(PDF)。Computer Security Journal (第16巻、第1号、2000年)。2015年11月24日時点のオリジナル(PDF)からアーカイブ。 2014年4月2日閲覧。
  20. ^ Peter Gutmann . 「PKI：死んではいない、ただ休んでいるだけ」（PDF） . IEEE Computer（第35巻、第8号）。
  21. ^ a bピーター・グットマン. 「PKIについて知りたくなかったけれど、知らざるを得なかったことすべて」（PDF） . 2011年11月14日閲覧。
  22. ^ Langley, Adam (2012年2月5日). 「失効チェックとChromeのCRL」 . Imperial Violet . 2017年2月2日閲覧。
  23. ^ 「セキュリティシステム事業計画サンプル [2021]」 OGScapital 2014年1月27日. 2021年7月9日時点のオリジナルよりアーカイブ。 2021年6月30日閲覧。
  24. ^ Michael Zusman、Alexander Sotirov (2009年7月). 「Sub-Prime PKI：Extended Validation SSLへの攻撃」(PDF) . Blackhat . 2020年9月10日閲覧。
  25. ^ Hunt, Troy (2018年9月17日). 「Extended Validation Certificates are Dead」 . TroyHunt.com . 2019年2月26日閲覧。
  26. ^ 「Let's Encrypt」 . Let's Encrypt . 2023年7月10日. 2025年4月8日閲覧。
  27. ^ 「より良いインターネットのために - ISRG 2020 年次報告書」(PDF) . Internet Security Research Group . 2020年11月17日. 2021年5月11日閲覧。
  28. ^ 「Let's Encrypt Stats」 . Let's Encrypt . 2023年7月10日. 2025年4月8日閲覧。
  29. ^ 「認証局 - 認証実施規定」（PDF）バージョン6.1。Apple社。2016年8月19日。
  30. ^ヴァン・ペルト、クリス。「ロジウス: オランダ政府 CA の信頼問題」。バグジラ。2017 年10 月 31 日に取得。
  31. ^ Moxie Marlinspike (2009). 「SSLを実際に破るためのさらなるコツ」(PDF) . Institute For Disruptive Studies. Blackhat . 2020年9月10日閲覧。
  32. ^ ITU-T勧告X.690、第8.19.2節
  33. ^ Dan Kaminsky (2009年12月29日). 「26C3: Black Ops Of PKI」 . CCCイベントブログ. Der Chaos Computer Club . 2013年9月29日閲覧。
  34. ^ Lenstra, Arjen; de Weger, Benne (2005年5月19日).公開鍵における意味のあるハッシュ衝突の構築可能性について(PDF) (技術レポート). Lucent Technologies, Bell Laboratories & Technische Universiteit Eindhoven. 2013年5月14日時点のオリジナルよりアーカイブ(PDF) 。 2013年9月28日閲覧。
  35. ^ 「MD5は現在有害とみなされている」アイントホーフェン工科大学、2011年6月16日。 2013年9月29日閲覧。
  36. ^ 「Eurocrypt 2009」。国際暗号研究協会。
  37. ^ Cameron McDonald、Philip Hawkes、Josef Pieprzyk (2009). 「SHA-1の衝突に関する最新情報」(PDF) . Macquarie University and Qualcomm . 2020年9月10日閲覧。
  38. ^ Dennis Dwyer (2009年6月2日). 「SHA-1衝突攻撃が252件に」 . SecureWorks Insights . 2016年2月24日閲覧。
  39. ^ Marc Stevens、Elie Bursztein、Pierre Karpman、Ange Albertini、Yarik Markov。「完全なSHA-1の最初の衝突」（PDF）。CWI Amsterdam & Google Research 。 2020年9月10日閲覧– Shattered経由。
  40. ^ 「ベースライン要件ドキュメント」 . CAブラウザフォーラム. 2017年3月19日閲覧。
  41. ^ Andrew Whalley (2016年11月16日). 「ChromeのSHA-1証明書」 . Googleオンラインセキュリティブログ. 2017年3月19日閲覧。
  42. ^ 「パブリックWebにおけるSHA-1の終了」 Mozillaセキュリティブログ2017年2月23日。 2017年3月19日閲覧。
  43. ^ 「Microsoft セキュリティ アドバイザリ 4010323」 . Technet . Microsoft . 2017年5月16日閲覧。
  44. ^ 「SafariとWebKitはSHA-1証明書をサポートしていません」。Appleサポート。2018年8月16日。 2020年9月10日閲覧。
  45. ^ "openssl/NEWS.md at master · openssl/openssl" . GitHub . 2025年2月16日閲覧。
  46. ^ B. Kaliski (1998年3月). PKCS #7: 暗号メッセージ構文 バージョン1.5 . ネットワークワーキンググループ. doi : 10.17487/RFC2315 . RFC 2315 .情報提供。
  47. ^ T. Dierks; E. Rescorla (2008年8月).トランスポート層セキュリティ (TLS) プロトコル バージョン 1.2 . IETF TLS ワークグループ. doi : 10.17487/RFC5246 . RFC 5246 .廃止 。RFC 8446  により廃止。RFC 3268、4346、4366を 廃止。RFC 4492を更新。​
  48. ^ S. Santesson; M. Myers; R. Ankey; S. Galperin; C. Adams (2013年6月). X.509 インターネット公開鍵基盤オンライン証明書ステータスプロトコル - OCSP .インターネット技術特別調査委員会. doi : 10.17487/RFC6960 . RFC 6960 .提案 された標準。RFC 8954 により更新。RFC 6277 および2560は廃止。RFC 5912を 更新。
  49. ^ 「PKCS 12: 個人情報交換構文標準」 EMC.com RSA Laboratories. 2017年7月6日時点のオリジナルよりアーカイブ。 2017年3月19日閲覧。
  50. ^ 「公開鍵基盤（X.509）（pkix） - 憲章」IETFデータトラッカー。インターネット技術タスクフォース。 2013年10月1日閲覧。
  51. ^ 「Pkixステータスページ」IETFツール。2017年3月10日閲覧。
  52. ^ Smith, Roderick W. (2012年11月4日). 「Linux用EFIブートローダーの管理：セキュアブートの制御（Linuxからのキー管理）」 . Roderick W. SmithのWebページ. 2025年2月20日閲覧。
  53. ^ 「Ubuntuでホストとクライアントを検証するためのSSH CAを作成する方法」 DigitalOcean . 2017年3月19日閲覧。
「 https://en.wikipedia.org/w/index.php?title=X.509&oldid=1336281283」より取得