先に要点
「デジタル証明書」という言葉はよく見かけるのに、実際には「SSL証明書のこと?」「ログインの本人確認?」「電子署名と同じ?」と混ざりやすいです。 特に Web サイト運用やサーバー設定をしていると、「証明書を入れる」「更新する」「期限切れに注意する」という作業だけ先に出てきて、仕組みそのものは後回しになりがちです。
このページでは、2026年6月時点で RFC 5280、NIST の public key certificate / public key cryptography / digital signature の定義、Microsoft Learn の証明書チェーン解説を確認しながら整理しています。さらに、定義だけで終わらせず openssl での確認コマンド、ブラウザや curl で実際に出るエラー文言、更新忘れを防ぐ通知運用までを実務目線で足しています。
「HTTPS の証明書更新」や「TLS終端」の文脈から見たい場合は、逆プロキシとは?NginxやApacheの前に置く理由と使いどころを解説 もつながりやすいです。
デジタル証明書とは何か
デジタル証明書 は、簡単に言うと「ある公開鍵が、たしかにその相手のものだと示すための電子文書」です。
ただ公開鍵だけ渡されても、それが本当に example.com のものなのか、社内の認証サーバーのものなのか、配布されたソフトの発行元のものなのかは分かりません。
そこで、認証局 などの信頼された第三者が「この公開鍵はこの名前や主体に結びついています」と署名付きで示したものが証明書です。
初心者向けには、こう分けると入りやすいです。
証明書の中には何が入っているか
証明書には、ざっくり次のような情報が入ります。
| 項目 | 意味 |
|---|---|
| 主体名(Subject) | 誰・どのドメイン・どの組織の証明書か |
| 公開鍵 | その相手に対応する公開鍵 |
| 発行者(Issuer) | どの 認証局 が出したか |
| 有効期限(notBefore / notAfter) | いつからいつまで使えるか |
| SAN(Subject Alternative Name) | 対応するドメイン名の一覧。今のブラウザはここを見る |
| 用途情報(Key Usage / EKU) | サーバー認証、クライアント認証、署名など何に使う前提か |
| 署名 | 発行者が本当に出したことを示す 電子署名 |
実務で 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 が判断のポイントです。典型的なパターンを並べておきます。
| opensslの表示 | 意味と原因 |
|---|---|
| Verify return code: 0 (ok) | チェーン・期限・名前すべて問題なし |
| verify error:num=20:unable to get local issuer certificate | 中間証明書がサーバーから送られていない(チェーン設定漏れ) |
| verify error:num=21:unable to verify the first certificate | 同じく中間証明書不足。クライアント側がルートまで辿れない |
| verify error:num=10:certificate has expired | 有効期限切れ。notAfter を過ぎている |
| verify error:num=18:self signed certificate | 自己署名証明書。信頼ストアに入っていない |
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 サイトへ接続するとき、サーバーは「このドメインに対応する証明書」を出してきます。ブラウザはその証明書を見て、接続先が想定どおりか、有効期限切れではないか、信頼チェーンに問題がないかを確認します。
いわゆる「SSL証明書」と呼ばれるものの多くは、ここで使うサーバー証明書のことです。 ただ、実際に使われているのは今では主に TLS なので、言葉としては「TLS証明書」や「サーバー証明書」に近いイメージです。
2. メール署名やメール暗号化
メールでも、送信者の正しさを示したり、やり取りを暗号化したりするために証明書が使われます(S/MIME)。 社外との重要なやり取りや、改ざんされていないことを示したい場面で使われることがあります。
3. ソフトウェアやアプリの署名
配布されるアプリやドライバ、インストーラが「本当にその開発元のものか」を示すためにも証明書が使われます(コード署名)。 ここでは、発行元が 電子署名 を付け、利用者側がその署名を検証する形です。
4. VPN やクライアント認証
VPN や社内システムでは、ユーザー名とパスワードだけでなく、端末や利用者が持つ証明書を使って認証することがあります。 「正しい端末だけ接続させたい」「管理者端末を限定したい」という場面ではかなり実務的です。
5. サービス間通信や機器認証
社内システム同士の API 通信、IoT 機器、社内ネットワーク機器の管理画面などでも証明書が使われます。 たとえば、逆プロキシで TLS終端 をまとめる構成でも、結局は「どの証明書をどこで持つか」が運用の要になります。
SSL証明書との違いは何か
ここはかなり混ざりやすいです。
つまり、SSL証明書はデジタル証明書の使われ方のひとつ、と考えると整理しやすいです。 しかも SSL という言葉は今でも慣用的に残っていますが、実際の通信では古い SSL ではなく TLS が使われています。
エラーが出たときに何が起きているか
証明書の問題は、ブラウザ・curl・サーバーログそれぞれで違う形のメッセージになります。同じ原因でも文言が変わるので、対応表を持っておくと調査が一気に速くなります。
期限切れ(ブラウザ)
Chrome/Edge では NET::ERR_CERT_DATE_INVALID、「この接続ではプライバシーが保護されません」と表示されます。Firefox は SEC_ERROR_EXPIRED_CERTIFICATE。
チェーン不足(ブラウザ)
中間証明書が足りないと NET::ERR_CERT_AUTHORITY_INVALID。「発行元を確認できません」系の表示になります。
名前の不一致(ブラウザ)
SAN に対象ドメインが無いと NET::ERR_CERT_COMMON_NAME_INVALID。wwwあり/なしの設定漏れで起きやすいです。
curl / アプリ側
期限切れは curl: (60) SSL certificate problem: certificate has expired、チェーン不足は curl: (60) ... unable to get local issuer certificate。どちらも終了コード 60 です。
ここで注意したいのは、curl -k(--insecure)で検証を無効にして「通った」ことにするのは応急処置にもなりません。本番の API 連携や Webhook で -k を常用すると、中間者攻撃に対して無防備になります。エラーが出たら、まず前章の openssl s_client でどの種類の問題(期限・チェーン・名前)かを切り分けてから直すのが正攻法です。
失敗例を「現象→原因→確認→回避」で1つ整理しておきます。
| 段階 | 内容 |
|---|---|
| 現象 | 本番ブラウザでは表示できるのに、Androidアプリや一部のLinuxサーバーからのAPI呼び出しだけ curl: (60) ... unable to get local issuer certificate で失敗する |
| 原因 | サーバーにサーバー証明書だけ設定し、中間証明書を送っていない。OS/ブラウザによっては中間証明書を補完できるが、できない環境で失敗する |
| 確認 | echo | openssl s_client -connect host:443 -servername host で verify error:num=20 が出る。返ってくる証明書が1枚だけになっている |
| 回避 | サーバー証明書 + 中間証明書を連結した fullchain.pem を設定し直し、再度 s_client で Verify return code: 0 (ok) を確認する |
更新忘れを防ぐ運用をどう作るか
証明書まわりは、仕組みを知るだけでは足りません。実務では「正しく発行できるか」より「正しく運用できるか」の方が事故につながりやすく、その筆頭が更新忘れです。
しかも、ここは追い風ではなく逆風になっています。CA/Browser Forum はサーバー証明書の最大有効期間を段階的に短縮することを決めており、2026年3月15日以降は最長200日、2027年3月15日以降は100日、2029年3月15日以降は47日になります(DigiCert / Sectigo の解説より)。つまり「年1回まとめて手で更新」という運用は早晩成り立たなくなり、自動更新が前提になります。
おすすめの考え方は「自動更新を入れる + 失敗を前提に多段で通知する」です。自動更新だけ入れても、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
残りの定番リスクも、簡単に押さえておきます。
秘密鍵の管理
証明書そのものより危ないのは秘密鍵の漏えい。なりすましや署名偽装につながる。鍵はアクセス権限を絞り(例: 600)、リポジトリに入れない。漏れたら失効(revoke)して再発行する
用途の不一致
サーバー認証用・クライアント認証用・署名用は EKU が異なる。「証明書なら何でも同じ」ではなく、用途情報まで見て選ぶ
初心者はどこまで理解すれば十分か
最初は次の4つが押さえられればかなり十分です。
- 証明書は「公開鍵が誰のものかを示す情報」
- SSL証明書はデジタル証明書の一部の使い方
- Web 以外にも、署名、VPN、端末認証、ソフトウェア配布で使われる
- 実務では「期限・秘密鍵・信頼チェーン・更新の自動化と通知」が大事
この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月以降は最長200日、2027年は100日、2029年は47日へ段階的に短縮される予定なので(CA/Browser Forum SC-081v3)、いま手動運用なら早めに自動更新+多段通知へ切り替えておくのが安全です。
まとめ
デジタル証明書 は「この公開鍵はこの相手のものです」と示すための電子文書です。 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
- DigiCert: TLS Certificate Lifetimes Will Officially Reduce to 47 Days
- curl: curl error codes