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日ごとのような固定の間隔に頼らないよう求めています。

よくある質問

関連記事

関連記事セキュリティヘッダーの設定方法｜HSTS、CSPの設定例つき 関連記事Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表 関連記事簡易チェックと脆弱性診断の違い｜無料ツールでできることと、専門業者が必要な場面 関連記事WordPressの脆弱性を確認する方法｜本体、プラグインの更新と対処の手順

The post SSL/TLS証明書のチェック方法|有効期限・チェーン・通信方式の確認手順 first appeared on 総合デジタルマーケティング企業 エスライン・テクノロジーズ.

セキュリティチェックの30項目は、外から17、管理画面と契約で13を確かめる

セキュリティチェックの30項目は、確かめる場所で2つに分かれます。公開ファイル、通信、HTTPヘッダー、DNSの17項目は外から、更新、ログイン、運用の13項目は管理画面と契約書で確かめます。

外から確かめられる設定は、攻撃者にも同じように見えています。証明書の期限切れや公開されたファイルは、URLを知っていれば誰でも気づけます。

管理画面の項目は外から見えないため、無料ツールでは確かめられません。IPAの『安全なウェブサイトの運用管理に向けての20ヶ条』も、パスワード、アカウント、ログといった運用の条項を多く含みます。

今日15分でできる最初の点検

最初の15分は、見つかったときの被害が大きい5点に絞ります。ブラウザとCMSの管理画面があれば、専門の道具は要りません。

1. 公開ファイルを開いてみる(2分)ブラウザで自社ドメインの /.git/HEAD と /.env を開きます。『見つかりません』や『Forbidden』と出れば合格です。設定値のような文字が表示されたら、ほかの作業より先に項目1の対処へ進みます。
2. 証明書の期限を見る(2分)アドレスバーの鍵アイコンから証明書を開き、有効期限を確かめます。残りが30日を切っていたら、自動更新が動いているかをサーバーの管理画面で見ます。
3. 更新とログインの守りを見る(5分)CMSの管理画面で、本体とプラグインに未適用の更新がないかを見ます。管理者アカウントで2段階認証が有効か、パスワードをほかのサービスと使い回していないかも確かめます。
4. バックアップの最終日を見る(3分)サーバーの管理画面で、最後に取得した日と保存先を確かめます。更新を当てるのは、この確認の後です。
5. 外から見える設定をまとめて診断する(3分)無料のWebサイトセキュリティチェックにURLを入れ、重大度が『緊急』と『高』の指摘だけを書き出します。登録は要らず、通常30秒から90秒で結果が出ます。

ターミナルを使える場合は、次の2行で項目5、6、9、11〜13の応答をまとめて確かめられます。1行目のようにスキームを省くと、curlはhttpで接続します。

curl -I example.com
curl -I https://example.com/

例: 1行目の応答(この形なら項目6は合格)
HTTP/1.1 301 Moved Permanently
Location: https://example.com/

例: 2行目の応答で探すヘッダー
strict-transport-security: max-age=31536000
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff

外から確かめる17項目(公開ファイル、通信、ヘッダー、DNS)

外から確かめる17項目は、ログインせずに、ブラウザ、curl、無料ツールで確かめられます。表は、確認方法と合格の目安、放置の危険、直し方の順に並べています。

公開してはいけないファイルとページ(項目1〜5)

よく使われるファイル名は、URLを推測して機械的に試せます。OWASPの検査ガイド(WSTG-CONF-04)も、.bak などの古い写しがソースコードや認証情報を表示する危険を挙げています。確認は、自社のサイトだけに限ります。

# Apache(.htaccess)の例: .git、.svn、.env を含むURLに404を返す
RedirectMatch 404 /\.(git|svn|env)

# nginxの例: 同じURLへのアクセスを拒否する(403を返す)
location ~ /\.(git|svn|env) {
    deny all;
}

