SSL/TLS証明書のチェック方法|有効期限・チェーン・通信方式の確認手順

SSL/TLS証明書で確認する6項目と合格の基準

確認する項目は、有効期限、ホスト名(SAN)、チェーン、TLSの版、暗号スイート、HTTPSへの転送の6つです。項目ごとに合格の基準を先に決めておくと、ブラウザやコマンドの結果をそのまま判定に使えます。

期限の基準を『残り3分の1』としたのは、Let’s EncryptとCertbot(4.0以降)の更新時期に合わせたためです。200日の証明書なら残り約66日、90日なら残り30日が目安です。

6項目をまとめて外から確かめるなら、当社の無料ツール『Webサイトのセキュリティチェック』も使えます。URLを入れるだけで、証明書の期限、ホスト名、中間証明書の不足、古いTLSや弱い暗号、HTTPSへの転送などを確認できます(登録不要)。

外から見える設定を受動的に調べる検査のため、脆弱性診断の代わりにはなりません。役割の違いは『簡易チェックと脆弱性診断の違い』に、証明書以外の点検項目は『Webサイトのセキュリティチェック項目30選』にまとめています。

証明書のチェーンの仕組み(ルート、中間、サーバー証明書)

ブラウザは、サーバー証明書から中間証明書をたどり、端末に入っているルート証明書に行き着けたときだけ証明書を信頼します。サーバーが送るのはサーバー証明書と中間証明書で、ルート証明書は送らなくてかまいません(TLS 1.3の仕様、RFC 8446)。

ルート証明書は認証局の大本で、OSやブラウザの信頼ストアに最初から入っています。中間証明書はルート証明書の署名を受けた認証局の証明書で、サーバー証明書に署名する役割です。サーバー証明書はドメインごとに発行され、SAN(サブジェクトの代替名)に対象のホスト名が並びます。

Certbotで取得した場合は、サーバー証明書と中間証明書をこの順につないだ fullchain.pem をWebサーバーに設定します。

PCのブラウザで開けても、チェーンの欠落は隠れる

中間証明書を送っていないサーバーでも、PCのブラウザでは警告が出ないことがあります。Chromeは足りない中間証明書を証明書内の情報(AIA)から取りに行き、Firefoxは信頼された中間証明書をあらかじめ取り込んでいるためです。

一方、curlやOpenSSLで通信するプログラムは、足りない中間証明書を自動では補いません。同じ設定でも、外部システムからのAPI接続や監視ツールだけが『unable to get local issuer certificate』で失敗します。

ブラウザでSSL証明書を確認する手順(Chrome、Edge、Firefox、Safari)

ブラウザでは、アドレスバー左端のアイコンから証明書の画面を開き、発行先、発行元、有効期間を確かめます。ChromeとEdgeは同じ形式の画面で、Firefoxはチェーンの証明書をタブで切り替えて表示します。

Chromeで証明書を開く手順

1. アイコンを開くアドレスバー左端の『サイト情報を表示』アイコンをクリックします。
2. 接続の情報を開く『この接続は保護されています』をクリックします。
3. 証明書の画面を開く『証明書は有効です』をクリックすると、証明書の画面が開きます。
4. 期限と発行元を読む『全般』タブで、発行先、発行元、有効期間(発行日と有効期限)を確かめます。
5. チェーンとSANを読む『詳細』タブの『証明書の階層』でチェーンを、『証明書のフィールド』の『証明書のサブジェクトの代替名』でSANを確かめます。

Edge、Firefox、Safariでの開き方

デベロッパーツールでTLSの版と暗号を見る

TLSの版と暗号は、Chromeのデベロッパーツールの『セキュリティ』パネルで確かめられます。デベロッパーツールを開いてCtrl+Shift+P(MacはCommand+Shift+P)を押し、『セキュリティを表示』と入力すると移動できます。

『接続』の欄には、TLSの版(例: TLS 1.3)、鍵交換(例: X25519MLKEM768)、暗号(例: AES_128_GCM)が並びます。古い版や弱い方式を使っていると『廃止された接続設定』と表示されるので、見直しの目安になります。

opensslでSSL証明書の有効期限、発行者、SANを確認する

openssl s_client でサーバーから証明書を受け取り、openssl x509 で期限、発行者、SANを表示します。Linuxのサーバー上のほか、WindowsではGit for Windowsに付属するGit Bashでも同じコマンドが使えます。

