デジタル証明書とは？どこで使う？SSL証明書との関係もわかりやすく解説

「デジタル証明書」という言葉はよく見かけるのに、実際には「SSL証明書のこと？」「ログインの本人確認？」「電子署名と同じ？」と混ざりやすいです。 特に Web サイト運用やサーバー設定をしていると、「証明書を入れる」「更新する」「期限切れに注意する」という作業だけ先に出てきて、仕組みそのものは後回しになりがちです。

このページでは、2026年10月時点で RFC 5280、NIST の public key certificate / public key cryptography / digital signature の定義、Microsoft Learn の証明書チェーン解説を確認しながら整理しています。さらに、定義だけで終わらせず openssl での確認コマンド、ブラウザや curl で実際に出るエラー文言、更新忘れを防ぐ通知運用までを実務目線で足しています。 「HTTPS の証明書更新」や「TLS終端」の文脈から見たい場合は、逆プロキシとは？NginxやApacheの前に置く理由と使いどころを解説 もつながりやすいです。

デジタル証明書とは何か

デジタル証明書 は、簡単に言うと「ある公開鍵が、たしかにその相手のものだと示すための電子文書」です。 ただ公開鍵だけ渡されても、それが本当に example.com のものなのか、社内の認証サーバーのものなのか、配布されたソフトの発行元のものなのかは分かりません。

そこで、認証局 などの信頼された第三者が「この公開鍵はこの名前や主体に結びついています」と署名付きで示したものが証明書です。

初心者向けには、こう分けると入りやすいです。

証明書の中には何が入っているか

証明書には、ざっくり次のような情報が入ります。

実務で X.509 証明書という言い方を見たら、だいたいこの手のインターネットでよく使われる証明書形式を指しています。 なので X.509 は難しい特殊用語というより「普段使っている証明書の標準的な入れ物」くらいの理解でまずは十分です。

手元の証明書ファイル(PEM形式)の中身を実際に見るには、次のコマンドが定番です。

openssl x509 -in server.crt -noout -text

要点だけ素早く見たいときは、項目を絞って表示できます。

$ openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName
subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R11
notBefore=Apr  4 00:00:00 2026 GMT
notAfter=Jul  3 23:59:59 2026 GMT
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

この出力を読むだけで「いつ切れるか(notAfter)」「どの CA が出したか(issuer)」「どのドメインに有効か(SAN)」が一目で分かります。証明書トラブルの調査は、まずここを見るところから始めると速いです。

opensslで期限とチェーンを確認する

証明書まわりの調査で最初に使うのは、稼働中のサーバーへ実際に接続して証明書を取ってくる openssl s_client です。

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

-servername は SNI(同じIPで複数ドメインを出し分ける仕組み)に対応するために必須です。これを付けないと別ドメインの証明書が返ってきて、調査が混乱します。

チェーン(中間証明書がそろっているか)を確認したいときは、検証の様子をそのまま表示させます。

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts

出力の先頭付近にある Verify return code が判断のポイントです。典型的なパターンを並べておきます。

num=20 が出たときは、配布されたチェーンファイル(fullchain.pem)を使わずにサーバー証明書単体だけを設定しているケースがほとんどです。「自分の PC では見えるのに別環境では警告が出る」というトラブルは、たいていこれが原因です(自分の OS にはたまたまその中間証明書がキャッシュされていただけ)。

残り日数だけを数値で確認したい、監視スクリプトに組み込みたい、という場合は -checkend が便利です。秒数で指定し、その期間内に切れるなら終了コード 1 を返します。

$ openssl x509 -in server.crt -noout -checkend 1209600
Certificate will expire   # 14日(1209600秒)以内に切れる
$ echo $?
1

この終了コードを使えば、cron で毎日回して「14日以内に切れる証明書だけ通知」といった仕組みが数行で作れます。

どこで使うのか

「証明書 = Web サイトの HTTPS 用」と思われがちですが、実際にはかなり広く使われます。

1. Web サイトの HTTPS

