公開鍵証明書

暗号化において、公開鍵証明書はデジタル証明書または身元証明書とも呼ばれ、公開鍵の有効性を証明するために使用される電子文書です。^{[1] [2]}証明書には、公開鍵とそれに関する情報、所有者の身元に関する情報（サブジェクトと呼ばれる）、および証明書の内容を検証したエンティティ（発行者と呼ばれる）のデジタル署名が含まれます。証明書を検査するデバイスが発行者を信頼し、署名がその発行者の有効な署名であると判断した場合、証明書に含まれる公開鍵を使用して証明書のサブジェクトと安全に通信できます。電子メールの暗号化、コード署名、および電子署名システムでは、証明書のサブジェクトは通常、個人または組織です。ただし、トランスポート層セキュリティ（TLS）では、証明書のサブジェクトは通常、コンピューターまたはその他のデバイスですが、TLS証明書は、デバイスの識別という主要な役割に加えて、組織または個人を識別する場合があります。 TLS は、古い名前であるSecure Sockets Layer (SSL) と呼ばれることもあり、Web を安全に閲覧するためのプロトコルであるHTTPSの一部であることで知られています。

一般的な公開鍵基盤（PKI）方式では、証明書の発行者は証明機関（CA）^[3]であり、通常は顧客に証明書の発行料を請求する会社です。対照的に、信頼のウェブ方式では、個人が互いの鍵に直接署名し、公開鍵証明書と同様の機能を果たす形式をとります。鍵が侵害された場合、証明書を取り消す必要がある場合があります。

公開鍵証明書の最も一般的な形式は、X.509で定義されています。 X.509 は非常に一般的なため、その形式は、 RFC 5280で定義されている公開鍵インフラストラクチャ (X.509)など、特定のユースケース向けに定義されたプロファイルによってさらに制約されます 。

トランスポート層セキュリティ(TLS)プロトコルは、その旧式のSecure Sockets Layer (SSL) プロトコルと同様に、クライアント コンピューターとサーバー間の通信が安全であることを保証します。このプロトコルでは、サーバーが目的の送信先であることを証明するデジタル証明書を提示する必要があります。接続クライアントは、証明書パス検証を実行して、次のことを確認します。

1. 証明書のサブジェクトは、クライアントが接続しようとしているホスト名(ドメイン名と混同しないでください) と一致します。
2. 信頼できる証明機関が証明書に署名しました。

証明書のサブジェクトフィールドには、サーバーのプライマリ ホスト名が共通名として指定されている必要があります。^{[説明が必要]}ホスト名は、プライベート アドレスや予約済みドメインではなく、パブリックにアクセス可能である必要があります。^[4]証明書は、複数のホスト名 (ドメインとそのサブドメインなど) に対して有効な場合があります。このような証明書は、一般にサブジェクト別名 (SAN) 証明書または統合コミュニケーション証明書 (UCC)と呼ばれます。これらの証明書にはサブジェクト別名フィールドが含まれますが、多くの CA は下位互換性のためにサブジェクト共通名フィールドにもこれを配置します。ホスト名の一部にアスタリスク (*) が含まれる場合、証明書はワイルドカード証明書と呼ばれることもあります。

証明書パスの検証が成功すると、クライアントはサーバーとの暗号化された接続を確立できます。

パブリックWeb サーバーなどのインターネットに接続されたサーバーは、信頼できるパブリック証明機関 (CA) から証明書を取得する必要があります。

クライアント証明書は、アクセス制御などのために、TLS サービスに接続するクライアントを認証します。ほとんどのサービスはデバイスではなく個人へのアクセスを提供するため、ほとんどのクライアント証明書にはホスト名ではなく電子メール アドレスまたは個人名が含まれています。さらに、クライアント証明書を発行する証明機関は通常、クライアントが接続するサービス プロバイダーです。これは、認証を実行する必要があるのはプロバイダーだからです。一部のサービス プロバイダーは、パッケージの一部として無料の SSL 証明書を提供しています。^[5]

ほとんどの Web ブラウザーはクライアント証明書をサポートしていますが、インターネット上で最も一般的な認証形式は、ユーザー名とパスワードのペアです。クライアント証明書は、デバイスを認証する仮想プライベート ネットワーク(VPN) やリモート デスクトップ サービスでより一般的です。