openssl s_client -connect example.com:443 -servername example.com \
  </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

出力の例です(値は説明用です)。

subject=CN=example.com
issuer=C=JP, O=Example Trust, CN=Example Intermediate CA R1
notBefore=Sep 20 00:00:00 2026 GMT
notAfter=Dec 18 23:59:59 2026 GMT
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

openssl x509の出力の読み方

• subject: 証明書の主体者です。CN=の値は参考で、名前の照合にはSANが使われます(RFC 9525)。
• issuer: この証明書に署名した中間認証局です。
• notBefore、notAfter: 有効期間の始まりと終わりです。GMT表記なので、日本時間は9時間足します(例の期限は日本時間の2026年12月19日8時59分59秒)。
• X509v3 Subject Alternative Name: 証明書が有効なホスト名の一覧です。wwwの有無やサブドメインを含め、使う名前がすべて入っているかを見ます。

特定の名前が含まれるかは、OpenSSL 3系なら -checkhost で判定できます。サーバー上の証明書ファイルは、-checkend に秒数を渡すと、期限までの残りがそれより短いかを終了コードで返します。

openssl s_client -connect example.com:443 -servername example.com \
  </dev/null 2>/dev/null | openssl x509 -noout -checkhost www.example.com
# 例: Hostname www.example.com does match certificate

# 残り30日(2,592,000秒)を切っていれば終了コード1(Certificate will expire)
sudo openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem \
  -noout -checkend 2592000

opensslでチェーンの欠落と名前の不一致を判定する

チェーンは、s_client が表示する証明書の一覧と、最後の『Verify return code』で判定します。0 (ok) なら合格で、中間証明書が欠けていると21になります。

openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com </dev/null 2>/dev/null \
  | grep -E '^ [0-9] s:|^   i:|^Verify return code'

出力の例です。正常なときは、0番のサーバー証明書の発行者(i:)と、1番の中間証明書の主体者(s:)が同じ名前でつながります。中間証明書が欠けていると、1番の行が無く、21が返ります。

# 正常な例
 0 s:CN=example.com
   i:C=JP, O=Example Trust, CN=Example Intermediate CA R1
 1 s:C=JP, O=Example Trust, CN=Example Intermediate CA R1
   i:C=JP, O=Example Trust, CN=Example Root CA
Verify return code: 0 (ok)

# 中間証明書が欠けている例
 0 s:CN=example.com
   i:C=JP, O=Example Trust, CN=Example Intermediate CA R1
Verify return code: 21 (unable to verify the first certificate)

複数台のサーバーを1台ずつ確かめる

ロードバランサーの配下に複数台があると、1台だけ古い証明書が残ることがあります。-connect に各サーバーのIPアドレス、-servername に本来のホスト名を指定すると、台ごとに確かめられます。

# 203.0.113.10 は説明用のアドレス。台ごとに書き換えて実行する
openssl s_client -connect 203.0.113.10:443 -servername www.example.com \
  </dev/null 2>/dev/null | openssl x509 -noout -enddate

CDNを使っている場合は、利用者に届くCDNの証明書と、CDNが接続する元サーバー(オリジン)の証明書が別物です。両方を監視の対象に入れます。

curl -vで証明書とTLSの状態を確認する

curl -v は、使われたTLSの版と暗号、証明書の期限、SANの照合、検証の結果を1回で表示します。サーバー上での動作確認や、ブラウザと結果を比べたいときに向いています。

curl -sv -o /dev/null https://example.com/ 2>&1 \
  | grep -E 'SSL connection|subject|(start|expire) date|issuer|verified|verify ok'

出力の例です(値は説明用です)。

* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / …
*   subject: CN=example.com
*   start date: Sep 20 00:00:00 2026 GMT
*   expire date: Dec 18 23:59:59 2026 GMT
*   issuer: C=JP; O=Example Trust; CN=Example Intermediate CA R1
*   subjectAltName: "example.com" matches cert's "example.com"
* SSL certificate verified via OpenSSL.

『SSL connection using』の行がTLSの版と暗号、『expire date』が期限(GMT)、『subjectAltName』がSANの照合結果です。行末の鍵交換などの表示は、curlとTLSライブラリの組み合わせで変わります。curl 8.5など少し前の版では、最後の行が『SSL certificate verify ok.』と表示されます。

