証明機関

暗号学において、証明機関または認証局（CA ）は、デジタル証明書の保管、署名、発行を行う機関です。デジタル証明書は、証明書の指定された主体による公開鍵の所有権を証明します。これにより、他者（証明書利用者）は、証明された公開鍵に対応する秘密鍵に関する署名またはアサーションに依拠することができます。CAは、証明書の主体（所有者）と証明書を信頼する当事者の両方から信頼される、信頼できる第三者として機能します。[ 1 ]これらの証明書の形式は、X.509またはEMV標準で指定されています。

認証局の特に一般的な用途の一つは、ワールドワイドウェブの安全なブラウジングプロトコルであるHTTPSで使用される証明書への署名です。また、各国政府が電子文書署名に使用するための身分証明書の発行にも使用されます。[ 2 ]

概要

信頼された証明書を使うと、インターネット経由でサーバーへの安全な接続を確立できる。証明書は、あたかも自分がターゲットであるかのように動作するターゲットサーバーへの経路上に偶然存在する悪意ある第三者を回避するために不可欠である。このようなシナリオは一般に中間者攻撃と呼ばれる。クライアントは、安全な接続を開始する前の承認の一部として、CA証明書を使ってサーバー証明書のCA署名を認証する。[ 3 ] 通常、ブラウザなどのクライアントソフトウェアには、信頼できるCA証明書のセットが含まれている。多くのユーザーはクライアントソフトウェアを信頼する必要があるため、これは理にかなっている。悪意のあるクライアントや侵害を受けたクライアントは、セキュリティチェックを一切省略して、ユーザーを騙してそうではないと信じ込ませることができる。

CA のクライアントは、サーバ管理者であり、そのサーバがユーザに付与する証明書を求めます。商用 CA は証明書の発行に料金を請求し、その顧客は認証されたサーバへの安全な接続がすぐに効率的に機能するよう、ほとんどの Web ブラウザに CA の証明書が含まれていることを期待しています。特定の証明機関を信頼する Web ブラウザ、その他のデバイス、アプリケーションの数は、ユビキタスと呼ばれます。非営利企業のMozilla は、自社製品とともに複数の商用 CA 証明書を発行しています。 [ 4 ] Mozilla が独自のポリシーを策定した一方で、CA/ブラウザフォーラムはCA の信頼に関して同様のガイドラインを策定しました。単一の CA 証明書は、複数の CA またはその再販業者間で共有できます。ルートCA 証明書は、さまざまな検証要件を持つ複数の中間CA 証明書を発行するためのベースになる場合があります。

商用CAに加えて、 Let's Encryptなどの非営利団体も公的に信頼されたデジタル証明書を無料で発行しています。また、 IBM Cloud、Amazon Web Services、Cloudflare、Google Cloud Platformなど、大規模なクラウドコンピューティングおよびウェブホスティング企業も公的に信頼されたCAであり、自社のインフラストラクチャでホストされているサービスに証明書を発行しています。

大規模な組織や政府機関は、それぞれ独自のPKI（公開鍵基盤）を保有している場合があります。それぞれのPKIには独自のCA（認証局）が含まれます。自己署名証明書を使用するサイトは、独自のCAとして機能します。

EMV決済カードを発行する商業銀行はEMV認証局[ 5 ]によって管理されており、これは販売時点情報管理端末（POS）で開始された決済取引をカード発行銀行にルーティングし、カード所有者の銀行口座から支払受取人の銀行口座に資金を送金する決済スキームである。各決済カードは、カードデータとともにカード発行者証明書をPOSに提示する。発行者証明書はEMV CA証明書によって署名されている。POSはストレージからEMV CAの公開鍵を取得し、発行者証明書と決済カードの真正性を検証してから、決済スキームに決済要求を送信する。

ブラウザやその他のクライアントは、ユーザーがCA証明書を任意に追加したり削除したりできるのが一般的です。サーバー証明書の有効期間は一般的に比較的短いですが、CA証明書はさらに延長されます[ 6 ]。そのため、頻繁にアクセスするサーバーの場合、サーバーの証明書が更新されるたびにセキュリティ免除を確認するよりも、発行されたCA証明書をインポートして信頼する方がエラーの発生リスクが低くなります。

信頼できる証明書は、メッセージの暗号化や署名に使用されることは稀です。CAはエンドユーザー証明書も発行しており、これはS/MIMEで使用できます。ただし、暗号化には受信者の公開鍵が必要であり、暗号化されたメッセージの作成者と受信者は互いに面識があるため、信頼できる第三者の有用性は、公開メーリングリストに送信されるメッセージの署名検証に限定されます。

