電子証明書とは？仕組み・種類・有効期限の確認方法を図解で解説
電子証明書とは、公開鍵とその持ち主（人・会社・サーバーなど）の結び付きを、認証局（CA）が電子署名で保証したデータです。
この記事では、証明書の中身、信頼の仕組み、種類ごとの使い分け、有効期限と失効の確認方法を、RFCなどの一次資料をもとに図解します。
この記事は以下のような人におすすめ！
- 電子証明書の意味と仕組みを短く知りたい人
- サーバー証明書や電子署名用の証明書の違いを整理したい人
- 有効期限や失効を確かめる方法を知りたい人
電子証明書とは？公開鍵の持ち主を保証するデータ
1-1. 電子証明書が必要な理由
インターネットで安全にやり取りするしくみの多くは、公開鍵暗号という技術を使っています。
公開鍵暗号では、本人だけが持つ「秘密鍵」と、誰に渡してもよい「公開鍵」をペアで使います。
ところが、受け取った公開鍵が本当にその相手のものかは、鍵そのものを見ても分かりません。
Microsoftの資料も、通信の途中で第三者が別の鍵にすり替えている可能性を、公開鍵暗号の課題として挙げています（参考5）。
この課題を解決するために、信頼できる第三者である認証局（CA）が、公開鍵と持ち主の結び付きを証明するデータを発行します。
認証局は、証明書を申請した人や組織が本物かを確認したうえで、証明書に署名して発行します。
このデータが電子証明書で、Microsoftの資料では「公開鍵を人・コンピューター・組織に結び付ける、署名されたデータ構造」と説明されています（参考4）。
電子証明書は、デジタル証明書や公開鍵証明書とも呼ばれ、どれもほぼ同じものを指します。
呼び方ごとの説明は、デジタル証明書や公開鍵証明書の記事でも紹介しています。
電子証明書は「この公開鍵はこの人（このサイト）のもの」と、認証局が署名して保証したデータです。
1-2. 電子証明書の中身（X.509の主な項目）
インターネットで使われる電子証明書の多くは、X.509という標準の形式で作られています。
X.509の証明書は、発行者や持ち主の名前、有効期間、公開鍵などの項目と、それらに対する認証局の署名でできています。
次の図は、Webサーバーの証明書を例に、主な項目と「その項目で何が分かるか」をまとめたものです。
図の項目を、表で整理します。
| 項目 | 内容 |
|---|---|
| バージョン | X.509の版で、現在の主流は拡張を使えるv3 |
| シリアル番号 | 認証局が証明書ごとに付ける正の整数で、同じ認証局の中で重複しない |
| 署名アルゴリズム | 認証局が署名に使った方式 |
| 発行者（Issuer） | 証明書に署名して発行した認証局の名前 |
| 有効期間（Validity） | 使い始めの日時（notBefore）から終わりの日時（notAfter）まで |
| 主体（Subject） | 証明書の持ち主の名前 |
| 公開鍵 | 持ち主の公開鍵と、その鍵の方式 |
| 拡張 | 別名（SAN）、鍵の用途、CAかどうかなどの追加情報 |
シリアル番号は、同じ認証局が発行する証明書ごとに一意でなければならないと定められています。
有効期間は、notBeforeからnotAfterまでの両端を含む期間です。
拡張のうち「別名（SAN）」には、メールアドレス、DNS名（ドメイン名）、IPアドレス、URIなどを持ち主の名前として入れられます。
「CAかどうか」を示すのは基本制約（Basic Constraints）という拡張で、鍵の用途（Key Usage）は署名用・暗号化用・証明書の発行用といった鍵の目的を示します。
X.509には3つの版があり、新しい版は前の版の項目を引き継ぎながら項目を追加してきました。
データの構造としては、署名の対象になる本体（バージョンから拡張まで）、署名アルゴリズム、署名の値の3つを1つにまとめた形になっています（参考4）。
発行者の名前とシリアル番号を組み合わせると、1枚の証明書を特定できます。
有効期限を決められない機器向けの証明書には、終了日として9999年12月31日を表す特別な値を入れることも認められています（参考1）。
形式そのものをもっと詳しく知りたい人は、X.509の記事も参考にしてください。
1-3. 印鑑証明書にたとえると分かりやすい
電子証明書は、紙の手続きでいう「印鑑証明書」にたとえると理解しやすくなります。
実印を押した書類が本人のものかは、役所が発行した印鑑証明書と印影を照らし合わせて確かめます。
同じように、電子署名が本人のものかは、認証局が発行した電子証明書の公開鍵を使って確かめます。
つまり、電子署名が「印鑑」、電子証明書が「その印鑑の印鑑証明書」、認証局が「印鑑証明書を発行する役所」にあたります。
印鑑証明書で印影を確かめるのと同じく、電子証明書でも、まず証明書そのものが信頼できる発行元のものかを確かめてから、中の公開鍵を使うのが正しい順番です。
ただし、電子証明書は署名の確認だけでなく、Webサイトが本物かを示したり、暗号化通信の鍵を確かめたりと、紙の印鑑証明書より幅広い場面で使われます。
電子証明書の仕組み
2-1. 電子署名と電子証明書の関係
電子証明書の仕組みを理解するには、まず電子署名の流れを押さえておくと近道です。
電子署名は、文書から「ハッシュ値」と呼ばれる短い要約を計算し、そのハッシュ値に送る人の秘密鍵で署名して作ります。
受け取った人は、同じ方法で文書のハッシュ値を計算し、送る人の公開鍵を使って署名と照らし合わせます。
一致すれば、文書は署名した人が署名したもので、途中で書き換えられていないと確かめられます。
ここで問題になるのが、検証に使う公開鍵が本当に送った人のものかという点で、それを保証するのが電子証明書です。
図のように、受け取る人は①証明書を確認し、②証明書から公開鍵を取り出し、③その公開鍵で署名を検証するという順に進めます。
ハッシュ値は、元の文書が1ビットでも違えばまったく別の値になり、ハッシュ値から元の文書を復元することもできません。
そのため、ハッシュ値に署名するだけで、文書全体が書き換えられていないことを確かめられます。
署名をしても元の文書そのものは変わらず、署名は文書と一緒に送ることも、別に送ることもできます（参考6）。
電子署名そのもののメリットや注意点は電子署名の記事、日本の法律上の扱いは電子署名法の記事で解説しています。
2-2. 認証局と証明書チェーン（信頼の連鎖）
電子証明書そのものにも、発行した認証局の電子署名が付いています。
認証局は、証明書の内容からハッシュ値を計算して自分の秘密鍵で署名し、受け取った側は認証局の公開鍵でその署名を検証します。
では、認証局の公開鍵が本物だとどう分かるのかというと、さらに上位の認証局の証明書で確かめ、最後は「ルート証明書」にたどり着きます。
この証明書のつながりを証明書チェーン（認証パス）と呼びます。
RFC 5280では、チェーンの各証明書について、ひとつ上の証明書の持ち主がその証明書の発行者であることと、確認する時点で有効であることを確かめるよう定めています。
チェーンのいちばん上は「トラストアンカー」と呼ばれる信頼の起点で、多くの場合は発行者と持ち主が同じ自己署名の証明書として配られます。
WindowsなどのOSやブラウザは、信頼するルート証明書の一覧（信頼ストア）を持っていて、チェーンの最後がその一覧にあるかで信頼するかを決めます。
Microsoftの資料では、PKI（公開鍵基盤）の主な構成要素として、認証局、登録局、証明書データベース、証明書ストア、鍵の保管サーバーを挙げています。
RFC 5280では、登録局（RA）を、認証局から一部の管理の仕事を任される任意の仕組みと定め、証明書の発行前に利用者が認証局へ名乗り出る登録の手続きは、直接か登録局を通して行うと説明しています。
なお、Microsoftの資料は、MicrosoftのPKIでは登録局をふつう下位CAと呼ぶと補足していますが、これはMicrosoftでの呼び方です。
このうち証明書ストアは、発行された証明書や申請中のリクエストを、それぞれのコンピューターに保存しておく場所です（参考5）。
RFC 5280は、発行者と持ち主が別々の認証局になっている「クロス証明書」も定めていて、2つの認証局のあいだの信頼関係を表します（参考1）。
社内システムでは、会社が自前の認証局（社内CA）を立て、そのルート証明書を社員の端末に配って信頼させる方法もよく使われます。
ルート証明書の役割はルート証明書の記事、認証局の種類や選び方は認証局（CA）の記事で詳しく解説しています。
2-3. HTTPS（TLS）での使われ方
いちばん身近な電子証明書の使い道が、URLが「https」で始まるWebサイトです。
TLS 1.3では、証明書で本人性を示す方式の場合、サーバーは必ずCertificateメッセージで自分の証明書チェーンを送ります。
続いてサーバーは、証明書の公開鍵と対になる秘密鍵で、それまでのやり取り全体に署名したCertificateVerifyメッセージを送ります。
ブラウザは、証明書チェーンを検証したうえでこの署名を確かめることで、相手が証明書の秘密鍵を本当に持っているサーバーだと判断できます。
証明書だけを盗んでも、対になる秘密鍵がなければこの署名を作れないため、なりすましはできません。
反対に、サーバーが利用者に証明書を求めたときだけ、利用者側も証明書を送る仕組みになっていて、これがクライアント証明書による認証です。
サーバーが証明書を求めたのに利用者が送らなかったり、送られたチェーンが信頼できる認証局につながらなかったりした場合、サーバーは認証されていない相手として続けるか、接続を中止するかを選べます（参考3）。
電子証明書の種類と使い分け
3-1. 何を証明するかで4つに分かれる
電子証明書は、X.509の形式と認証局の署名という仕組みは共通で、違いは「誰の、何を証明するか」と使う場面です。
RFC 5280も、証明書を「認証局の証明書（CA証明書）」と、証明書を発行する権限のない持ち主に発行される「エンドエンティティ証明書」に大きく分けています。
次の図は、よく目にする電子証明書を、証明する対象ごとに4つに整理したものです。
| 種類 | 証明すること | 主な使い道 |
|---|---|---|
| サーバー証明書（SSL/TLS証明書） | 接続先のサイト（ドメイン）が本物であること | httpsのWebサイト、メールサーバー |
| クライアント証明書 | 接続してきた人や端末が正規であること | 社内システム、VPN、Wi-Fiへの接続 |
| 電子署名用の証明書 | 文書に署名した人や会社が本人であること | 電子契約、行政への電子申請 |
| ルート証明書・中間CA証明書 | 証明書を発行する認証局が信頼できること | OS・ブラウザの信頼ストア、証明書チェーン |
このうち証明書を発行できるのはCA証明書を持つ認証局だけで、サーバー証明書などのエンドエンティティ証明書は、証明書を発行する権限のない持ち主に発行されます。
ルート証明書は自分自身で署名した自己署名証明書で、認証パスの起点となる公開鍵を届ける役割を持ちます（参考1）。
3-2. サーバー証明書とクライアント証明書
サーバー証明書は、Webサイトなどのサーバーが「このドメインの正しい持ち主です」と示すための証明書です。
証明書の別名（SAN）にドメイン名が入っていて、ブラウザは接続先の名前がその中に含まれるかも確かめます。
サーバー証明書には、ドメインの管理権限だけを確認するDV、組織の実在まで確認するOV、さらに厳しく審査するEVといった認証の段階があります。
認証局がどこまで本人確認をするかは、取引に求められる安全性の高さによって変わるとMicrosoftの資料も説明しています（参考4）。
サーバー証明書の種類・取得・更新はサーバー証明書、選び方はSSLサーバ証明書、無料証明書の多いDVはDV証明書の記事で解説しています。
クライアント証明書は、反対に「接続してきた人や端末が正規のものか」をサーバー側が確かめるための証明書です。
IDとパスワードに加えて、会社が配った端末だけに証明書を入れておけば、証明書のない私物の端末からの接続を断れます。
導入方法や運用の注意点は、クライアント証明書の記事を参考にしてください。
3-3. 電子署名用の証明書（個人・法人）
電子契約や行政への電子申請では、文書に電子署名をした人や会社が本人であることを示すために、電子署名用の証明書を使います。
日本では、個人向けにマイナンバーカードに入っている公的個人認証サービスの電子証明書、法人向けに法務局（登記所）が発行する商業登記電子証明書などがあります。
これらの有効期間や手数料、申請の手順は制度ごとに決まっていて、見直されることもあるため、利用する前に地方公共団体情報システム機構（J-LIS）や法務省などの公式案内で確認してください。
民間の電子契約サービスでは、サービス事業者が署名用の証明書や署名の仕組みを用意する方式もあるので、契約の前にどの方式で署名するかを確かめておくと安心です。
どの方式でも、署名に使う秘密鍵やカードを他人に貸したり、暗証番号を共有したりしないことが基本です。
電子証明書を発行・管理する基盤全体（PKI）については、PKI証明書の記事でも解説しています。
行政手続きの電子証明書の有効期限や更新方法は制度ごとに異なるため、数字や手順は必ず発行元の最新の公式案内で確かめてください。
電子証明書の取得・更新・失効
4-1. 電子証明書を取得する基本の流れ
電子証明書の取得は、種類が違っても基本的な流れは共通しています。
- 利用者（またはサーバー）が、秘密鍵と公開鍵のペアを作る
- 公開鍵と名前などの情報を入れた証明書の申請（リクエスト）を認証局に送る
- 認証局が申請者の本人確認やドメインの管理権限を確認する
- 認証局が証明書の内容に署名して、電子証明書を発行する
- 受け取った証明書を、サーバーや端末に秘密鍵と一緒に設定する
Microsoftの資料でも、利用者が認証局に証明書を申請し、認証局が本人を確認したうえで、証明書の内容のハッシュ値に署名して発行する流れが説明されています。
この流れの基本は、秘密鍵を利用者の手元で作って保管し、認証局には公開鍵だけを送ることです。
秘密鍵が漏れると、証明書が本物でも第三者がなりすませてしまうため、秘密鍵の管理は証明書そのもの以上に重要です。
ただし組織によっては、紛失に備えて秘密鍵を暗号化して預ける「鍵の保管サーバー」をPKIに置く場合もあります（参考5）。
証明書の申請は、Webサーバーの管理画面や証明書の発行サービスの画面から行うことが多く、細かな手順は認証局やサービスごとに異なります。
4-2. 有効期限と更新の考え方
電子証明書には必ず有効期間があり、期間外の証明書は検証で「有効ではない」と判断されます。
RFC 5280は、有効期間を「認証局がその証明書の状態についての情報を維持すると保証する期間」と定めています。
有効期間の日付は、2049年までは「UTCTime」、2050年以降は「GeneralizedTime」という形式で書き込むと決められています（参考1）。
証明書は期限が来ても自動では延長されないため、期限の前に新しい証明書を発行してもらい、入れ替える作業が必要です。
期限切れはWebサイトの警告表示やシステムの接続エラーに直結するので、証明書ごとに期限を一覧にして、早めに更新する運用にしておきましょう。
社内CAで発行した証明書にも期限があるため、社内のVPNや無線LANで使うクライアント証明書の期限切れにも注意しましょう。
サーバー証明書は、取得から更新までを自動化できるサービスもあるため、手作業の更新が多い場合は自動化も検討する価値があります。
証明書の更新は「新しい証明書への入れ替え」なので、サーバーへの設定し直しや、中間CA証明書の入れ替えも忘れずに行いましょう。
4-3. 失効の仕組み（CRLとOCSP）
証明書は有効期間のあいだ使い続けることを前提に発行されますが、期限の前に使えなくする「失効」が必要になることがあります。
RFC 5280は失効が必要になる例として、名前の変更、退職などによる持ち主と認証局の関係の変化、秘密鍵の漏えいやその疑いを挙げています。
失効した証明書を知らせる方法の1つ目が、CRL（証明書失効リスト）です。
CRLは、失効した証明書のシリアル番号を並べた時刻付きの一覧で、認証局などが署名して公開し、1時間・1日・1週間といった周期で新しく発行されます。
ただし、CRLは発行の周期ごとにしか更新されないため、失効の情報が届くまでに時間差が出るという弱点があります。
一方で、CRLには証明書と同じように、信頼できないサーバーや通信経路を通して配れるという利点もあります。
なお、失効した証明書は、その証明書の有効期間が過ぎたあとに定期発行されるCRLに一度載るまでは、一覧から外してはいけないと定められています（参考1）。
この弱点を補うのが、OCSP（オンライン証明書状態プロトコル）です。
OCSPは、証明書を使う側がOCSPレスポンダーに個別の証明書の状態を問い合わせ、CRLより新しい失効情報を得られるようにする仕組みです。
| OCSPの応答 | 意味 |
|---|---|
| good | 問い合わせた番号の証明書で、有効期間内のものが失効していない |
| revoked | 証明書が一時的または永久に失効している |
| unknown | 問い合わせ先がその証明書を知らない（対象外の発行者など） |
goodは「失効していない」という意味で、その証明書が実際に発行されたことや有効期間内であることまでは示さない点に注意が必要です。
反対にrevokedは、認証局がそもそも発行した記録のないシリアル番号を問い合わせたときに返されることもあります。
また、revokedには永久的な失効だけでなく、一時的な保留（certificateHold）も含まれます（参考2）。
ブラウザやOSがCRLとOCSPをどう使い分けるかは製品ごとに異なるため、社内システムで失効を確実に反映させたい場合は、利用する製品の仕様を確認しておきましょう。
電子証明書の確認方法とよくあるエラー
5-1. ブラウザで証明書を確認する手順とチェック項目
Webサイトの電子証明書は、特別なツールがなくてもブラウザから確認できます。
- 確認したいサイトをhttpsで開く
- アドレスバーの左にあるアイコンをクリックし、接続の安全性に関する表示を開く
- 「証明書」や「証明書は有効です」などの項目から、証明書の詳細を表示する
- 発行先（主体）、発行者、有効期間、証明書チェーンを確認する
メニューの名前や位置はブラウザやバージョンによって変わるため、見つからない場合はブラウザのヘルプで「証明書の表示」を調べてください。
Windowsでは、パソコンに入っている証明書を証明書マネージャーで確認することもできます。
証明書の詳細画面では、この記事の1-2で紹介した発行者・有効期間・主体などの項目が、英語の項目名のまま表示されることもあります。
証明書の詳細を開いたら、次の項目を順に確かめると、問題のある証明書に気づきやすくなります。
- 発行先（主体や別名）に、アクセスしているドメイン名が含まれているか
- 発行者が、聞いたことのある認証局や自社の認証局か
- 有効期間の開始日から終了日のあいだに、今日の日付が入っているか
- 証明書チェーンが、ルート証明書まで途切れずにつながっているか
社内システムの証明書を管理する担当者は、これに加えて、秘密鍵の保管場所と、更新の担当者・期限の一覧も合わせて確認しておきましょう。
5-2. よくある証明書エラーと原因
証明書に問題があると、ブラウザの警告やアプリの接続エラーとして表に出ます。
TLS 1.3の仕様では、証明書の問題を伝えるエラー（アラート）が種類ごとに定められています（参考3）。
| TLSのアラート | 意味 | まず確認すること |
|---|---|---|
| certificate_expired | 証明書の期限切れ、または現在は有効ではない | 証明書の有効期間と、端末の日付・時刻の設定 |
| unknown_ca | チェーンの認証局を信頼できるルートに結び付けられない | 中間CA証明書の設定漏れ、社内CAのルート証明書の配布 |
| certificate_revoked | 発行した認証局が証明書を失効させた | 新しい証明書への入れ替え |
| bad_certificate | 証明書が壊れている、署名を正しく検証できないなど | 証明書ファイルが壊れていないか、チェーンの順序と中間CA証明書が正しいか |
| certificate_unknown | そのほかの理由で証明書を受け入れられない | 証明書の用途や設定全体の見直し |
社内システムでunknown_caが出る場合は、社内CAのルート証明書が利用者の端末の信頼ストアに入っているかを最初に確かめると、原因を早く絞り込めます。
サーバーの管理者は、中間CA証明書を含めたチェーン全体をサーバーに設定しているかも、あわせて確認しておきましょう。
実際にブラウザに表示されるメッセージの文言はブラウザごとに異なりますが、原因の多くはこの表のどれかにあてはまります。
利用者として警告を見た場合は、そのまま先に進まず、URLが正しいかを確かめ、社内のシステムなら管理者に連絡しましょう。
よくある質問
Q1. 電子証明書と電子署名の違いは何ですか？
電子署名は文書に付ける「印鑑」にあたるデータで、電子証明書はその署名を確かめる公開鍵が本人のものだと認証局が保証する「印鑑証明書」にあたるデータです。
Q2. 電子証明書とデジタル証明書は違うものですか？
呼び方の違いで、どちらも公開鍵と持ち主の結び付きを認証局が保証するデータを指し、公開鍵証明書と呼ばれることもあります。
Q3. 電子証明書の有効期限が切れるとどうなりますか？
期限切れの証明書は検証で有効ではないと判断されるため、Webサイトなら警告が表示され、電子申請や社内システムなら署名や接続ができなくなるので、期限の前に更新が必要です。
Q4. 電子証明書の中身はどこで確認できますか？
Webサイトの証明書はブラウザのアドレスバーのアイコンから詳細を開くと確認でき、発行先、発行者、有効期間、証明書チェーンなどを見られます。
Q5. 秘密鍵が漏れたかもしれないときはどうすればいいですか？
すぐに発行元の認証局に連絡して証明書を失効させ、新しい鍵ペアを作って証明書を発行し直すのが基本で、RFC 5280も秘密鍵の漏えいやその疑いを失効の理由に挙げています（参考1）。
まとめ
電子証明書とは、公開鍵とその持ち主の結び付きを、認証局が電子署名で保証したデータです。
中身はX.509という形式で、発行者、持ち主、有効期間、公開鍵などの項目に認証局の署名が付いています。
受け取った側は、ルート証明書までの証明書チェーンをたどって署名を検証し、有効期間や失効の状態も確かめます。
サーバー証明書、クライアント証明書、電子署名用の証明書、ルート証明書は仕組みが共通で、証明する相手と使う場面が違います。
まずは身近なWebサイトの証明書をブラウザで開き、発行者と有効期間を確かめるところから始めてみてください。