S/MIMEプロトコルに従って、電子メール証明書はメッセージの整合性を確立し、メッセージを暗号化することができます。暗号化された電子メール通信を確立するには、通信する側が事前にデジタル証明書を持っている必要があります。各通信者は、相手にデジタル署名された電子メールを送信し、送信者の証明書をインポートすることを選択する必要があります。

一部の公的に信頼されている証明機関は電子メール証明書を提供していますが、より一般的には、特定の組織内で通信するときに S/MIME が使用され、その組織は独自の CA を実行し、その CA は電子メール システムの参加者によって信頼されます。

自己署名証明書とは、発行者と一致するサブジェクトと、独自の公開鍵で検証できる署名を持つ証明書です。

自己署名証明書には、独自の限定された用途があります。発行者と唯一のユーザーが同じエンティティである場合、自己署名証明書は完全な信頼値を持ちます。たとえば、Microsoft Windows の暗号化ファイル システムは、暗号化ユーザーに代わって自己署名証明書を発行し、それを使用してデータを透過的にオンザフライで復号化します。デジタル証明書の信頼チェーンは、ルート証明書、トラスト アンカー、またはトラスト ルートと呼ばれる自己署名証明書から始まります。証明機関は、他の証明書に署名できるように、ルート証明書に自己署名します。

中間証明書の目的はルート証明書と同様で、他の証明書に署名するためだけに使用されます。ただし、中間証明書は自己署名されません。ルート証明書または別の中間証明書で署名する必要があります。

エンド エンティティ証明書またはリーフ証明書は、他の証明書に署名できない証明書です。たとえば、TLS/SSL サーバー証明書とクライアント証明書、電子メール証明書、コード署名証明書、および認定証明書はすべてエンド エンティティ証明書です。

サブジェクト代替名（SAN）証明書は、X.509の拡張機能であり、フィールドを使用してさまざまな値をセキュリティ証明書に関連付けることができます。^{[6]これらの値は}サブジェクト代替名（SAN）と呼ばれます。名前には次のものがあります。^[7]subjectAltName

• メールアドレス
• IPアドレス
• URI
• DNS 名: これは通常、メイン証明書のサブジェクト フィールド内の共通名RDNとしても提供されます。
• ディレクトリ名:件名に指定された識別名の代替。
• 一般名またはユニバーサル プリンシパル名として指定されるその他の名前: 登録されたオブジェクト識別子とそれに続く値。

RFC  2818 (2000年5月) では、証明書にDNS名を追加する推奨方法としてサブジェクト代替名を指定しており、フィールドにDNS名を入力する以前の方法は非推奨となっていますcommonName。^[8] Google Chromeバージョン58 (2017年3月) では、commonNameフィールドのチェックがまったくサポートされなくなり、代わりにSANのみがチェックされるようになりました。^[8]

右のWikimediaのセクションの図に示されているように、SANフィールドにはワイルドカードを含めることができます。^[9]すべてのベンダーがSAN証明書にワイルドカードを混在させることをサポートまたは推奨しているわけではありません。^[10]

ドメイン名のフラグメントにアスタリスク *(ワイルドカード)を使用する公開鍵証明書は、ワイルドカード証明書と呼ばれます。 を使用することで、1 つの証明書を複数のサブドメインに使用できます。 これは、コンピュータ ネットワークのトランスポート層セキュリティによく使用されます。 *

たとえば、単一のワイルドカード証明書は、ドメインhttps://*.example.com上の次のすべてのサブドメインを保護しますhttps://*.example.com。

• payment.example.com
• contact.example.com
• login-secure.example.com
• www.example.com

サブドメインごとに個別の証明書を取得する代わりに、すべてのメインドメインとサブドメインに単一の証明書を使用してコストを削減できます。^[11]

ワイルドカードはサブドメインの1つのレベルのみをカバーするため（アスタリスクはピリオドと一致しない）、^[12]これらのドメインは証明書には有効ではありません：^[13]

• test.login.example.com
• example.com

CA による例外の可能性に注意してください。たとえば、DigiCert のワイルドカードプラス証明書には、ネイキッド ドメインの自動的な「Plus」プロパティが含まれていますexample.com。^{[引用が必要]}

RFC  2818に従って、サブドメインマッチングは単一レベルのみがサポートされています^。[1]

拡張検証証明書にワイルドカードを使用することはできません。^{[14]回避策としては、}サブジェクト別名（SAN）拡張 にすべての仮想ホスト名を追加することが考えられますが、 ^{[15] [16]}大きな問題は、新しい仮想サーバーが追加されるたびに証明書を再発行する必要があることです。（詳細については、 「トランスポート層セキュリティ § 名前ベースの仮想サーバーのサポート」を参照してください。）