いちばん身近なのは HTTPS です。 ブラウザが Web サイトへ接続するとき、サーバーは「このドメインに対応する証明書」を出してきます。ブラウザはその証明書を見て、接続先が想定どおりか、有効期限切れではないか、信頼チェーンに問題がないかを確認します。

2. メール署名やメール暗号化

メールでも、送信者の正しさを示したり、やり取りを暗号化したりするために証明書が使われます(S/MIME)。 社外との重要なやり取りや、改ざんされていないことを示したい場面で使われることがあります。

3. ソフトウェアやアプリの署名

配布されるアプリやドライバ、インストーラが「本当にその開発元のものか」を示すためにも証明書が使われます(コード署名)。 ここでは、発行元が 電子署名 を付け、利用者側がその署名を検証する形です。

4. VPN やクライアント認証

5. サービス間通信や機器認証

社内システム同士の API 通信、IoT 機器、社内ネットワーク機器の管理画面などでも証明書が使われます。 たとえば、逆プロキシで TLS終端 をまとめる構成でも、結局は「どの証明書をどこで持つか」が運用の要になります。

SSL証明書との違いは何か

ここはかなり混ざりやすいです。

• デジタル証明書: もっと広い概念
• SSL証明書: 主に Web 用サーバー証明書を指すことが多い言い方

つまり、SSL証明書はデジタル証明書の使われ方のひとつ、と考えると整理しやすいです。

エラーが出たときに何が起きているか

証明書の問題は、ブラウザ・curl・サーバーログそれぞれで違う形のメッセージになります。同じ原因でも文言が変わるので、対応表を持っておくと調査が一気に速くなります。

ここで注意したいのは、curl -k(--insecure)で検証を無効にして「通った」ことにするのは応急処置にもなりません。本番の API 連携や Webhook で -k を常用すると、中間者攻撃に対して無防備になります。エラーが出たら、まず前章の openssl s_client でどの種類の問題(期限・チェーン・名前)かを切り分けてから直すのが正攻法です。

失敗例を「現象→原因→確認→回避」で1つ整理しておきます。

更新忘れを防ぐ運用をどう作るか

証明書まわりは、仕組みを知るだけでは足りません。実務では「正しく発行できるか」より「正しく運用できるか」の方が事故につながりやすく、その筆頭が更新忘れです。

しかも、ここは追い風ではなく逆風になっています。CA/Browser Forum はサーバー証明書の最大有効期間を段階的に短縮することを決めており、2026年3月15日以降はすでに最長200日で、2027年3月15日以降は100日、2029年3月15日以降は47日へ短くなります（CA/Browser Forum の Baseline Requirements。2026年10月時点の版は 2.3.1）。同じ日程で、ドメイン認証の結果を使い回せる期間も200日→100日→10日へ短くなります。つまり「年1回まとめて手で更新」という運用は早晩成り立たなくなり、自動更新が前提になります。

無料の証明書で広く使われる Let's Encrypt も、いまの90日から段階的に短くする予定を公表しています。2027年2月10日から標準のプロファイルが64日、2028年2月16日から45日になり、希望者向けには45日の証明書（2026年5月から）や6日の短期証明書も用意されています（Let's Encrypt 公式ブログ）。自動更新していれば基本的に作業は要りませんが、「更新は期限の30日前」のような固定の日数を前提にした設定や監視は見直しが必要です。

おすすめの考え方は「自動更新を入れる + 失敗を前提に多段で通知する」です。自動更新だけ入れても、ACMEクライアントが沈黙して失敗していると気づけません。

外形監視の最小例として、複数ホストの残日数をまとめて出すワンライナーを置いておきます。これを cron で日次実行し、しきい値を割ったものだけ Slack Webhook へ流せば、専用ツールが無くても通知運用は始められます。

for h in example.com api.example.com; do
  end=$(echo | openssl s_client -connect "$h:443" -servername "$h" 2>/dev/null \
    | openssl x509 -noout -enddate | cut -d= -f2)
  days=$(( ($(date -d "$end" +%s) - $(date +%s)) / 86400 ))
  echo "$h : ${days}日"
done

残りの定番リスクも、簡単に押さえておきます。

初心者はどこまで理解すれば十分か