プロバイダー

世界的に、認証局ビジネスは細分化されており、国レベルまたは地域レベルのプロバイダが自国の市場を独占しています。これは、法的拘束力のあるデジタル署名など、デジタル証明書の多くの用途が、現地の法律、規制、および認証局の認定制度と関連しているためです。

しかし、世界的に信頼されるTLS/SSLサーバー証明書の市場は、少数の多国籍企業によって大部分が支配されています。この市場は、技術的な要件のために参入障壁が非常に高くなっています。 [ 7 ]法的に義務付けられているわけではありませんが、新規プロバイダーは、Webブラウザやオペレーティングシステムに信頼できるルートとして登録されるために、毎年セキュリティ監査（北米の証明機関向けのWebTrust [ 8 ]や欧州のETSI [ 9 ]など）を受けることを選択する場合があります。

2020年8月24日現在、Mozilla Firefoxウェブブラウザでは52の組織を代表する147のルート証明書が信頼されており、[ 10 ] macOSでは60の組織を代表する168のルート証明書が信頼されており、[ 11 ] Microsoft Windowsでは101の組織を代表する255のルート証明書が信頼されています。[ 12 ] Android 4.2（Jelly Bean）の時点で、Androidには現在100を超えるCAが含まれており、リリースごとに更新されています。[ 13 ]

2014年11月18日、電子フロンティア財団、Mozilla、Cisco、Akamaiを含む企業と非営利団体のグループは、無料のドメイン検証済みX.509証明書と、証明書のインストールとメンテナンスを可能にするソフトウェアを提供する非営利の証明機関であるLet's Encryptを発表しました。 [ 14 ] Let's Encryptは、連邦税免除が認められているカリフォルニア州の非営利団体である新しく設立されたInternet Security Research Groupによって運営されています。[ 15 ]

有効なTLS証明書の監視における業界標準であるNetcraftの2015年5月のデータによると、「世界的な[TLS]エコシステムは競争が激しいものの、少数の大手認証局（CA）が支配しており、公開ウェブサーバーで発行された[TLS]証明書の4分の3は、3つの認証局（Symantec、Comodo、GoDaddy）で占められています。[本調査]開始以来、Symantec（またはSymantecに買収される前のVeriSign）がトップの座を維持しており、現在では全証明書の3分の1弱を占めています。異なる手法の影響を示す例として、最もアクセス数の多い100万のサイトにおいて、Symantecは有効で信頼できる証明書の44%を発行しており、これは同社の市場シェア全体を大幅に上回っています。」[ 16 ]

2024年7月現在、Alexa上位1000万ウェブサイトとTranco上位100万ウェブサイトの認証局の使用状況に関する統計を収集している調査会社W3Techsは、絶対的な使用シェアで上位5つの認証局を以下のようにリストアップしています。[ 17 ]

ランク発行者使用法市場占有率
1レッツ・エンクリプト60.6%64.1%
2グローバルサイン22.3%23.6%
3セクティゴ5.7%6.0%
4GoDaddyグループ3.7%3.9%
5デジサートグループ1.8%1.9%

検証基準

HTTPSサーバーの証明書の大半を発行する商用CAは、通常、「ドメイン検証」と呼ばれる手法を用いて証明書の受信者を認証します。ドメイン検証に用いられる手法はCAによって異なりますが、一般的にドメイン検証は、証明書申請者が特定のドメイン名を管理していることを証明することを目的としており、申請者の身元に関する情報を証明するものではありません。

多くの認証局は、ドメイン検証証明書よりも厳格な代替手段として、拡張認証（EV）証明書も提供しています。拡張認証は、ドメイン名の管理だけでなく、証明書に含まれる追加の識別情報も検証することを目的としています。一部のブラウザでは、この追加の識別情報がURLバーの緑色のボックスに表示されます。ドメイン検証の弱点に対する解決策としてのEVの限界の一つは、攻撃者が依然として標的ドメインのドメイン検証証明書を入手し、攻撃中にそれを展開できる可能性があることです。もしそうなった場合、被害者のユーザーが目にする違いは、会社名が表示された緑色のバーが表示されないことです。ユーザーがこの不在を攻撃の兆候として認識するかどうかについては疑問があります。 2009年にInternet Explorer 7を使用したテストでは、IE7のEV警告が表示されないことに対してユーザーは気づかなかったことが示されました。しかし、Microsoftの新しいブラウザであるEdge Legacyでは、EV証明書とドメイン検証証明書の間に大きな違いが見られ、ドメイン検証証明書には中が空洞の灰色の鍵アイコンが表示されます。