ワイルドカードは、マルチドメイン証明書またはユニファイドコミュニケーション証明書（UCC）のドメインとして追加できます。さらに、ワイルドカード自体に、subjectAltName他のワイルドカードを含む拡張子を持たせることができます。たとえば、ワイルドカード証明書にはサブジェクト代替名*.wikipedia.orgがあります。したがって、完全に異なるWebサイト名と同様に*.m.wikimedia.org保護されます。^[17]www.wikipedia.orgmeta.m.wikimedia.org

RFC  6125は、セキュリティ上の理由からワイルドカード証明書、特に「部分的なワイルドカード」に反対している。^[18]

ワイルドカードはドメイン名の1レベルにのみ適用されます*.example.com。sub1.example.comexample.comsub2.sub1.domain.com

ワイルドカードは、初期の仕様によれば「部分的なワイルドカード」としてラベル内のどこにでも現れる可能性がある^[19]

f*.domain.com大丈夫です。一致はしますfrog.domain.comがfrog.super.domain.com

baz*.example.netOKで一致しますbaz1.example.net

*baz.example.netOKで一致しますfoobaz.example.net

b*z.example.netOKで一致しますbuzz.example.net

ただし、「部分ワイルドカード」証明書の使用は推奨されません。2011 年現在、部分ワイルドカードのサポートはオプションであり、マルチネーム証明書に必要な SubjectAltName ヘッダーでは明示的に禁止されています。^[20]すべての主要ブラウザは、部分ワイルドカード証明書のサポートを意図的に削除しました。 ^{[21] [22]}部分ワイルドカード証明書を使用すると、「SSL_ERROR_BAD_CERT_DOMAIN」エラーが発生します。同様に、プログラミング言語の標準ライブラリでは、「部分ワイルドカード」証明書をサポートしないのが一般的です。たとえば、「部分ワイルドカード」証明書は、Python ^[23]と Go の最新バージョンでは機能しません。したがって、

一番左のラベルでない限り、ワイルドカードのみで構成されたラベルを許可しない

sub1.*.domain.comは許可されません。

名前に複数のワイルドカードが含まれる証明書は許可されません。

*.*.domain.com

*トップレベルドメイン を含む証明書は許可されません。

*.com

あまりに一般的すぎるので許可されるべきではありません。

*

ASCIIでエンコードされた国際ドメイン名（Aラベル）は、ASCIIでエンコードされ、で始まるラベルですxn--。国際ラベルのURLにはワイルドカードを含めることはできません。^[24]

xn--caf-dma.comはcafé.com

xn--caf-dma*.com許可されていません

Lw*.xn--caf-dma.com許可されている

• EMV証明書：EMVは、決済カード、決済端末、自動現金自動預け払い機（ATM）の技術標準に基づいた決済方法です。EMV決済カードには、決済取引中に決済カードの真正性を検証するために、EMV認証局^[25]によって署名されたカード発行者証明書がプリロードされています。
• コード署名証明書: 証明書はアプリ(またはそのバイナリ) を検証し、配信中に改ざんされていないことを確認できます。
• 認定証明書: 個人を識別する証明書で、通常は電子署名のために使用されます。これらは、 eIDAS規制によって標準化され、その承認が義務付けられているヨーロッパで最も一般的に使用されています。
• ロールベースの証明書:連邦ブリッジ認証局 (FBCA) のX.509証明書ポリシーで定義されているように、ロールベースの証明書は「加入者の名前ではなく、加入者が代理で行動することを許可されている特定の役割を識別し、承認されたビジネス慣行をサポートするために発行されます。」^[26]
• グループ証明書:連邦ブリッジ認証局 (FBCA) のX.509証明書ポリシーで定義されており、「複数のエンティティが 1 つの立場で行動し、トランザクションの否認不可性が望まれない場合」に使用されます。^[27]

これらは、証明書で最も一般的なフィールドの一部です。ほとんどの証明書には、ここに記載されていないフィールドが多数含まれています。証明書の X.509 表現の観点から見ると、証明書は「フラット」ではなく、証明書内のさまざまな構造にネストされたこれらのフィールドが含まれていることに注意してください。