最初は次の4つが押さえられればかなり十分です。

この4つが入ると、「証明書を設定してください」と言われたときに、ただのファイル作業ではなく「信頼をどう配る仕組みなのか」「どう更新を回し続けるか」まで見えやすくなります。

デジタル証明書に関するよくある質問

Q. デジタル証明書と SSL/TLS 証明書は同じものですか？

A. SSL/TLS 証明書はデジタル証明書の一種で、Web サーバーの認証に使うものです。デジタル証明書はもっと広い概念で、コード署名、メール署名(S/MIME)、VPN、端末認証なども含みます。

Q. 証明書がいつ切れるか手早く確認するには？

A. ファイルなら openssl x509 -in server.crt -noout -enddate、稼働中サーバーなら echo | openssl s_client -connect host:443 -servername host 2>/dev/null | openssl x509 -noout -dates です。残り日数で分岐させたいなら -checkend 秒数 が終了コードで判定できて便利です。

Q. ブラウザで「保護されていない通信」と出たら、まず何を見ますか？

A. エラーコードを見ます。NET::ERR_CERT_DATE_INVALID なら期限切れ、NET::ERR_CERT_AUTHORITY_INVALID なら中間証明書不足や信頼されないCA、NET::ERR_CERT_COMMON_NAME_INVALID ならドメイン名(SAN)の不一致です。原因の種類で直し方が変わります。

Q. curl のエラー60はどう切り分けますか？

A. メッセージで分かれます。certificate has expired は期限切れ、unable to get local issuer certificate はチェーン不足(またはクライアントのCAストア不備)です。-k で無視するのは本番では危険なので、openssl s_client で原因を特定してから直してください。

Q. 自己署名証明書を本番で使っても良いですか？

A. 一般公開サービスでは避けた方が安全です。verify error:num=18:self signed certificate が出てブラウザ警告になり、利用者の信頼を失います。社内やテストでは便利ですが、内部 CA を立てて配布する方が運用が綺麗です。

Q. 「ルート CA と中間 CA」「チェーン不足」とは何が起きているのですか？

A. ルート CA は信頼の起点、中間 CA はその委任を受けて実際の証明書を発行する役割です。サーバー証明書は中間 CA から発行され、中間→ルートの信頼チェーンを辿って検証されます。サーバーが中間証明書を送り忘れると num=20/21 になり、環境によって警告が出ます。サーバー証明書と中間証明書を連結した fullchain.pem を設定すれば解消します。

Q. 有効期間が47日に短くなると運用はどう変わりますか？

A. 手動更新は現実的でなくなり、Let's Encrypt などの ACME 自動更新が前提になります。2026年3月15日以降は最長200日になっており、2027年3月15日から100日、2029年3月15日から47日へ段階的に短くなる予定なので（CA/Browser Forum の投票 SC-081v3 で決定し、Baseline Requirements に反映済み）、いま手動運用なら早めに自動更新+多段通知へ切り替えておくのが安全です。

まとめ

デジタル証明書 は「この公開鍵はこの相手のものです」と示すための電子文書です。 HTTPS、メール署名、ソフトウェア署名、VPN、端末認証など、かなり幅広い場面で使われます。

SSL証明書という言い方は今でもよく残っていますが、それは Web 向けサーバー証明書を指す場面が多いだけで、証明書そのものはもっと広い仕組みです。 大事なのは「入れたら終わり」ではなく、openssl で期限・チェーン・名前を確認し、更新を自動化して、複数のしきい値で通知が鳴る状態を作ることです。有効期間が短くなっていく流れの中では、この運用がそのままサービスの可用性を左右します。

参考リンク

• RFC Editor: RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
• NIST CSRC Glossary: Public key certificate
• NIST CSRC Glossary: Public key cryptography
• NIST CSRC Glossary: Digital signature
• Microsoft Learn: Working with Certificates
• CA/Browser Forum: Baseline Requirements for TLS Server Certificates
• Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days
• Certbot: User Guide（更新のタイミング）
• DigiCert: TLS Certificate Lifetimes Will Officially Reduce to 47 Days
• curl: curl error codes