検証の弱点

ドメイン検証には、構造的なセキュリティ上の制約があります。特に、CAが送信するドメイン検証プローブを攻撃者が観測できるような攻撃に対して、常に脆弱です。こうした攻撃には、DNS、TCP、BGPプロトコル（TLS/SSLのような暗号保護機能を持たない）への攻撃や、ルーターの侵害などが含まれます。このような攻撃は、CAの近くのネットワーク上、あるいは標的ドメイン自体の近くで発生する可能性があります。

最も一般的なドメイン検証手法の一つは、認証トークンまたはリンクを含むメールを、ドメインの管理責任者と思われるメールアドレスに送信するというものです。これは、ドメインのWHOISエントリに記載されている技術担当者のメールアドレス、またはドメインのadmin@、administrator@、webmaster@、hostmaster@ 、 postmaster@などの管理メールアドレスが考えられます。 [ 18 ] [ 19 ] 一部の認証局は、ドメインのroot@、 info@、support@を使用した確認を受け付ける場合があります。 [ 20 ] ドメイン検証の理論は、これらの管理アドレスに送信されたメールは、ドメインの正当な所有者だけが読めるというものです。

ドメイン認証の実装は、セキュリティ上の脆弱性の原因となることがあります。ある事例では、セキュリティ研究者が、CAがdomain.comの代わりに[email protected]のようなメールアドレスを使用することを許容していたものの、すべてのウェブメールシステムが攻撃者による登録を防ぐために「ssladmin」というユーザー名を予約していたわけではないため、攻撃者がウェブメールサイトの証明書を入手できたことを示しました。[ 21 ]

2011年以前は、ドメイン検証に使用できるメールアドレスの標準リストが存在しなかったため、メール管理者はどのアドレスを予約する必要があるか明確ではありませんでした。 2011年11月に採択されたCA/ブラウザフォーラムのベースライン要件の最初のバージョンでは、そのようなアドレスのリストが指定されました。これにより、メールホストはこれらのアドレスを管理用に予約できるようになりましたが、このような予防措置は依然として普遍的ではありません。2015年1月、フィンランド人男性がフィンランド語版Microsoft Liveでユーザー名「hostmaster」を登録し、ドメイン名の所有者ではないにもかかわらず、live.fiのドメイン検証済み証明書を取得することができました。[ 22 ]

証明書の発行

公開鍵証明書を取得する手順

CAは、公開鍵と所有者のIDを含むデジタル証明書を発行します。対応する秘密鍵は公開されず、鍵ペアを生成したエンドユーザーによって秘密に保持されます。この証明書は、証明書に含まれる公開鍵が証明書に記載されている個人、組織、サーバー、またはその他のエンティティに属していることをCAが確認または検証したものでもあります。このようなスキームにおけるCAの義務は、申請者の資格情報を検証し、ユーザーと証明書利用者が発行された証明書の情報を信頼できるようにすることです。CAは、このために様々な標準とテストを使用します。本質的に、認証局は「はい、この人物は本人であり、私たちCAはそれを保証します」と宣言する責任があります。[ 23 ]

ユーザーがCAを信頼し、CAの署名を検証できる場合、特定の公開鍵が証明書に記載されている人物に属していると想定することもできます。[ 24 ]

例

公開鍵暗号は、二者間でやり取りされるデータを暗号化するために使用できます。これは通常、ユーザーがHTTPセキュアプロトコルを実装しているサイトにログオンする際に発生します。この例では、ユーザーがオンラインバンキングを行うために銀行のホームページwww.bank.exampleにログオンするとします。ユーザーがwww.bank.exampleのホームページを開くと、ウェブブラウザに表示されるすべてのデータとともに公開鍵を受け取ります。公開鍵はクライアントからサーバーへのデータを暗号化するために使用できますが、安全な手順は、一時的な共有対称暗号化鍵を決定するプロトコルで使用することです。このような鍵交換プロトコル内のメッセージは、銀行の公開鍵で暗号化することができ、銀行のサーバーだけが秘密鍵を持ち、メッセージを読み取ることができます。[ 25 ]