検証に失敗するとcurlは終了コード60で止まり、原因を英語で表示します(主な文言は後の表を参照)。

Windows標準のcurlで確かめるとき

Windowsに標準で入っている curl.exe は、Windowsの暗号機能(Schannel)で通信するため、-v を付けても証明書の期限や発行者が出ません。PowerShellで次のように -w "%{certs}" を使うと、証明書の主体者と期限を書き出せます。

curl.exe -s -o NUL -w "%{certs}" https://example.com/ |
  Select-String '^(Subject|Expire Date):'

最初の2行がサーバー証明書の主体者と期限です(例: Expire Date:2026-12-18 23:59:59 GMT)。チェーンの欠落や名前の照合は、Git for Windowsに付属するopensslで、前の節のコマンドを使って確かめます。

TLSの版と暗号スイートを確かめ、TLS 1.0と1.1を止める

TLS 1.0と1.1はRFC 8996で廃止されており、TLS 1.2と1.3だけを有効にするのが現在の基準です。版を指定して接続を試し、1.2と1.3は接続でき、1.0と1.1は拒否されれば合格です。

# 1.2と1.3は、接続できれば合格(Protocol version の行を見る)
openssl s_client -connect example.com:443 -servername example.com \
  -tls1_2 -brief </dev/null
openssl s_client -connect example.com:443 -servername example.com \
  -tls1_3 -brief </dev/null
# 1.1は、拒否されれば合格(OpenSSL 3系は SECLEVEL=0 の指定が必要)
openssl s_client -connect example.com:443 -servername example.com \
  -tls1_1 -cipher 'DEFAULT:@SECLEVEL=0' </dev/null

1.2と1.3で『Protocol version: TLSv1.2』のように表示されれば、その版で接続できています。1.1の試験で『alert protocol version』を含むエラーが出れば、サーバーが古い版を拒否しています。1.0の確認は、-tls1 を指定する同じ手順です。

暗号スイートの考え方

TLS 1.2の暗号スイートは、鍵交換、認証、暗号、ハッシュの組を1つの名前で表します。ECDHE-RSA-AES128-GCM-SHA256 なら、鍵交換がECDHE、認証がRSA、暗号がAES-128-GCM、ハッシュがSHA-256です。

TLS 1.3の暗号スイートは、TLS_AES_128_GCM_SHA256 のように暗号とハッシュだけを表します。鍵交換は『グループ』(X25519など)として別に決まり、どの暗号スイートも認証付き暗号(AEAD)です(RFC 8446)。

TLS 1.2で避けるものは、IETFの推奨文書RFC 9325が示しています。

• RC4: 使用禁止
• 3DES: 実効の強さが128ビットに届かない
• TLS_RSA_WITH_で始まる静的なRSA鍵交換: 前方秘匿性がない
• CBCモード: encrypt_then_mac拡張を使えない場合は避ける
• TLS_DHE_で始まるDHE: TLS 1.2では避ける

Mozilla推奨(Intermediate)に合わせた設定例

サーバー設定の推奨値には、Mozillaの『Server Side TLS』が広く使われてきました。このガイドはMozilla外のコミュニティ作業部会TLSRefへ移り、Mozillaのページは移管先を案内しています。

2026年4月の6.0版で、古い端末向けの『Old』は廃止されました。一般の公開サイト向けの『Intermediate』の推奨値は次のとおりです。

# nginx: 次の3行は http ブロックに置く
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE+AESGCM:ECDHE+CHACHA20:!PSK;
ssl_prefer_server_ciphers off;

# HTTPSの server ブロックに置く
add_header Strict-Transport-Security "max-age=63072000" always;

# Apache(mod_ssl)
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE+AESGCM:ECDHE+CHACHA20:!PSK
SSLHonorCipherOrder off
Header always set Strict-Transport-Security "max-age=63072000"

ECDHE+AESGCM:ECDHE+CHACHA20:!PSK は、表のTLS 1.2の6種だけに絞り込む短い書き方です(並び順は異なります)。使う前に、次のコマンドで6種に展開されるかを確かめます。

# TLSv1.2の6行と、TLSv1.3の3行が表示されれば想定どおり
openssl ciphers -v -tls1_2 'ECDHE+AESGCM:ECDHE+CHACHA20:!PSK'