• シリアル番号: CA のシステム内で証明書を一意に識別するために使用されます。特に、失効情報を追跡するために使用されます。
• サブジェクト: 証明書が属するエンティティ: マシン、個人、または組織。
• 発行者: 情報を検証し、証明書に署名したエンティティ。
• 指定日以前: 証明書が有効になる最も早い日時。通常は、クロック スキューの問題を回避するために、証明書が発行された時点の数時間前または数日前に設定されます。
• 有効期間: 証明書が有効でなくなる日時。
• キーの使用法: 証明書の公開キーの有効な暗号化の使用。一般的な値には、デジタル署名の検証、キーの暗号化、証明書の署名など​​があります。
• 拡張キー使用法: 証明書が使用される可能性のあるアプリケーション。一般的な値には、TLS サーバー認証、電子メール保護、コード署名などがあります。
• 公開鍵: 証明書の主体に属する公開鍵。
• 署名アルゴリズム: ハッシュ アルゴリズムとデジタル署名アルゴリズムが含まれます。たとえば、「sha256RSA」の場合、sha256 はハッシュ アルゴリズムで、RSA は署名アルゴリズムです。
• 署名: 証明書の本文がハッシュ化され (「署名アルゴリズム」フィールドのハッシュ アルゴリズムが使用される)、ハッシュが発行者の秘密キーを使用して署名されます (「署名アルゴリズム」フィールドの署名アルゴリズムが使用される)。