残りの通信は新しい（使い捨ての）対称鍵を使用して行われるため、ユーザーが銀行のページに情報を入力し、ページを送信する（情報を銀行に送り返す）と、ユーザーがページに入力したデータはウェブブラウザによって暗号化されます。したがって、たとえ誰かがユーザーからwww.bank.exampleに送信された（暗号化された）データにアクセスできたとしても、盗聴者はそれを読み取ったり解読したりすることはできません。

このメカニズムは、ユーザーがウェブブラウザに表示されているのが銀行であることを確信できる場合にのみ安全です。ユーザーがwww.bank.exampleと入力した際に通信が乗っ取られ、偽のウェブサイト（銀行のウェブサイトを装ったもの）がそのページの情報をユーザーのブラウザに送り返した場合、偽のウェブページは偽の公開鍵（偽サイトは対応する秘密鍵を保有）をユーザーに送信できます。ユーザーはフォームに個人情報を入力し、ページを送信します。すると、偽のウェブページはユーザーのデータにアクセスできるようになります。

証明機関のメカニズムは、まさにこれを防ぐことを目的としています。証明機関（CA）は公開鍵とその所有者を保管する組織であり、通信に関わるすべての当事者はこの組織を信頼し（そしてその公開鍵を知っています）。ユーザーのウェブブラウザがwww.bank.exampleから公開鍵を受け取ると、その鍵のデジタル署名（いわゆるX.509証明書に含まれる追加情報を含む）も受け取ります。ブラウザは既にCAの公開鍵を所有しているため、署名を検証し、証明書とその中の公開鍵を信頼することができます。www.bank.exampleは証明機関が認証した公開鍵を使用しているため、偽のwww.bank.exampleは同じ公開鍵しか使用できません。偽のwww.bank.exampleは対応する秘密鍵を知らないため、その真正性を検証するために必要な署名を作成することができません。[ 26 ]

安全

データがCAに（おそらく電子ネットワーク経由で）提示され、証明書を要求する個人／企業／プログラムの資格情報も同様に提示された場合、データとエンティティの一致の正確性を保証することは困難です。そのため、商用CAは、政府機関、決済インフラ、サードパーティのデータベースやサービス、カスタムヒューリスティックなどを活用するなど、複数の認証手法を組み合わせて使用​​することがよくあります。一部のエンタープライズシステムでは、Kerberosなどのローカル認証形式を使用して証明書を取得し、それを外部の証明書利用者が使用できます。公証人は、署名を公証する当事者を個人的に知っていることが求められる場合があります。これは、多くのCAが達成している基準よりも高いものです。米国法曹協会のオンライン取引管理に関する概要によると、デジタル署名に関して制定された米国の連邦法および州法の主な目的は、「矛盾した、過度に煩雑な地方規制を防止し、電子文書が紙文書に関連する従来の要件を満たすことを確立すること」です。さらに、米国の電子署名法と提案されたUETAコード[ 27 ]は、次のことを保証するのに役立ちます。

  1. 当該取引に関連する署名、契約書、その他の記録は、電子形式であるという理由のみで法的効果、有効性、執行可能性を否定されることはない。
  2. 当該取引に係る契約は、その締結に電子署名又は電子記録が使用されたという理由のみをもって、その法的効力、有効性又は執行可能性を否定されるものではない。

個人や企業の身元を正しく確認するためのセキュリティ対策が講じられているにもかかわらず、単一の認証局（CA）が偽の証明書を偽造者に発行するリスクが存在します。また、同一または非常に類似した名前の個人や企業を登録することも可能であり、混乱を招く可能性があります。このリスクを最小限に抑えるため、証明書透明性イニシアチブ（CTI）は、すべての証明書を公開の偽造不可能なログで監査することを提案しており、これはフィッシング詐欺の防止に役立つ可能性があります。[ 28 ] [ 29 ]

大規模な導入では、アリスはボブの認証局をよく知らない可能性があります（おそらく両者はそれぞれ異なるCAサーバーを使用しているため）。そのため、ボブの証明書には、アリスが認識できると想定される別のCA 2によって署名されたボブのCAの公開鍵も含まれている可能性があります。このプロセスは、通常、CAとCA証明書の階層構造またはメッシュ構造につながります。

証明書の失効

証明書は有効期限前に失効される可能性があり、これは証明書がもはや有効ではないことを示します。失効が行われない場合、攻撃者は有効期限まで、侵害された証明書や誤って発行された証明書を悪用することができます。[ 30 ]したがって、失効は公開鍵基盤の重要な部分です。[ 31 ]失効は発行CAによって実行され、暗号的に認証された失効証明書を発行します。[ 32 ]