どちらの例も、証明書の自動更新が使う /.well-known/ には影響しません。見つかった後の手順は、.gitや.envが公開されていたときの確認と対処で扱っています。

通信の暗号化と証明書(項目6〜10)

HTTPSは、入力内容を盗み見と書き換えから守る土台です。20ヶ条でも、通信の暗号化は独立した1条になっています。SSL/TLS証明書の詳しい見方は、SSL/TLS証明書のチェック方法で扱っています。

HTTPヘッダーとCookie(項目11〜14)

セキュリティヘッダーは、ブラウザに備わった防御を有効にする設定です。確認はどれも、curl -I の応答を1回見れば済みます。書き方の例は、セキュリティヘッダーの設定方法にまとめています。

APIを公開しているサイトは、Access-Control-Allow-Origin が * や、受け取ったオリジンをそのまま返す設定になっていないかも確かめます。

DNSとメール認証(項目15〜17)

自社ドメインを名乗るなりすましメールは、サイトに触れずに顧客や取引先を狙います。IPAの情報セキュリティ10大脅威2026でも、ビジネスメール詐欺が組織向けの10位に入りました。メール認証は、受け取る側に本物かどうかを判断させる仕組みです。

# Mac、Linux
dig TXT example.com +short
dig TXT _dmarc.example.com +short

# Windows(コマンドプロンプト、PowerShell)
nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com

例: 合格の形(SPFは1行だけ、DMARCはレポートの宛先あり)
"v=spf1 include:_spf.example.net ~all"
"v=DMARC1; p=none; rua=mailto:dmarc-report@example.com"

Gmailの送信者のガイドラインは、すべての送信者にSPFかDKIMを求め、1日5,000件以上を送る送信者にはSPF、DKIM、DMARCのすべてを求めています。コマンドを使わない場合は、ドメイン名を入れるだけのDMARC、SPF、DKIMの無料診断ツールでも設定の状況を確かめられます。

管理画面と契約で確かめる13項目(更新、ログイン、運用)

管理画面と契約で確かめる13項目は、外からは見えませんが、乗っ取りを防げるか、被害から戻れるかを決めます。CMS、サーバー、ドメインの管理画面と、制作会社やサーバー事業者との契約書を手元に置いて確かめます。

ソフトウェアの更新(項目18〜21)

公表された脆弱性には、CVEという共通の番号が付きます。攻撃者はその情報を使い、対策していないシステムを狙います。10大脅威2026でも、『システムの脆弱性を悪用した攻撃』が組織向けの4位でした。

WordPressでの具体的な手順は、WordPressの脆弱性を確認する方法で扱っています。

ログインとアカウント(項目22〜25)

管理画面のパスワードは、ほかで漏れたパスワードの一覧を使って機械的に試されます。20ヶ条も、不正ログインの対策、不要なアカウント、推測されやすいパスワードを、それぞれ独立した条項にしています。CMSだけでなく、サーバー、ドメイン、DNS、メール配信の管理画面も同じ扱いです。

バックアップ、監視、体制(項目26〜30)

被害をゼロにはできないため、気づく仕組みと戻す手段を先に用意します。IPAが2026年10月9日に出した不正アクセスによる漏えい等の事案を踏まえた注意喚起も、ログの保持期間、保有データ、外部サービスの見直しを求めています。

直す順番は、被害の大きさ、見つかりやすさ、手間の3つで決める

30項目は、被害の大きさ、見つかりやすさ、直す手間と副作用の3つの物差しで、3段階に分けて直します。被害が大きく機械的に見つかるものから先に直し、表示を壊すおそれのあるものは試しながら進めます。

点検の計画: 今日15分、毎月30分、変更時と年1回の見直し

点検は一度で終わらせず、頻度を決めて回します。目安は、初回15分、毎月30分、変更したときと公開前に10分から20分、四半期に1時間、年1回に半日です。

公開前と変更したときは、次の8点を確かめてから切り替えます。作業の途中で作ったファイルやアカウントは、消し忘れやすいためです。