nginxの ssl_protocols は、serverブロックだけに書くと既定のサーバーの値が使われる場合があるため、httpブロックに置きます。鍵交換のグループは、OpenSSL 3.5以降なら既定でX25519MLKEM768を優先するので、多くの場合は指定不要です。CDNを使っている場合は、CDN側の最小のTLSバージョンの設定が利用者との通信を決めます。

HTTPからHTTPSへの転送、HSTS、混在コンテンツを確かめる

HTTPのURLは301でHTTPSの同じURLへ転送し、HTTPSの応答にはHSTS(Strict-Transport-Security)のヘッダーを付けます。2026年9月公開のChrome 154では、HTTPの接続を開く前に確認を求める警告が既定で有効になりました(Chrome 154のリリースノート)。

Googleの発表では、警告の対象は最近訪れていない公開サイトで、社内などのプライベートなアドレスは対象外です。HTTPSに対応していないホスト名は、サブドメインも含めて警告の対象になります。

# スキームを省くと、curlはHTTP(80番ポート)で接続する
curl -sI example.com | grep -i -E '^HTTP|^location'
curl -sI www.example.com | grep -i -E '^HTTP|^location'
# HTTPSの応答にHSTSが付いているか
curl -sI https://example.com/ | grep -i strict-transport-security

出力の例です。

HTTP/1.1 301 Moved Permanently
Location: https://example.com/
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/
strict-transport-security: max-age=63072000

合格の基準は、HTTPの各ホスト名が301(恒久的な転送)でHTTPSへ移ることと、HTTPSの応答にHSTSがあることです。HSTSはセキュリティヘッダーの1つで、設定の手順は『セキュリティヘッダーの設定方法』で詳しく扱っています。

HSTSを入れると、証明書のエラーは回避できなくなる

HSTSを記憶したブラウザは、max-ageの期間中に証明書のエラーが起きると、警告を回避して進む選択肢を出さずに接続を止めます(RFC 6797の8.4節、12.1節)。期限切れがそのまま全面的な停止になるため、HSTSは自動更新と監視が動いてから設定します。

HSTSのヘッダーは、HTTPSの応答でエラーなく受け取ったときだけ有効になり、HTTPの応答に付けてはいけません。max-age=0 を送ると、ブラウザに記憶された設定を消せます。

混在コンテンツを見つけて直す

混在コンテンツは、HTTPSのページの中で画像やスクリプトをHTTPで読み込んでいる状態です。現在のブラウザは、画像、音声、動画をHTTPSへ自動で切り替え、スクリプト、CSS、iframeなどはブロックします(MDNの解説)。

見つけるには、デベロッパーツールのコンソールで『Mixed Content』で始まる警告を探し、読み込み元のURLをHTTPSに書き換えます。直しきるまでの応急処置として、CSPの upgrade-insecure-requests でまとめてHTTPSへ切り替える方法もあります。

期限切れのときの影響と、すぐやる対処

期限が切れると、ブラウザは画面全体の警告を出し、API連携やアプリの通信も検証エラーで止まります。まず外から配信中の証明書を確かめ、更新、再読み込み、全台での再確認の順に進めます。

Chromeは『この接続ではプライバシーが保護されません』、Firefoxは『警告: 潜在的なセキュリティリスクあり』という画面に、原因を示すコードを出します。主なコードとcurlの文言は次のとおりです。

ChromeとFirefoxは、中間証明書を補えた場合は3行目の警告を出しません。対処は次の順で進めます。

1. 配信中の証明書を確かめるs_client で notAfter を読み、どのホスト名の、どのサーバーで切れているかを特定します。
2. サーバー上のファイルと比べるファイルの期限が新しいのに配信が古いなら、更新は済んでいて再読み込みが漏れています。
3. 証明書を更新するACMEなら certbot renew などで更新し、有料の証明書は再発行して差し替えます。
4. 設定を確かめて再読み込みするnginx -t で構文を確かめてから、systemctl reload nginx で反映します。
5. 全ホスト名、全台、CDNで確かめるwwwの有無、サブドメイン、各サーバー、CDNの証明書を外から確かめます。
6. 止まった原因を直すcertbot renew --dry-run で失敗を再現し、80番ポートの遮断、DNSの変更、権限の不足などを直します。