失効情報をクライアントに配布する場合、失効の発見の適時性（したがって、攻撃者が侵害された証明書を悪用する機会）は、失効ステータスの照会におけるリソースの使用およびプライバシーの懸念とトレードオフの関係にあります。[ 33 ]失効情報が利用できない場合（事故または攻撃のいずれかにより）、クライアントは、フェイルハードにして証明書が失効されているものとして扱う（したがって可用性が低下する）か、フェイルソフトにして証明書が失効されていないものとして扱う（したがって、攻撃者が失効を回避できるようにする）かを決定する必要があります。[ 34 ]

失効チェックのコストと、信頼性の低いリモートサービスによる可用性への影響を考慮し、ウェブブラウザは失効チェックの実行回数を制限し、実行する場合はフェイルソフトな対応をとっています。[ 35 ]証明書失効リストは日常的に使用するには帯域幅の消費量が大きすぎ、オンライン証明書ステータスプロトコルは接続遅延とプライバシーの問題を引き起こします。フェイルハードな対応を可能にする他の方式も提案されていますが、まだ導入には至っていません。[ 31 ]

業界団体

ベースライン要件

CA/ブラウザフォーラムは、CAが遵守すべきポリシーと技術要件のリストであるベースライン要件[ 41 ]を公開しています。これは、Firefox [ 42 ]とSafari [ 43 ]の証明書ストアへの組み込み要件です。

2025年4月14日、CA/ブラウザフォーラムは、SSL/TLS証明書の有効期間を2029年3月15日までに最大47日に短縮する投票を可決しました。[ 44 ]

開始日最大寿命導入証明書の更新頻度
2012年7月1日60ヶ月ベースライン要件のv1.0。§9.4
2015年4月1日39ヶ月ベースライン要件v1.3.0。§6.3.2
2018年3月1日825日ベースライン要件のv1.4.4。§6.3.2
2020年9月1日398日1年
2026年3月15日200日SC-081v36ヶ月
2027年3月15日100日SC-081v33ヶ月
2029年3月15日47日間SC-081v31ヶ月

CAの侵害

CA が破壊される可能性がある場合、システム全体のセキュリティが失われ、侵害された CA を信頼するすべてのエンティティが破壊される可能性があります。

例えば、攻撃者のイブが、認証局（CA）からアリスを名乗る証明書を発行してもらったとします。つまり、証明書にはアリスを名乗っていることが公に明記され、アリスに関するその他の情報も含まれている可能性があります。アリスの情報の一部、例えば勤務先名などは真実である可能性があり、証明書の信頼性を高めます。しかし、イブは証明書に関連付けられた極めて重要な秘密鍵を保有しています。イブは証明書を使ってデジタル署名されたメールをボブに送信し、ボブにそのメールがアリスからのものだと信じ込ませることができます。ボブは、アリスだけが読めると思い込み、暗号化されたメールで返信する可能性もありますが、実際にはイブは秘密鍵を使ってそのメールを解読することができます。

このようなCAの転覆に関する注目すべき事例は2001年に発生しました。認証局VeriSignが、 Microsoftを名乗る人物に2つの証明書を発行したのです。これらの証明書には「Microsoft Corporation」という名称が付けられていたため、実際にはMicrosoftから提供されていないMicrosoftソフトウェアのアップデートが、あたかもMicrosoftから提供されているかのように見せかける詐欺行為に利用される可能性がありました。この不正行為は2001年初頭に発覚し、MicrosoftとVeriSignは、この問題の影響を最小限に抑えるための措置を講じました。[ 45 ] [ 46 ]

2008年、コモドの再販業者であるCertstarは、Mozillaを代表する権限を持たないEddy Niggにmozilla.comの証明書を販売しました。[ 47 ]

2011年には、ComodoとDigiNotarから偽造証明書が取得されました。 [ 48 ] [ 49 ]イランのハッカーによるものとされています。この偽造DigiNotar証明書がイランにおける中間者攻撃に使用されたという証拠があります。[ 50 ]

2012年に、Trustwaveが透過的なトラフィック管理（中間者攻撃）に使用される従属ルート証明書を発行したことが明らかになりました。これにより、企業は従属証明書を使用してSSL内部ネットワークトラフィックを盗聴できるようになりました。[ 51 ]

