Loading article…
暗号学において、公開鍵証明書（デジタル証明書またはID証明書とも呼ばれる）は、公開鍵がその所有者の身元に正しく帰属していることを証明するために使用される電子文書です。 [ 1 ] [ 2 ]証明書には、公開鍵とその情報、所有者（主体と呼ばれる）の身元に関する情報、および証明書の内容を検証したエンティティ（発行者と呼ばれる）のデジタル署名が含まれます。
証明書を検証する側が発行者を信頼し、署名がその発行者の有効な署名であると判断した場合、含まれている公開鍵を使用して証明書の主体と安全にやり取りできます。電子メールの暗号化、コード署名、および電子署名システムでは、証明書の主体は通常、個人または組織です。ただし、トランスポート層セキュリティ(TLS) では、証明書の主体は通常、コンピュータまたはその他のデバイスですが、TLS 証明書は、デバイスを識別するという中核的な役割に加えて、組織または個人を識別することもあります。TLS は、古い名前であるSecure Sockets Layer (SSL) と呼ばれることもあり、 Web を安全に閲覧するためのプロトコルであるHTTPSの一部であることで知られています。
一般的な公開鍵基盤（PKI）スキームでは、証明書の発行者は認証局（CA）[ 3 ]であり、通常は顧客から手数料を徴収して証明書を発行する企業です。対照的に、信頼のウェブスキームでは、個人が互いの鍵に直接署名し、公開鍵証明書と同様の機能を果たす形式をとります。
公開鍵証明書は通常、CSR（証明書署名要求）を使用してPKI（公開鍵基盤）から要求されます。CSRは、 CMP、EST、ACMEなどの安全な証明書登録プロトコルを使用して転送する必要があります。登録プロセスに関わる関係者は、CSRの真正性、完全性、および認証を検証する必要があり、その主な責任は証明書発行者が負います。
鍵が漏洩した場合や、不正使用につながる可能性のあるその他の状況が発生した場合は、証明書を失効させる必要がある場合があります。
公開鍵証明書と属性証明書の一般的な形式は、X.509で定義されています。公開鍵証明書については、公開鍵基盤 (X.509)などのインターネット関連のユースケース向けにIETFによって形式が規定されています。[ 4 ]
デジタル証明書システムは信頼の連鎖を提供します。つまり、ほとんどの証明書は親証明書に対して検証可能です。この連鎖はルート証明書から始まり、これが信頼のアンカー（別名：信頼のルート）として機能します。この証明書は自己署名されており（下記参照）、親証明書は存在しません。発行認証局は、この証明書を保護および検証するために他の方法を使用します。
中間証明書は、ルート証明書と同様の目的を持ち、他の証明書に署名することのみに使用されます。ただし、中間証明書は自己署名されません。ルート証明書または別の中間証明書によって署名される必要があります。
エンドエンティティ証明書、またはリーフ証明書とは、他の証明書に署名できない証明書のことです。例えば、TLS/SSLサーバー証明書とクライアント証明書、電子メール証明書、コード署名証明書、および適格証明書はすべてエンドエンティティ証明書です。
トランスポート層セキュリティ（TLS）プロトコルは、旧式のセキュアソケットレイヤー（SSL）プロトコルと同様に、クライアントコンピュータとサーバー間の通信の安全性を保証します。このプロトコルでは、サーバーがデジタル証明書を提示し、自身が本来の宛先であることを証明する必要があります。接続するクライアントは証明書パス検証を行い、以下の点を確認します。
証明書のSubjectフィールドでは、サーバーのプライマリ ホスト名を Common Name として識別する必要があります。これは、証明書に記載されている名前が、ユーザーが接続するドメイン名 (たとえば、) と完全に一致しwww.example.com、証明書がその特定のホスト名に対して有効であることを保証することを意味します。[ 5 ]ホスト名は、プライベート アドレスや予約済みドメインを使用せず、パブリックにアクセス可能である必要があります。[ 6 ]証明書は、複数のホスト名 (たとえば、ドメインとそのサブドメイン) に対して有効になる場合があります。このような証明書は、一般的にSubject Alternative Name (SAN) 証明書またはUnified Communications Certificates (UCC)と呼ばれます。これらの証明書にはSubject Alternative Nameフィールドが含まれていますが、多くの CA は下位互換性のためにSubject Common Nameフィールドにも含めています。ホスト名の一部にアスタリスク (*) が含まれている場合、証明書はワイルドカード証明書とも呼ばれます。
認証パスの検証が成功すると、クライアントはサーバーとの暗号化された接続を確立できます。
インターネットに接続するサーバー（公開Webサーバーなど）は、信頼できる公開認証局（CA）から証明書を取得する必要があります。
クライアント証明書は、TLSサービスに接続するクライアントを認証し、例えばアクセス制御を行うために使用されます。ほとんどのサービスはデバイスではなく個人にアクセスを提供するため、クライアント証明書にはホスト名ではなく、メールアドレスや個人名が含まれることがほとんどです。さらに、クライアント証明書を発行する認証局は、通常、クライアントが接続するサービスプロバイダです。これは、認証を実行する必要があるのがプロバイダだからです。
ほとんどのウェブブラウザはクライアント証明書をサポートしていますが、インターネット上で最も一般的な認証方法はユーザー名とパスワードの組み合わせです。クライアント証明書は、仮想プライベートネットワーク（VPN）やリモートデスクトップサービスでより一般的に使用されており、これらのサービスではデバイスの認証に用いられます。
S/MIMEプロトコルによれば、電子メール証明書はメッセージの完全性を証明するとともに、メッセージを暗号化することができます。暗号化された電子メール通信を確立するには、通信を行う当事者双方が事前にデジタル証明書を用意しておく必要があります。それぞれが相手にデジタル署名付きの電子メールを送信し、送信者の証明書をインポートするオプションを選択する必要があります。
一部の公的に信頼されている認証局は電子メール証明書を提供していますが、より一般的には、特定の組織内で通信する際にはS/MIMEが使用され、その組織は独自の認証局を運用しており、その認証局は当該電子メールシステムの参加者から信頼されています。
自己署名証明書とは、発行者と一致する件名を持ち、かつ自身の公開鍵で検証可能な署名を持つ証明書のことです。
この種の証明書は、見知らぬ者同士の遠隔信頼関係を確立するには役に立ちませんが、発行者と唯一の使用者が同一人物である場合は、完全な信頼価値を持ちます。前述のとおり（「信頼の連鎖」の項 を参照）、ルート証明書は自己署名証明書です。証明書の唯一の使用者である認証局は、他の手段を用いて証明書を検証し、保護します。別の例として、 Microsoft Windows の暗号化ファイルシステムがあります。これは、暗号化ユーザーに代わって自己署名証明書を発行し、それを用いてデータを透過的に復号化します。
サブジェクト代替名（SAN）証明書は、X.509の拡張機能であり、フィールドを使用してセキュリティ証明書にさまざまな値を関連付けることができます。[ 7 ]これらの値はサブジェクト代替名（SAN）と呼ばれます。名前には以下が含まれます。[ 4 ]： §4.2.1.6subjectAltName
2000 年 5 月現在、証明書に DNS 名を追加する推奨方法は Subject Alternative Names です。[ 8 ]以前の DNS 名をフィールドに入力する方法はcommonName現在非推奨となっています。[ 9 ] Google Chromeバージョン 58 (2017 年 3 月) では、フィールドのチェックのサポートが削除されcommonName、代わりに SAN のみを参照するようになりました。[ 9 ] 右側の Wikimedia セクションの画像に示すように、SAN フィールドにはワイルドカードを含めることができます。[ 10 ]すべてのベンダーが SAN 証明書にワイルドカードを混在させることをサポートまたは推奨しているわけではありません。[ 11 ]
*)ドメイン名部分にアスタリスク*（ワイルドカード）を使用する公開鍵証明書は、ワイルドカード証明書と呼ばれます。ワイルドカード証明書を使用することで、1つの証明書を複数のサブドメインに使用できます。これは、コンピュータネットワークのトランスポート層セキュリティで一般的に使用されています。*
例えば、単一のワイルドカード証明書で、ドメインhttps://*.example.com上の以下のすべてのサブドメインを保護できますhttps://*.example.com。
payment.example.comcontact.example.comlogin-secure.example.comwww.example.comサブドメインごとに個別の証明書を取得する代わりに、すべてのメインドメインとサブドメインに単一の証明書を使用することでコストを削減できます。[ 12 ]
ワイルドカードはサブドメインの 1 レベルしかカバーしないため (アスタリスクはピリオドと一致しないため)、[ 13 ]これらのドメインは証明書に対して有効ではありません: [ 14 ]
test.login.example.comexample.comCA による例外の可能性に注意してください。たとえば、DigiCert のワイルドカード プラス証明書には、ネイキッド ドメイン用の自動的な「Plus」プロパティが含まれていますexample.com。
サブドメインのマッチングは1レベルのみがサポートされています。[ 13 ] [ 15 ]
拡張検証証明書にワイルドカードを使用することはできません。[ 16 ] 回避策としては、すべての仮想ホスト名をサブジェクト代替名（SAN）拡張に追加する方法がありますが、[ 17 ] [ 18 ]大きな問題は、新しい仮想サーバーが追加されるたびに証明書を再発行する必要があることです。（詳細については、「トランスポート層セキュリティ」§ 名前ベースの仮想サーバーのサポートを参照してください。）
ワイルドカードは、マルチドメイン証明書または統合通信証明書(UCC) のドメインとして追加できます。さらに、ワイルドカード自体に、subjectAltName他のワイルドカードを含む拡張機能を持たせることができます。たとえば、ワイルドカード証明書には、サブジェクト代替名として が*.wikipedia.orgあります。これにより、まったく異なる Web サイト名も保護されます。[ 19 ]*.m.wikimedia.orgwww.wikipedia.orgmeta.m.wikimedia.org
RFC 6125は、セキュリティ上の理由からワイルドカード証明書、特に「部分的なワイルドカード」に反対している。[ 20 ]
ワイルドカードはドメイン名の 1 つのレベルにのみ適用されます。*.example.com一致しますsub1.example.comが、example.com一致しません。sub2.sub1.domain.com
初期の仕様[ 8 ]では、ワイルドカードは「部分ワイルドカード」としてラベル内のどこにでも出現することが許可されていました。
f*.domain.com大丈夫です。一致しますfrog.domain.comが、frog.super.domain.combaz*.example.net問題ありませんし、一致していますbaz1.example.net*baz.example.net問題ありませんし、一致していますfoobaz.example.netb*z.example.net問題ありませんし、一致していますbuzz.example.netただし、「部分ワイルドカード」証明書の使用は推奨されません。2011 年現在、部分ワイルドカードのサポートはオプションであり、マルチネーム証明書に必要な SubjectAltName ヘッダーでは明示的に禁止されています。[ 21 ] : §6.3主要なブラウザはすべて、意図的に部分ワイルドカード証明書のサポートを削除しています。 [ 22 ] [ 23 ]これにより、「SSL_ERROR_BAD_CERT_DOMAIN」エラーが発生します。同様に、プログラミング言語の標準ライブラリが「部分ワイルドカード」証明書をサポートしないのが一般的です。たとえば、「部分ワイルドカード」証明書は、最新バージョンの Python [ 24 ]と Go の両方で動作しません。したがって、
最も左端のラベルでない限り、ワイルドカードのみで構成されるラベルは許可しないでください。
sub1.*.domain.com許可されていません。名前に複数のワイルドカードを含む証明書は許可されていません。
*.*.domain.com*トップレベルドメインを含む証明書は許可されていません。
*.comあまりにも一般的すぎるので、許可すべきではない。
*ASCIIでエンコードされた国際ドメイン名（Aラベル）は、ASCIIエンコードされ、で始まるラベルですxn--。国際ラベルを持つURLにはワイルドカードを含めることはできません。[ 25 ]
xn--caf-dma.comはcafé.comxn--caf-dma*.com許可されていませんLw*.xn--caf-dma.com許可されていますこれらは証明書でよく使われるフィールドの一部です。ほとんどの証明書には、ここに記載されていないフィールドが多数含まれています。なお、証明書のX.509表現においては、証明書は「フラット」ではなく、これらのフィールドが証明書内の様々な構造の中にネストされていることに注意してください。
これは、SSL.com の Web サイトから取得した、復号化された SSL/TLS 証明書の例です。発行者の共通名 (CN) は と表示されておりSSL.com EV SSL Intermediate CA RSA R3、これが拡張検証(EV) 証明書であることを示しています。Web サイトの所有者 (SSL Corp) に関する検証済みの情報は にありますSubject。X509v3 Subject Alternative Nameには、証明書でカバーされているドメイン名のリストが含まれています。X509v3 Extended Key UsageおよびX509v3 Key Usageフィールドには、すべての適切な使用例が表示されます。
証明書： データ： バージョン: 3 (0x2) シリアルナンバー： 72:14:11:d3:d7:e0:fd:02:aa:b0:4e:90:09:d4:db:31 署名アルゴリズム：sha256WithRSAEncryption 発行者: C=米国、ST=テキサス州、L=ヒューストン、O=SSL Corp、CN=SSL.com EV SSL中間認証局 RSA R3 有効 期限：2019年4月18日 22:15:06 GMT 期限：2021年4月17日 22:15:06 GMT 件名: C=米国、ST=テキサス州、L=ヒューストン、O=SSL Corp/シリアル番号=NV20081614243、CN=www.ssl.com/郵便番号=77098/事業区分=民間組織/住所=3100 Richmond Ave/管轄ST=ネバダ州/管轄C=米国 主題公開鍵情報: 公開鍵暗号アルゴリズム：rsa暗号化 RSA公開鍵：（2048ビット） モジュラス: 00:ad:0f:ef:c1:97:5a:9b:d8:1e ... 指数: 65537 (0x10001) X509v3拡張機能： X509v3認証局キー識別子： キーID:BF:C1:5A:87:FF:28:FA:41:3D:FD:B7:4F:E4:1D:AF:A0:61:58:29:BD 権限情報へのアクセス: CA発行者 - URI: http://www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt OCSP - URI: http://ocsps.ssl.com X509v3 サブジェクト代替名: DNS:www.ssl.com、DNS:answers.ssl.com、DNS:faq.ssl.com、DNS:info.ssl.com、DNS:links.ssl.com、DNS:reseller.ssl.com、DNS:secure.ssl.com、DNS:ssl.com、DNS:support.ssl.com、DNS:sws.ssl.com、DNS:tools.ssl.com X509v3証明書ポリシー： ポリシー: 2.23.140.1.1 ポリシー: 1.2.616.1.113527.2.5.1.1 ポリシー: 1.3.6.1.4.1.38064.1.1.1.5 CPS: https://www.ssl.com/repository X509v3拡張キー使用法： TLS Webクライアント認証、TLS Webサーバー認証 X509v3 CRL配布ポイント： フルネーム： URI: http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl X509v3 サブジェクトキー識別子: E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B X509v3キーの使用法: 重要 デジタル署名、鍵暗号化 CT事前認定SCT： 署名済み証明書のタイムスタンプ： バージョン：v1（0x0） ログID：87:75:BF:E7:59:7C:F8:8C:43:99 ... タイムスタンプ：2019年4月18日 22:25:08.574 GMT 拡張機能：なし 署名: ecdsa-with-SHA256 30:44:02:20:40:51:53:90:C6:A2 ... 署名済み証明書のタイムスタンプ： バージョン：v1（0x0） ログ ID : A4:B9:09:90:B4:18:58:14:87:BB ... タイムスタンプ：2019年4月18日 22:25:08.461 GMT 拡張機能：なし 署名: ecdsa-with-SHA256 30:45:02:20:43:80:9E:19:90:FD ... 署名済み証明書のタイムスタンプ： バージョン：v1（0x0） ログID：55:81:D4:C2:16:90:36:01:4A:EA ... タイムスタンプ：2019年4月18日 22:25:08.769 GMT 拡張機能：なし 署名: ecdsa-with-SHA256 30:45:02:21:00:C1:3E:9F:F0:40 ... 署名アルゴリズム：sha256WithRSAEncryption 36:07:e7:3b:b7:45:97:ca:4d:6c ...
欧州連合では、法的文書への（高度な）電子署名は、身分証明書を添付したデジタル署名を用いて行われるのが一般的です。ただし、物理的な署名と同等の効力を持つのは、適格な電子署名（適格な信頼サービスプロバイダーと署名作成デバイスの使用が必要なもの）のみです。
X.509トラスト モデルでは、認証局 (CA) が証明書の署名を担当します。これらの証明書は 2 当事者間の仲介役として機能し、つまり CA は信頼できる第三者として機能します。CA は、証明書を要求する個人または組織 (サブスクライバーと呼ばれる) からの要求を処理し、情報を検証し、その情報に基づいてエンド エンティティ証明書に署名する場合があります。この役割を効果的に果たすには、CA は、広く信頼されている 1 つ以上のルート証明書または中間証明書と、それに対応する秘密鍵を持っている必要があります。CA は、ルート証明書を一般的なソフトウェアに含めるか、信頼を委任する別の CA から相互署名を取得することによって、この広範な信頼を得ることができます。他の CA は、企業などの比較的小規模なコミュニティ内で信頼されており、Windowsグループ ポリシーなどの他のメカニズムによって配布されます。
認証局は、発行した証明書の最新の失効情報を維持し、証明書がまだ有効かどうかを示す責任も負っています。認証局は、オンライン証明書ステータスプロトコル（OCSP）および/または証明書失効リスト（CRL）を通じてこの情報を提供します。市場における主要な認証局には、IdenTrust、DigiCert、Sectigoなどがあります。[ 29 ]
主要なソフトウェアの中には、デフォルトで信頼されている認証局のリストが含まれているものがあります。これにより、エンドユーザーは証明書の検証が容易になり、証明書を要求する個人や組織は、広く信頼される証明書を発行できる認証局を簡単に把握できます。これは特にHTTPSにおいて重要です。HTTPSでは、ウェブサイト運営者は一般的に、ウェブサイトへのほぼすべての潜在的な訪問者から信頼される証明書を取得したいと考えるからです。
プロバイダーが自社ソフトウェアが信頼すべき認証局を決定するために使用するポリシーとプロセスは、ルートプログラムと呼ばれます。最も影響力のあるルートプログラムは次のとおりです。
Firefox以外のブラウザは、一般的にオペレーティングシステムの機能を使用して、どの認証局を信頼するかを決定します。たとえば、Windows上のChromeはMicrosoft Root Programに含まれる認証局を信頼しますが、macOSまたはiOS上のChromeはApple Root Programの認証局を信頼します。[ 30 ] EdgeとSafariもそれぞれのオペレーティングシステムのトラストストアを使用しますが、それぞれ1つのOSでのみ利用可能です。FirefoxはすべてのプラットフォームでMozilla Root Programのトラストストアを使用します。
Mozilla Root Program は公開されており、その証明書リストはオープンソースのFirefox Web ブラウザの一部であるため、Firefox 以外でも広く使用されています。たとえば、共通の Linux Root Program はありませんが、Debian [ 31 ]のような多くの Linux ディストリビューションには、 Firefox の信頼リストの内容を定期的にコピーするパッケージが含まれており、アプリケーションで使用されます。
ルート証明書プログラムは通常、含まれる証明書に有効な用途のセットを提供します。たとえば、一部の認証局はTLSサーバー証明書の発行には信頼されているものの、コード署名証明書の発行には信頼されていない場合があります。これは、ルート証明書ストレージシステム内の信頼ビットのセットによって示されます。
証明書は有効期限が切れる前に失効させることができ、これは証明書がもはや有効ではないことを示します。失効がなければ、攻撃者は有効期限が切れるまで、侵害された、または誤って発行された証明書を悪用することができます。[ 32 ]したがって、失効は公開鍵インフラストラクチャの重要な部分です。[ 33 ]失効は発行認証局によって実行され、認証局は暗号的に認証された失効ステートメントを作成します。[ 34 ]
クライアントに失効情報を配信する場合、失効の発見の適時性（したがって、攻撃者が侵害された証明書を悪用できる期間）は、失効ステータスの照会におけるリソース使用量やプライバシーの懸念とトレードオフの関係にある。[ 35 ]失効情報が利用できない場合（事故または攻撃による）、クライアントは、証明書が失効しているかのように扱う（可用性が低下する）か、失効していないかのように扱う（攻撃者が失効を回避できるようにする）かを決定する必要がある。[ 36 ]
失効チェックのコストと、信頼性の低い可能性のあるリモートサービスによる可用性への影響のため、Web ブラウザは失効チェックの実行を制限し、実行する場合はフェイルソフトで処理します。[ 37 ]証明書失効リストは、日常的に使用するには帯域幅のコストが高すぎ、オンライン証明書ステータスプロトコルは接続遅延とプライバシーの問題を引き起こします。フェイルハードチェックを可能にするための他のスキームが提案されていますが、まだ正常に展開されていません。[ 33 ]
証明書の最も一般的な用途は、HTTPSベースの Web サイトです。WebブラウザはHTTPS Web サーバーが正規のものであることを確認するため、ユーザーはWeb サイトとのやり取りに盗聴者がおらず、Web サイトが主張どおりのものであると安心して利用できます。このセキュリティは電子商取引において重要です。実際には、Web サイト運営者は証明書署名要求を認証局に申請することで証明書を取得します。証明書要求は、Web サイト名、会社情報、公開鍵を含む電子文書です。証明書プロバイダーは要求に署名し、公開証明書を発行します。Web ブラウジング中、この公開証明書は Web サイトに接続するすべての Web ブラウザに提供され、プロバイダーが Web サイトの所有者に証明書を発行したと確信していることを Web ブラウザに証明します。
例えば、ユーザーがhttps://www.example.com/ブラウザで接続した際に、ブラウザが証明書の警告メッセージを表示しない場合、たとえhttps://www.example.com/そのメールアドレスがウェブサイト上に表示されていなくても、ユーザーは、ウェブサイトとのやり取りが、公開レジストラに「example.com」として登録されているメールアドレスを持つエンティティとのやり取りと同等であると理論的に確信できます。それ以外のいかなる保証も暗示されるものではありません。さらに、証明書の購入者、ウェブサイトの運営者、およびウェブサイトのコンテンツ生成者の間の関係は希薄である可能性があり、保証されません。せいぜい、証明書はウェブサイト自体が侵害（ハッキング）されていない、または証明書の発行プロセスが不正に操作されていないことを条件として、ウェブサイトの一意性を保証するものです。
証明書発行者は、それぞれ異なる審査基準を必要とする3種類の証明書を発行することができます。審査基準が厳しくなる順（そして当然ながらコストも高くなる順）に、ドメイン検証、組織検証、拡張検証の3種類があります。これらの審査基準は、CA/Browser Forumの自主的な参加者によって大まかに合意されています。
証明書プロバイダーは、購入者が審査基準の1つ、すなわち対象となるDNSドメインを管理的に管理する権利を証明できる場合に、ドメイン検証済み（DV）証明書を発行します。
証明書プロバイダーは、購入者が以下の2つの基準を満たしている場合に、組織検証（OV）クラスの証明書を発行します。1つ目は、当該ドメイン名を管理する権限を有すること、2つ目は、組織が実際に法人格を有することです。証明書プロバイダーは、証明書ポリシーを通じてOV審査基準を公開します。
拡張検証（EV）証明書を取得するには、購入者は証明書発行機関に対し、自らの法的身元を証明する必要があり、これには人間の手による検証チェックも含まれます。OV証明書と同様に、証明書発行機関は証明書ポリシーを通じてEV証明書の審査基準を公開します。
2019 年までは、Chrome や Firefox などの主要ブラウザは、サイトが EV 証明書を提示すると、ユーザーに法的身元を視覚的に表示するのが一般的でした。これは、ドメインの前に法的名称を表示し、変更を強調するために明るい緑色を使用することで実現されていました。ほとんどのブラウザはこの機能を廃止し[ 38 ] [ 39 ]、使用されている証明書の種類についてユーザーに視覚的な違いを提供しなくなりました。この変更は、フォレンジック専門家によって提起されたセキュリティ上の懸念と、有名な組織になりすますために EV 証明書を購入しようとした試みが成功したことを受けてのもので、これらの視覚的表示の非効率性が証明され、潜在的な悪用が浮き彫りになりました。[ 40 ]
ウェブブラウザは、ウェブサイトが突然別の証明書を提示した場合、たとえその証明書の鍵ビット数が少なくても、たとえ提供元が異なっていても、たとえ以前の証明書の有効期限がはるか未来であっても、ユーザーに警告を発しません。証明書提供者が政府の管轄下にある場合、政府は、例えば法執行目的など、提供者に任意の証明書を生成するよう命じる自由を持つ可能性があります。子会社の卸売証明書提供者も、任意の証明書を生成する自由を持っています。
すべてのウェブ ブラウザには、信頼できるルート証明書の広範な組み込みリストが付属しており、その多くはユーザーに馴染みのない組織によって管理されています。[ 1 ] これらの組織はそれぞれ、任意の Web サイトに対して任意の証明書を発行することができ、そのルート証明書を含むウェブ ブラウザがそれを正規のものとして受け入れるという保証を得ています。この場合、エンド ユーザーは、ブラウザ ソフトウェアの開発者が組み込みの証明書リストを管理すること、および証明書プロバイダーが正しく動作し、問題のある証明書をブラウザの開発者に通知することに頼らなければなりません。まれではありますが、不正な証明書が発行された事例があり、場合によってはブラウザが不正を検出しましたが、他のケースでは、ブラウザの開発者がこれらの証明書をソフトウェアから削除するまでに時間がかかりました。[ 41 ] [ 42 ]
組み込み証明書のリストは、ブラウザ開発者が提供するものに限定されません。ユーザー（およびある程度アプリケーション）は、社内イントラネットなどの特別な目的のためにリストを拡張することができます。[ 43 ] これは、誰かがマシンにアクセスしてブラウザに新しいルート証明書をインストールできる場合、そのブラウザは挿入された証明書を使用するWebサイトを正当なものとして認識することを意味します。
証明可能なセキュリティのためには、システム外部の何かに依存することで、公開鍵認証方式は認証局の存在など、何らかの特別な設定の前提に頼らざるを得なくなるという結果が生じる。[ 44 ]
上記の制限にもかかわらず、証明書認証TLSは、Webサイトが機密情報をホストしたり、重要な取引を実行したりする場合には、すべてのセキュリティガイドラインで必須とみなされています。これは、実際には、上記の弱点にもかかわらず、公開鍵証明書で保護されたWebサイトは、保護されていないhttp:// Webサイトよりも安全であるためです。[ 45 ]
米国国立標準技術研究所（NIST）のコンピュータセキュリティ部門[ 46 ]は、公開鍵証明書に関するガイダンス文書を提供しています。
証明書ではワイルドカード証明書は許可されていません。
この文書では、ワイルドカード文字 '*' は提示された識別子に含めるべきではないが、アプリケーション クライアントによってチェックされる可能性がある (主に展開済みのインフラストラクチャとの下位互換性のため) と述べています。 [...] いくつかのセキュリティ上の考慮事項により、ルールを厳格化することが正当化されます。 [...]