# 配信中の証明書の期限
openssl s_client -connect example.com:443 -servername example.com \
  </dev/null 2>/dev/null | openssl x509 -noout -enddate
# サーバー上のファイルの期限(Certbotの例)
sudo openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem \
  -noout -enddate
# 更新し、構文を確かめてから再読み込み(nginxの例)
sudo certbot renew
sudo nginx -t && sudo systemctl reload nginx

更新したのに古い証明書が出るときの原因は、再読み込みの漏れ、別の台に残った古い証明書、別に管理しているCDNの証明書、設定が別のファイルを指している、のいずれかです。直したあとは、無料の『Webサイトのセキュリティチェック』でも外から結果を確かめられます。原因を切り分けられないときや、更新の自動化を設計し直したいときは、お問い合わせフォームから相談を受け付けています。

自動更新(ACME)と期限の監視を仕組みにする

更新は、ACME(RFC 8555)に対応した認証局とクライアントで自動にし、Webサーバーの再読み込みまでを含めます。そのうえで、自動更新が止まったことに気づけるよう、外から期限を調べる監視を別に置きます。

Certbotは4.0以降、残りが有効期間の3分の1を切った証明書を更新します。--deploy-hook "systemctl reload nginx" を付けると、更新できたときだけ再読み込みが走ります。事前の動作確認に使うのは certbot renew --dry-run です。

更新の時期を認証局から受け取るARI(RFC 9773、2025年6月発行)という仕組みもあり、Let’s Encryptはクライアントでの利用を勧めています。同社は2025年6月4日に期限切れの通知メールを終了したため、通知は自分で用意します。

#!/bin/sh
# 残り日数がしきい値を切った証明書と、検証に失敗したホストを表示する
DAYS=14
for host in example.com www.example.com; do
  cert=$(openssl s_client -connect "$host:443" -servername "$host" \
    -verify_hostname "$host" -verify_return_error </dev/null 2>/dev/null \
    | openssl x509 2>/dev/null)
  if [ -z "$cert" ]; then
    echo "NG $host: 接続、チェーン、名前、期限のいずれかで失敗"
  elif ! echo "$cert" | openssl x509 -noout -checkend $((DAYS * 86400)) >/dev/null; then
    echo "NG $host: 残り${DAYS}日未満"
  else
    echo "OK $host"
  fi
done

しきい値は、自動更新が動く時点より小さく、手で直す時間が残る値にします。90日の証明書は残り30日で自動更新が動くため、14日を切っていれば、自動更新が2週間以上止まっている合図です。cronで毎日動かし、NGの行が出たらチームに通知します。

• 管理しているホスト名(www、サブドメイン、API、メール)と、その証明書の一覧がある
• 更新が自動で、更新後の再読み込みまで含まれている
• certbot renew --dry-run などの更新の試験が成功する
• 外からの期限の監視が毎日動き、通知が複数人に届く
• 2027年3月15日からの100日の上限に合わせ、手作業の更新が残っていない
• サーバーの移転、CDNの導入、DNSの変更のあとに外から確かめる手順がある
• HSTSを入れる前に、上の項目がすべて満たされている

有効期間の短縮の動向(2026年10月時点)

CA/Browser Forumの決議SC-081v3により、公的に信頼されるTLS証明書の最長有効期間は、2026年3月15日以降の発行分で200日になりました。2027年3月15日に100日、2029年3月15日に47日へ短くなります。

決議は2025年4月11日に可決され(提案はApple)、2026年10月4日付のBaseline Requirements 2.3.1版にもこの日程が入っています。日数はnotBeforeからnotAfterまでを含めて数え、1日は86,400秒です。

ドメイン確認の再利用期間は、認証局がドメインの管理権を確かめた結果を使い回せる日数です。2029年には10日になるため、更新のたびにDNSやHTTPでの確認を自動で通せる仕組みが前提になります。

Let’s Encryptの発表によると、既定の90日は2027年2月10日に64日、2028年2月16日に45日へ短くなります。希望者向けの45日の証明書(tlsserverプロファイル)は、2026年5月13日から選べるようになりました。同社は、更新を有効期間の約3分の2の時点で行い、60日ごとのような固定の間隔に頼らないよう求めています。

よくある質問

関連記事