2012年、Flameマルウェア（別名SkyWiper）には、破損したMD5ハッシュアルゴリズムを使用したMicrosoftターミナルサーバーライセンス証明書によって発行された有効な証明書とMD5衝突を起こすモジュールが含まれていました。そのため、作成者は証明書に記載されているハッシュを用いて衝突攻撃を実行することができました。[ 52 ] [ 53 ]

2015年、中国の中央ドメインレジストリに所属するMCSホールディングスという中国の認証局が、 Googleドメインに対して無許可の証明書を発行しました。[ 54 ] [ 55 ]そのため、GoogleはChromeからMCSとルート認証局の両方を削除し、証明書を失効させました。[ 56 ]

キーストレージ

証明機関の秘密鍵を盗んだ攻撃者は、CA のシステムに継続的にアクセスすることなく、CA であるかのように証明書を偽造できます。したがって、鍵の盗難は証明機関が防御する主要なリスクの 1 つです。公的に信頼されている CA は、ほとんどの場合、鍵をハードウェア セキュリティ モジュール(HSM) に保存します。これにより、鍵を使用して証明書に署名できますが、通常は物理的制御とソフトウェア制御の両方を使用してその鍵の抽出を防止します。CA は通常、長期的なルート証明書の鍵をオフラインの HSM に保管するというさらなる予防策を講じます。ただし、有効期間が短い中間証明書に署名する必要がある場合は除きます。オンライン HSM に保存されている中間証明書は、エンド エンティティ証明書に署名したり、失効情報を最新に保ったりする日常的な作業を実行できます。

CA は、キーが改ざんされたりコピーされたりしないようにするために、署名キーを生成するときに キーセレモニーを使用することがあります。

信頼できる第三者機関のスキームの実装上の弱点

現在の X.509 方式の実装方法における重大な弱点は、特定の当事者が信頼するどの CA も、選択したどのドメインに対しても証明書を発行できることです。このような証明書は、正当で認可されているかどうかに関わらず、信頼する当事者によって有効なものとして受け入れられます。[ 57 ] X.509 と信頼できる第三者を採用している最も一般的な技術が HTTPS プロトコルであることを考えると、これは重大な欠点です。すべての主要なウェブ ブラウザーは、数十に及ぶ信頼できる CA のリストが事前設定された状態でエンド ユーザーに配布されているため、これらの事前承認された信頼できる CA のいずれかが、どのようなドメインに対しても有効な証明書を発行できることになります。[ 58 ] これに対する業界の反応は沈黙しています。[ 59 ]ブラウザーの事前設定された信頼できる CA リストの内容は、ブラウザー アプリケーションを配布またはインストールさせている当事者によって独立して決定されるため、CA 自身にできることは実際には何もありません。

この問題は、 DNSベース名前付きエンティティ認証（DANE）プロトコル開発の原動力となっています。ドメインネームシステムセキュリティ拡張（DNSSEC）と組み合わせてDANEを採用することで、ドメインのPKIにおける信頼できる第三者の役割は、完全に排除されるわけではないにしても、大幅に軽減されます。

参照