これは、SSL.com の Web サイトから取得したデコードされた SSL/TLS 証明書の例です。発行者の共通名 (CN) は として表示されSSL.com EV SSL Intermediate CA RSA R3、これがExtended Validation (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=US、ST=テキサス、L=ヒューストン、O=SSL Corp、CN=SSL.com EV SSL 中間 CA RSA R3
        有効
            以前: 2019年4月18日 22:15:06 GMT
            それ以降 : 2021年4月17日 22:15:06 GMT
        件名: C=US、ST=テキサス、L=ヒューストン、O=SSL Corp/serialNumber=NV20081614243、CN=www.ssl.com/postalCode=77098/businessCategory=Private Organization/street=3100 Richmond Ave/jurisdictionST=ネバダ/jurisdictionC=US
        サブジェクト公開鍵情報:
            公開鍵アルゴリズム: rsaEncryption
                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
                  プライバシーポリシー: 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などがあります。^[28]

一部の主要ソフトウェアには、デフォルトで信頼されている証明機関のリストが含まれています。^{[引用が必要]}これにより、エンド ユーザーは証明書を検証しやすくなり、証明書を要求する個人または組織は、どの証明機関が広く信頼される証明書を発行できるかを知ることが容易になります。これは、Web サイトの運営者が通常、Web サイトへのほぼすべての潜在的な訪問者から信頼される証明書を取得したいと考える HTTPS では特に重要です。

プロバイダーがソフトウェアがどの証明機関を信頼すべきかを決定するために使用するポリシーとプロセスをルート プログラムと呼びます。最も影響力のあるルート プログラムは次のとおりです。^{[引用が必要]}

• Microsoft ルート プログラム
• Apple ルートプログラム
• Mozilla ルート プログラム
• Oracle Javaルートプログラム
• Adobe AATL Adob​​e Approved Trust List および EUTL ルート プログラム (ドキュメントの署名に使用)

Firefox以外のブラウザは、一般的にオペレーティングシステムの機能を使用して、どの証明機関が信頼されるかを決定します。そのため、たとえば、Windows上のChromeはMicrosoft Root Programに含まれる証明機関を信頼しますが、macOSまたはiOS上のChromeはApple Root Programの証明機関を信頼します。^[29] EdgeとSafariもそれぞれのオペレーティングシステムの信頼ストアを使用しますが、それぞれ単一のOSでのみ使用できます。FirefoxはすべてのプラットフォームでMozilla Root Program信頼ストアを使用します。

Mozilla ルート プログラムは公開されて運用されており、その証明書リストはオープン ソースのFirefox ウェブ ブラウザーの一部であるため、Firefox 以外でも広く使用されています。^{[引用が必要]}たとえば、共通の Linux ルート プログラムはありませんが、Debian などの多くの Linux ディストリビューション^[30]には、Firefox 信頼リストの内容を定期的にコピーするパッケージが含まれており、アプリケーションによって使用されます。

ルート プログラムは通常、含まれている証明書に有効な目的のセットを提供します。たとえば、一部の CA は TLS サーバー証明書の発行については信頼されていると見なされますが、コード署名証明書については信頼されていないと見なされる場合があります。これは、ルート証明書ストレージ システムの信頼ビットのセットで示されます。

証明書は有効期限が切れる前に失効される可能性があり、これは証明書がもはや有効ではないことを示します。失効が行われないと、攻撃者は有効期限が切れるまで、侵害された証明書や誤って発行された証明書を悪用することができます。^{[31]したがって、失効は}公開鍵インフラストラクチャの重要な部分です。^[32]失効は発行証明機関によって実行され、暗号的に認証された失効ステートメントを作成します。^[33]

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

失効チェックのコストと、信頼性の低いリモートサービスによる可用性への影響を考慮して、Webブラウザは失効チェックを制限し、失効チェックを行う場合はフェイルソフトにします。^[36] 証明書失効リストは、日常的に使用するには帯域幅のコストがかかりすぎ、オンライン証明書ステータスプロトコルは接続の遅延とプライバシーの問題を引き起こします。フェイルハードチェックを可能にする他のスキームも提案されていますが、まだうまく導入されていません。^[32]

証明書の最も一般的な用途は、HTTPSベースの Web サイトです。Webブラウザーは、 HTTPS Web サーバーが本物であることを検証します。これにより、ユーザーは、 Web サイトとのやり取りに盗聴者がおらず、Web サイトが主張するとおりのものであると安心できます。このセキュリティは、電子商取引にとって重要です。実際には、Web サイトの運営者は、証明書署名要求を証明機関に申請して証明書を取得します。証明書要求は、Web サイト名、会社情報、公開キーを含む電子文書です。証明書プロバイダーは要求に署名し、公開証明書を作成します。Web ブラウジング中に、この公開証明書は、Web サイトに接続するすべての Web ブラウザーに提供され、プロバイダーが Web サイトの所有者に証明書を発行したと考えていることを Web ブラウザーに証明します。

たとえば、ユーザーがhttps://www.example.com/ブラウザで に接続したときに、ブラウザが証明書の警告メッセージを表示しない場合、ユーザーは、 とのやり取りが、https://www.example.com/パブリック レジストラの「example.com」にリストされている電子メール アドレスと連絡を取っているエンティティとのやり取りと同等であると理論的に確信できます。ただし、その電子メール アドレスは Web サイトのどこにも表示されていない可能性があります。^{[引用が必要]}その他のいかなる種類の保証も暗示されていません。さらに、証明書の購入者、Web サイトの運営者、および Web サイト コンテンツの生成者との関係は希薄である可能性があり、保証されていません。^{[引用が必要]}せいぜい、証明書は、Web サイト自体が侵害 (ハッキング) されていないか、証明書の発行プロセスが破壊されていないことを条件に、Web サイトの一意性を保証します。

証明書プロバイダーは、それぞれに独自の審査の厳しさが必要な 3 種類の証明書を発行できます。厳しさ (および当然コスト) が増す順に並べると、ドメイン検証、組織検証、拡張検証となります。これらの厳しさは、CA/ブラウザ フォーラムの自主的な参加者によって緩やかに合意されています。^{[引用が必要]}

購入者が 1 つの審査基準 (影響を受ける DNS ドメインを管理する権限) を証明できる場合、証明書プロバイダーは購入者にドメイン検証 (DV) 証明書を発行します。

証明書プロバイダーは、購入者が 2 つの基準 (問題のドメイン名を管理する権利、およびおそらく組織が法人として実際に存在していること) を満たす場合、購入者に組織検証 (OV) クラスの証明書を発行します。証明書プロバイダーは、証明書ポリシーを通じて OV 審査基準を公開します。

拡張認証(EV) 証明書を取得するには、購入者は、人間による手動検証チェックを含め、証明書プロバイダーにその法的アイデンティティを納得させる必要があります。OV 証明書と同様に、証明書プロバイダーは、証明書ポリシーを通じて EV 審査基準を公開します。

2019年まで、ChromeやFirefoxなどの主要なブラウザは、サイトがEV証明書を提示したときに、ユーザーに法的アイデンティティを視覚的に表示するのが一般的でした。これは、ドメインの前に法的名称を表示し、変更を強調するために明るい緑色を表示することで行われました。ほとんどのブラウザは、使用されている証明書の種類についてユーザーに視覚的な違いを提供しないため、この機能を廃止しました^{[37] [38]}。この変更は、法医学の専門家によって提起されたセキュリティ上の懸念と、有名な組織になりすますためにEV証明書を購入する試みが成功したことを受けて行われたもので、これらの視覚的な指標の非効率性が証明され、潜在的な悪用が浮き彫りになりました。^[39]

Web サイトが突然異なる証明書を提示した場合、その証明書のキー ビット数が少なくても、プロバイダーが異なっていても、以前の証明書の有効期限がずっと先であっても、Web ブラウザーはユーザーに警告を発しません。[要^{出典]証明}書プロバイダーが政府の管轄下にある場合、その政府は、法執行などの目的で、プロバイダーに証明書を生成するよう命令する自由を持つ場合があります。子会社の卸売証明書プロバイダーも、証明書を生成する自由を持っています。

すべてのウェブブラウザには、信頼できるルート証明書の広範な組み込みリストが付属していますが、その多くはユーザーには馴染みのない組織によって管理されています。^[1] これらの組織はそれぞれ、任意のウェブサイトに対して任意の証明書を自由に発行でき、そのルート証明書を含むウェブブラウザがそれを本物として受け入れることを保証しています。この場合、エンドユーザーは、ブラウザソフトウェアの開発者が組み込みの証明書リストを管理し、証明書プロバイダーが正しく動作して問題のある証明書をブラウザ開発者に通知することを信頼する必要があります。まれではありますが、不正な証明書が発行された事件がありました。ブラウザが不正を検出した場合もあれば、ブラウザ開発者がソフトウェアからこれらの証明書を削除するまでに時間がかかった場合もあります。^{[40] [41]}

組み込み証明書のリストは、ブラウザ開発者が提供するものに限定されません。ユーザー（およびある程度のアプリケーション）は、会社のイントラネットなどの特別な目的のためにリストを自由に拡張できます。^[42] つまり、誰かがマシンにアクセスしてブラウザに新しいルート証明書をインストールできる場合、そのブラウザは挿入された証明書を使用するWebサイトを正当なものとして認識します。

証明可能なセキュリティの場合、システムの外部にあるものに依存するため、公開鍵認証方式は、認証局の存在など、何らかの特別なセットアップの仮定に依存しなければならないという結果になります。^[43]

上記の制限にもかかわらず、証明書認証されたTLSは、Webサイトが機密情報をホストしたり、重要な取引を実行したりする場合は常に、すべてのセキュリティガイドラインで必須と見なされています。これは、実際には、上記の弱点にもかかわらず、公開鍵証明書で保護されたWebサイトは、保護されていないhttp:// Webサイトよりも安全であるためです。^[44]

アメリカ国立標準技術研究所（NIST）コンピュータセキュリティ部門^[45]は、公開鍵証明書に関するガイダンス文書を提供している。

• SP 800-32 公開鍵技術と連邦PKIインフラストラクチャの概要^[46]
• SP 800-25 連邦政府機関によるデジタル署名と認証のための公開鍵技術の使用^[47]

• 認可証明書
• かなり良いプライバシー

• チョン、テジュン; ロク、ジェイ; チャンドラセカラン、バラクリシュナン; チョフネス、デイビッド; レビン、デイブ; マッグス、ブルース M.; ミスラブ、アラン; ルーラ、ジョン; サリバン、ニック; ウィルソン、クリスト (2018)。「Web は OCSP 必須ステープルに対応していますか?」( PDF)。インターネット測定カンファレンス 2018 の議事録。pp. 105–118。doi : 10.1145/3278532.3278543。ISBN 9781450356190.S2CID 53223350  。
• Larisch, James; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Wilson, Christo (2017)。「CRLite: すべての TLS 失効をすべてのブラウザーにプッシュするためのスケーラブルなシステム」。2017 IEEEセキュリティおよびプライバシーシンポジウム (SP) 。pp . 539–556。doi : 10.1109/ sp.2017.17。ISBN 978-1-5090-5533-3. S2CID  3926509。
• Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (2022 年 11 月). トランスポート層セキュリティ (TLS) とデータグラム トランスポート層セキュリティ ( DTLS ) の安全な使用に関する推奨事項。doi : 10.17487/RFC9325 . RFC 9325。
• スミス、トレバー、ディキンソン、ルーク、シーモンズ、ケント( 2020)。「Let's Revoke: スケーラブルなグローバル証明書失効」。2020年ネットワークおよび分散システム セキュリティ シンポジウム議事録。doi : 10.14722 / ndss.2020.24084。ISBN 978-1-891562-61-7. S2CID  211268930。