• 作業で作った .zip、.sql、.bak を消した(項目2)
• テスト用のアカウントと、制作会社の一時的なアカウントを消した(項目25)
• 本番のデバッグ表示を切った。WordPressは WP_DEBUG、PHPは display_errors(項目5)
• テスト環境は、Basic認証などで社外から見えない(項目4)
• 全ページがhttpsで開き、Consoleに混在コンテンツの警告がない(項目6、10)
• curl -I で、ヘッダーが意図どおりに返る(項目11〜13)
• フォームを送信し、WAFに止められず、確認メールが届いた(項目28)
• 新しく作ったサブドメインに、使い終えたら消す担当を決めた(項目17)

問題が見つかったときの初動: 記録、停止、鍵の作り直し、報告

公開ファイルや改ざんが見つかったら、記録、停止、作り直し、調査、報告の判断、再発防止の順で動きます。先にファイルを消すと、調査と報告に要る証拠まで失うためです。

1. 記録を残す見つけた日時、URL、画面のスクリーンショットを残し、サーバーのログを保全します。
2. 公開を止める問題のファイルを公開フォルダから外すか、サーバー設定で拒否します。改ざんであれば、メンテナンス表示に切り替えます。
3. 鍵とパスワードを作り直す読まれたおそれのある .env のパスワード、APIキー、管理者のパスワードを変えます。ファイルを消しても、写しを取られた鍵は使えるままです。
4. ログで範囲を調べるアクセスログで、そのURLに外部から届いたリクエストの有無と日時を確かめます。
5. 報告と通知の要否を判断する個人データが漏れたおそれがあれば、個人情報保護委員会への報告と本人への通知が必要かを判断します。
6. 再発を防ぐ原因になった手順、権限、更新の漏れを直し、点検の計画に組み込みます。

自社だけで判断が難しい場合は、制作や保守を担う会社に早めに連絡します。診断結果の読み方や直す順番の相談は、エスライン・テクノロジーズのお問い合わせ窓口でも受け付けています。

IPAの20ヶ条と、この点検表の対応

この30項目は、IPAの20ヶ条の観点を、小規模なサイトで確かめられる形に置き換えたものです。20ヶ条は2005年に掲載が始まり、2015年の全面改訂を経て、2019年3月6日に最終更新されています。

20ヶ条の3条目にある『安全なウェブサイトの作り方』の脆弱性対策は、入力フォームなどの作りを調べる必要があり、この点検表には含めていません。ただし、項目11〜14のヘッダーとCookieは、その被害を和らげる設定にあたります。

反対に、メール認証(項目15、16)、参照先のないCNAME(項目17)、証明書の自動更新(項目7)は、20ヶ条にない観点として加えました。メールの送信者への要件や、証明書の有効期間の短縮といった、最終更新後の変化に対応するためです。

無料ツール、手作業、専門家の診断の使い分け

外から見える項目は無料ツールでまとめて確かめ、管理画面の項目は自分の目で確かめます。入力フォームや会員機能の作りは、専門家の脆弱性診断が担う領域です。

手順5で使った無料ツール『Security Checker X』は、公開ページの取得、DNSの照会、TLSの接続確認だけで診断し、ログインの試行や攻撃用データの送信はしません。各指摘には『確認済み』『推定』『可能性』の確度が付くため、事実と推測を分けて読めます。診断できるのは、自社か管理権限のあるサイトだけです。

専門家に依頼するかどうかの判断は、簡易チェックと脆弱性診断の違いで整理しています。

よくある質問

項目ごとに詳しく確かめる関連記事

関連記事.gitや.envが公開されていないか確認する方法と、見つかった時の対処 関連記事SSL/TLS証明書のチェック方法 関連記事セキュリティヘッダーの設定方法 関連記事WordPressの脆弱性を確認する方法 関連記事簡易チェックと脆弱性診断の違い

The post Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表 first appeared on 総合デジタルマーケティング企業 エスライン・テクノロジーズ.