参考文献

  1. ^ Chien, Hung-Yu (2021-08-19). 「Forward Secrecyを備えた動的公開鍵証明書」 . Electronics . 10 (16): 2009. doi : 10.3390/electronics10162009 . ISSN  2079-9292 .
  2. ^ 「証明機関 (CA) とは何ですか?」。
  3. ^ Villanueva, John Carl. 「デジタル証明書の仕組み - 概要」 www.jscape.com . 2021年9月5日閲覧。
  4. ^ 「Mozillaに含まれるCA証明書リスト — Mozilla」 Mozilla.org。2013年8月4日時点のオリジナルよりアーカイブ。 2014年6月11日閲覧。
  5. ^ 「EMV CA」。EMV Certificate Authority Worldwide。2010年10月2日。 2019年2月17日閲覧。
  6. ^ Zakir Durumeric、James Kasten、Michael Bailey、J. Alex Halderman (2013年9月12日). 「HTTPS証明書エコシステムの分析」(PDF) . The Internet Measurement Conference . SIGCOMM . 2013年12月22日時点のオリジナルよりアーカイブ(PDF) . 2013年12月20日閲覧。
  7. ^ 「SSL証明書とは？」 2015年11月3日時点のオリジナルよりアーカイブ。2022年3月19日閲覧。
  8. ^ "webtrust" . webtrust. 2013年8月18日時点のオリジナルよりアーカイブ。2013年3月2日閲覧。
  9. ^ Kirk Hall (2013年4月). 「認証局に適用される標準および業界規制」(PDF) . トレンドマイクロ. 2016年3月4日時点のオリジナルよりアーカイブ(PDF) . 2014年6月11日閲覧.
  10. ^ "CA:IncludedCAs - MozillaWiki" . wiki.mozilla.org . 2017年3月25日時点のオリジナルよりアーカイブ。2017年3月18日閲覧。
  11. ^ 「macOS High Sierraで利用可能な信頼されたルート証明書のリスト」。Appleサポート。2020年8月24日閲覧。
  12. ^ 「Microsoftに含まれるCA証明書リスト」 . ccadb-public.secure.force.com . 2020年8月24日閲覧。
  13. ^ 「HTTPSとSSLによるセキュリティ」 developer.android.com 。 2017年7月8日時点のオリジナルよりアーカイブ。2017年6月9日閲覧。
  14. ^ 「Let's Encrypt: あらゆる場所でSSL/TLSを配信」（プレスリリース）Let's Encrypt。2014年11月18日時点のオリジナルよりアーカイブ。 2014年11月20日閲覧。
  15. ^ 「About」 . Let's Encrypt. 2015年6月10日時点のオリジナルよりアーカイブ。 2015年6月7日閲覧。
  16. ^ 「SSL証明書のカウント - Netcraft」 news.netcraft.com 2015年5月13日。2015年5月16日時点のオリジナルよりアーカイブ。
  17. ^ 「ウェブサイトのSSL証明書機関の使用統計、2025年12月 - W3Techs 」。w3techs.com 。
  18. ^ 「公的に信頼された証明書の発行と管理に関する基本要件、v.1.2.3」（PDF）。2015年3月23日時点のオリジナルからアーカイブ（PDF） 。 2015年3月20日閲覧。
  19. ^ “CA/禁止または問題のある慣行 - MozillaWiki” . wiki.mozilla.org . 2017年7月21日時点のオリジナルよりアーカイブ。 2017年7月6日閲覧。
  20. ^ 「SSL FAQ - よくある質問 - Rapid SSL」www.rapidssl.com。2015年2月6日時点のオリジナルよりアーカイブ。
  21. ^ Zusman, Mike (2009).刑事告訴は行われない：PKIハッキング(PDF) . DEF CON 17. ラスベガス. 2013年4月15日時点のオリジナルよりアーカイブ(PDF) .
  22. ^ 「フィンランド人男性がシンプルなメールアカウントを作成し、マイクロソフトのセキュリティ証明書を取得」 tivi.fi 2015年3月18日。2015年8月8日時点のオリジナルよりアーカイブ。
  23. ^ 「認証局の責任」。2015年2月12日時点のオリジナルよりアーカイブ。2015年2月12日閲覧。
  24. ^ 「Network World」 2000年1月17日。
  25. ^応用暗号とネットワークセキュリティ：第2回国際会議、ACNS 2004、中国黄山、2004年6月8日～11日。議事録。Springer。2004年6月。ISBN 9783540222170。
  26. ^証明書ライフサイクル管理のショートカットガイド. Realtimepublishers.com. 2006. ISBN 9781931491594。
  27. ^ 「電子署名と記録」（PDF）。2016年3月4日時点のオリジナルよりアーカイブ（PDF） 。 2014年8月28日閲覧。
  28. ^ 「証明書の透明性」。2013年11月1日時点のオリジナルよりアーカイブ。2013年11月3日閲覧。
  29. ^ B. Laurie; A. Langley; E. Kasper (2013年6月).証明書の透明性.インターネット技術タスクフォース. doi : 10.17487/RFC6962 . ISSN 2070-1721 . RFC 6962 . 実験的。
  30. ^スミス、ディキンソン、シーモンズ 2020、p.1。
  31. ^ a bシェファー、サンタンドレ、フォッサーティ 2022、7.5。証明書の失効。
  32. ^ Chung et al. 2018、p.3。
  33. ^スミス、ディキンソン、シーモンズ 2020、10ページ。
  34. ^ラリッシュら。 2017、p. 542.
  35. ^スミス、ディキンソン、シーモンズ 2020、p.1-2。
  36. ^ 「デジタル証明書問題に対処するため、マルチベンダー電力協議会が設立」 Network World 、2013年2月14日。2013年7月28日時点のオリジナルよりアーカイブ。
  37. ^ 「主要な認証局がSSLセキュリティの名の下に団結」 Dark Reading 、2013年2月14日。2013年4月10日時点のオリジナルよりアーカイブ。
  38. ^ 「CA/Browser Forum Founder」 2007年12月3日. 2014年8月23日時点のオリジナルよりアーカイブ。 2014年8月23日閲覧。
  39. ^ 「CA/Browser Forum」。2013年5月12日時点のオリジナルよりアーカイブ。2013年4月23日閲覧。
  40. ^ Wilson, Wilson. 「CA/ブラウザフォーラムの履歴」(PDF) . DigiCert. 2013年5月12日時点のオリジナルよりアーカイブ(PDF) . 2013年4月23日閲覧。
  41. ^ 「ベースライン要件」 CABフォーラム、2013年9月4日。2014年1月7日時点のオリジナルよりアーカイブ。2017年4月14日閲覧。
  42. ^ 「Mozilla Root Store Policy」 Mozilla。2017年4月15日時点のオリジナルよりアーカイブ。2017年4月14日閲覧。
  43. ^ 「Apple Root Certificate Program」。Apple。2017年3月20日時点のオリジナルよりアーカイブ。2017年4月14日閲覧。
  44. ^ 「CA/ブラウザフォーラム、SSL/TLS証明書の有効期間を最長47日に短縮する投票を通過」 Business Wire 2025年4月14日 2025年5月13日閲覧。
  45. ^ "CA-2001-04" . Cert.org. 2001年12月31日. 2013年11月2日時点のオリジナルよりアーカイブ。 2014年6月11日閲覧。
  46. ^ Microsoft, Inc. (2007-02-21). 「Microsoft セキュリティ情報 MS01-017: VeriSign 発行の誤ったデジタル証明書がなりすましの危険性をもたらす」 2011年10月26日時点のオリジナルよりアーカイブ。 2011年11月9日閲覧。
  47. ^ Seltzer, Larry. 「SSL証明書ベンダーがMozilla.comのCSSL証明書をある人物に販売」 eWeek . 2021年12月5日閲覧。
  48. ^ Bright, Peter (2011年3月28日). 「イランの独立系ハッカー、Comodoハックの責任を主張」 Ars Technica. 2011年8月29日時点のオリジナルよりアーカイブ。 2011年9月1日閲覧。
  49. ^ Bright, Peter (2011年8月30日). 「新たな不正証明書が、証明機関に関する古くからある疑問を提起」 . Ars Technica. 2011年9月12日時点のオリジナルよりアーカイブ。 2011年9月1日閲覧。
  50. ^ Leyden, John (2011年9月6日). 「『オペレーション・ブラック・チューリップ』の内幕：DigiNotarハッキングの分析」 The Register . 2017年7月3日時点のオリジナルよりアーカイブ。
  51. ^ 「Trustwaveが中間者証明書を発行」 The H Security . 2012年2月7日. 2012年3月13日時点のオリジナルよりアーカイブ。 2012年3月14日閲覧。
  52. ^ 「Flameマルウェア衝突攻撃の説明 | MSRCブログ | Microsoftセキュリティレスポンスセンター」msrc.microsoft.com . 2023年10月13日閲覧。
  53. ^ Goodin, Dan (2012年6月7日). 「暗号技術のブレークスルーは、Flameが世界クラスの科学者によって設計されたことを示している」 Ars Technica . 2023年10月13日閲覧。
  54. ^ Fisher, Dennis (2015年3月23日). 「中国のレジストラと連携するCAが不正なGoogle証明書を発行」 . ThreatPost . 2023年9月27日閲覧。
  55. ^ Langley, Adam (2015年3月23日). 「デジタル証明書のセキュリティ維持」 . Google セキュリティブログ. 2023年9月27日閲覧。
  56. ^ローエンタール、トム (2015年3月31日). 「中国のCNNICが偽の証明書を発行、暗号資産の信頼を著しく侵害」 .ジャーナリスト保護委員会. 2023年10月13日閲覧。
  57. ^オズボーン、チャーリー. 「シマンテック、不正なGoogle証明書を発行したとしてスタッフを解雇 - ZDNet」 . ZDNet . 2016年10月2日時点のオリジナルよりアーカイブ。
  58. ^ 「不正なGoogleデジタル証明書が発見される」 linkedin.com 2014年8月12日。
  59. ^ 「インドのCA NICによる不正な証明書発行を受けて、政府CAは依然として「信頼できる第三者」とみなされるのか？」 casecurity.org 、 2014年7月24日。2016年10月3日時点のオリジナルよりアーカイブ。

引用文献

「 https://en.wikipedia.org/w/index.php?title=Certificate_authority&oldid=1336758425」より取得