暗号技術において、公開鍵証明書（こうかいかぎしょうめいしょ、public key certificate）とは、公開鍵と、その所有者の同定情報（その他に有効期間、発行者、署名アルゴリズムなどの情報も含む）を結びつける証明書である。デジタル証明書とも呼ばれる。公開鍵は単にバイナリデータであるため、公開鍵が所有者本人の物であることを確認するために証明書が必要となる。通常「公開鍵証明書」と呼ばれるものには、公開鍵そのもののデータも含まれている。
概要

公開鍵証明書は、公開鍵暗号を広い範囲で使用する場合に用いられる。ユーザー同士で暗号鍵を直接やりとりするのは、よほど小さなネットワークでない限り実用的ではない。公開鍵暗号はこの鍵配送の問題を回避する手段を提供する。

例えばある通信当事者 (ここではアリスと呼ぶことにする) に対して他の通信当事者たち (たとえばボブなど) が秘密のメッセージを送りたいとき、アリスは公開鍵を作成してボブらに公開すれば、ボブや公開鍵を入手した誰でもアリス宛てのメッセージを暗号化でき、アリスはそれを復号することができる。だが、盗聴者 (ここでは仮にイブと呼ぶことにする) が作成した公開鍵でも、それをアリスの公開鍵であるとして配布できてしまうため、この偽の公開鍵を受け取った人のメッセージはイブに復号されてしまう。これを回避するために、ユーザー同士で直接に公開鍵をやりとりするのでは、鍵配送の問題は解決されない。

そこで、信頼できる第三者機関（Trusted Third Party、TTP）として振る舞う人 (ここでは仮にトレントと呼ぶことにする) が、アリスの公開鍵の証明書を作成すると、トレントを信頼する誰もが、｢証明書に記載されている公開鍵がアリスの物である」ということを証明書の署名を確認するだけでよくなる。このように、公開鍵とその正当な所持者の関係を証明するために公開鍵証明書が用いられる。

典型的な公開鍵基盤（Public Key Infrastructure、PKI）では、認証局（Certificate Authority、CA）がこのTTPに相当する。信頼の輪(Web of Trust)では、トレントにはどんなユーザーでもなることができ、公開鍵がアリスの物であるというユーザーの申し立てを信用するかどうかは、アリスにメッセージを送りたい人次第となる。
証明書の発行

公開鍵証明書が偽造されないように通常、デジタル署名が使用される。典型的な公開鍵基盤(PKI)体系においては、認証局(CA)がこの署名を行う。信頼の輪(Web of Trust)体系においては、自分自身（自己署名証明書）もしくは他のユーザーが署名を行う。どちらの場合でも、証明書に署名をした者が公開鍵と所有者情報との結びつきを証明し、証明書の正当性を保証することになる。

大規模な展開になるとアリスはボブの認証局のことを知らないということもあり得るので（アリスとボブが異なる認証局を持っているかもしれず、それぞれが自分の認証局を使用している場合はこのような結果となってしまう）、ボブの証明書はアリスでも認識できるかもしれない「より階層の高い」認証局が署名したボブの認証局の公開鍵も組み込む場合がある。このプロセスは証明書の階層構造、そして複雑な信頼関係に達する。公開鍵基盤は大規模な設定で証明書を管理するソフトウェアを対象とする。X.509では証明書の階層構造はトップダウンのツリー構造であり、認証局を複数の第三者機関によって信頼するという必要をなくすために体系の中心として認証局を代表するルート証明書がツリーの先端となる。

かつて、ブラウザの互換性の問題で必要分の固定IPアドレスを使用しなければならず、認証局(CA)発行の証明書は1年間有効のもので3万円程度と導入コストは高価だったが、近年、レンタルサーバー業者がSNI SSLに対応したり、大手CA発行の証明書も1千円程度と大変安価で発行できるようになった。また、無料で証明書が取得ができるサービス（Let's Encrypt）もあり、導入コストは下がってきている。
正当性と失効

秘密鍵[注釈 1]の信頼性がなくなったり、証明書に埋め込まれた公開鍵と所有者情報の関係が変更（改名や転職などで）されたり、誤っていることが発覚したりした場合は、証明書が失効する場合がある。失効はごくまれな事象ではあるが、証明書の失効の可能性は、証明書を信頼する際にユーザーがいつもその正当性をチェックすべき（できるべき）であるということを意味する。これは電子証明書失効リスト（CRL - 失効した証明書のリスト）と比較することで可能となる。CRLが確実に最新で正確になるようにするのは集中的PKIのコア機能によるもので、それにはスタッフ、予算が共に必要になるため、時には適切に行われないこともある。この機能を有効にするためには、必要になったときにはいつでも誰でもすぐに利用でき、頻繁にアップデートされなければならない。証明書の正当性をチェックする別の方法として、OCSP（Online Certificate Status Protocol）を用いて証明書の状態を認証局に問い合わせる方法がある。
規格

現在もっとも一般的な証明書規格は、ITU-T X.509である。インターネットでX.509を用いるための標準は、2013年10月末に解散[1]したIETFのPKIXワーキンググループが、策定の作業をしていた。
証明書に含まれる情報

証明書は通常、以下の情報を含む。

証明書の同定情報 (同じ発行者の出したほかの証明書から区別するため)

末尾の署名のアルゴリズム

発行者を識別する情報

有効期間の開始や満了

主体者 (人、コンピュータ、組織など) を識別する情報

(主体者の) 公開鍵の情報

公開鍵のアルゴリズム

公開鍵それ自体


そのほかの情報 (たとえば、失効センタのURL)

以上に対する署名

主な認証方式
ドメイン認証(DV)

ドメインの存在確認のみの簡易認証式
組織認証(OV)

証明書取得の際に法人の存在も確認する認証式でEV証明書(後述)のようにアドレスバーが緑色になることはないが、証明書に法人名が記述されている。
実在認証(EV)「Extended_Validation_証明書」を参照
脚注[脚注の使い方]
注釈^ ここで秘密鍵とは、対称鍵のことではなく、公開鍵に対する私有鍵のこと。

出典^ “ ⇒Public-Key Infrastructure (X.509) (pkix) - History”. 2014年3月7日閲覧。

関連項目

X.509

PGP

Secure Sockets Layer,Transport Layer Security

Extended Validation 証明書 (EV SSL)

Authorization certificater

HTTP/2

外部リンク

表

話

編

歴
SSLとTLS
プロトコル

TLS/SSL

OCSP

HTTPS

STARTTLS

DTLS

ACME

技術

認証局

証明書失効リスト

DNS Certification Authority Authorization

DANE

EV証明書

HSTS

HTTP公開鍵ピンニング（英語版）

OCSPステープリング（英語版）

Perfect forward secrecy

公開鍵証明書

公開鍵暗号

公開鍵基盤

ルート証明書

SNI

歴史

アメリカ合衆国からの暗号の輸出規制

サーバゲート暗号化（英語版）

実装

Bouncy Castle（英語版）

BoringSSL

Botan

cryptlib（英語版）

GnuTLS

JSSE（英語版）

LibreSSL

MatrixSSL（英語版）

NSS

OpenSSL

mbed TLS（英語版）

RSA BSAFE（英語版）

SChannel

SSLeay

stunnel

wolfSSL

公証

証明書の透明性

Convergence（英語版）

HTTPS Everywhere / SSL Observatory

Perspectives Project（英語版）

脆弱性

理論

中間者攻撃

パディングオラクル攻撃

Lucky Thirteen攻撃

暗号

バル・ミツワー攻撃（英語版）

プロトコル

BEAST

BREACH

CRIME

Logjam* POODLE（SSL 3.0）