セキュリティヘッダーは影響の小さい順に4段階で入れる

最初に入れるのは、表示が壊れにくいX-Content-Type-OptionsとReferrer-Policyです。次にX-Frame-OptionsとPermissions-Policy、3段階目にHSTS、最後にCSPを入れます。段階を分けておくと、表示や機能が壊れたときに原因のヘッダーを1つに絞り込めます。

セキュリティヘッダーの推奨値は、OWASPのHTTP Headers Cheat Sheetを基準にし、X-Frame-Optionsだけは自サイト内の枠表示を残せる SAMEORIGIN にしています（OWASPは DENY）。段階1と同時に、ServerヘッダーとX-Powered-Byに出る版の表記も消します。

ヘッダーはどこで付き、ブラウザはどう使うか

セキュリティヘッダーは、アプリ（WordPressなど）、Webサーバー、CDNのどこでも付けられ、ブラウザは手元に届いた応答のヘッダーに従って動作を変えます。ブラウザからは、どこで付いたヘッダーかを区別できません。1つのヘッダーを付ける場所を1か所に決めることが、重複と付け漏れを防ぐ近道です。

各ヘッダーの設定値と推奨値

段階1と2の4つは推奨値がほぼ決まっており、自サイトの使い方と突き合わせれば決められます。HSTSとCSPは、後の節の手順で扱います。

X-Content-Type-Options: nosniff

X-Content-Type-Optionsの値は nosniff だけで、Content-TypeがJavaScriptの種類でないスクリプトと、text/cssでないスタイルシートを読み込ませなくします。Chrome 146の場合、text/plainで返したJavaScriptは、nosniffが無いと実行され、付けると止まります。

入れる前に curl -sI https://example.com/main.js で、主なJavaScriptのContent-Typeを調べます。text/javascript などなら合格で、text/plain などならサーバーのMIMEタイプの設定を先に直します。

Referrer-Policy: strict-origin-when-cross-origin

Referrer-Policyは、リンク先や外部の読み込み先へ、元のページのURLをどこまで伝えるかを決めます。推奨値は、同じオリジンにはURL全体を、別のオリジンには https://example.com/ のようなオリジンだけを伝え、HTTPSからHTTPへは何も送りません。指定が無いときの既定値でもありますが、OWASPは明示するよう勧めています。

URLに会員番号などを含むサイトでは、no-referrer や same-origin も選べます。ただし、Google Maps Platformの公式文書によると、この2つではRefererが送られず、Refererで制限したAPIキーが要求を拒否する場合があります。

X-Frame-Options と frame-ancestors の関係

X-Frame-Optionsは、自サイトのページを他サイトの枠（iframe）の中に表示させない指示で、クリックジャッキングを防ぎます。値は、すべての枠を拒否する DENY と、すべての親が同じオリジンのときだけ許す SAMEORIGIN の2つです。特定のサイトを許す ALLOW-FROM は廃止され、現在のブラウザはこの値を含むヘッダー全体を無視します。

特定のサイトにだけ埋め込みを許す方法は、CSPの frame-ancestors 'self' https://partner.example.jp のような指定です。CSPの仕様（W3C CSP Level 3）は、強制モードのCSPに frame-ancestors があれば、X-Frame-Optionsを無視すると定めています。Chrome 146でも、X-Frame-Options: DENY より frame-ancestors の許可が優先されます。

新旧のブラウザに対応するため、2つは併記できます。WordPressは管理画面やカスタマイザーで自サイトを枠の中に表示し、本体も SAMEORIGIN を付けるため、サーバー側もSAMEORIGINにそろえます。

Permissions-Policy

Permissions-Policyは、カメラ、マイク、位置情報などのブラウザ機能を、そのページと埋め込んだiframeで使えるかを決めます。値は機能ごとに、() で全面禁止、(self) で自サイトだけ、(self "https://map.example.jp") で指定のオリジンにも許可します。旧仕様のFeature-Policyの camera 'none' は、camera=() と書き換えます。

止めるのは、使っていない機能だけです。店舗検索で位置情報を使うなら geolocation=(self) にし、決済でPayment Request APIを使うなら payment は止めません。

付けないヘッダーと、消すヘッダー

X-XSS-Protectionは廃止されたヘッダーで、OWASPは付けないか、付けるなら 0 にするよう勧めています。古いブラウザのXSS検出機能が、安全なサイトにかえってXSSの弱点を生む場合があったためです。ChromiumがVersion 107で廃止したExpect-CTも、付ける必要はありません。

ServerとX-Powered-Byに出る版の表記は、Apacheならhttpd.confの ServerTokens Prod（.htaccessでは不可）で消します。nginxは server_tokens off;、PHPはphp.iniの expose_php = Off です。版を隠すだけでは安全にならないとApacheの公式文書も述べており、WordPressの本体とプラグインの更新のような更新作業を優先します。

Apache、nginx、WordPress、Cloudflareの設定例

段階1と2の4つのヘッダーに、HSTSの最初の値（max-age=300）を加えた設定例です。どの環境でも、404などのエラー応答とリダイレクトにもヘッダーが付く書き方を選ぶことが要点です。

Apache（.htaccess、VirtualHost）

# .htaccess、またはHTTPSのVirtualHostに書く
<IfModule mod_headers.c>
  # アプリが同名のヘッダーを出しても1本になるよう、unsetとalways setを対にする
  Header unset X-Content-Type-Options
  Header always set X-Content-Type-Options "nosniff"
  Header unset Referrer-Policy
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header unset X-Frame-Options
  Header always set X-Frame-Options "SAMEORIGIN"
  Header unset Permissions-Policy
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header unset Strict-Transport-Security
  Header always set Strict-Transport-Security "max-age=300"
  # PHPの版の表記を消す（PHPの動かし方で入る表が違うため2行とも書く）
  Header unset X-Powered-By
  Header always unset X-Powered-By
</IfModule>

Apacheの Header には、既定の「onsuccess」と「always」の2つの表があります。Apacheが自ら作る404やリダイレクト（RedirectやRewriteRuleの301）では、always の表しか使われず、always の無い指定は付きません（mod_headersの公式文書）。

PHPのヘッダーが入る表は動かし方で違い、mod_phpでは既定の表に、CGIやFastCGI（PHP-FPMなど）では always の表に入ります。Header always set だけではmod_phpでアプリの同名ヘッダーと2本並ぶため、例のように Header unset と対で書くと、どちらの方式でも1本になります。LiteSpeedなどApache互換のサーバーでは扱いが異なる場合があるため、設定後にcurlで本数を確かめます。

.htaccessの指定は、そのフォルダに届いた要求にだけ効き、VirtualHostやコントロールパネルで行うリダイレクトには付きません。HSTSは、変更できるならVirtualHostに書くのが確実です。mod_headersが無効な場合、<IfModule> で囲んだ指定は黙って無視され、囲まない指定は500エラーになります。

nginx

# /etc/nginx/snippets/security-headers.conf（共通の指定を1か所にまとめる）
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=300" always;

# HTTPSのserverブロック（証明書などの設定は省略）
server {
    listen 443 ssl;
    server_name example.com;
    server_tokens off;
    include snippets/security-headers.conf;

    location /assets/ {
        add_header Cache-Control "public, max-age=2592000";
        # add_headerを書いた場所では上の指定が消えるため、読み込み直す
        include snippets/security-headers.conf;
    }
}

nginxの add_header は、always が無いと200や301などの決まった応答にしか付かず、404や500には付きません（nginxの公式文書）。また、下の階層に add_header が1つでもあると、上の階層の add_header はすべて引き継がれません。例の /assets/ のように、キャッシュ用のヘッダーを足したlocationでセキュリティヘッダーが消えるのは、このためです。

対策は、共通のファイルを各locationで読み込み直すか、nginx 1.29.3以降（安定版は1.30.0以降）の add_header_inherit merge; をserverブロックに書く方法です。OSの標準パッケージは版が古いことがあるため、nginx -v で確かめてから選びます。アプリが出した同名のヘッダーは置き換わらずに残るので、PHP-FPMなら fastcgi_hide_header X-Frame-Options; のように隠します（リバースプロキシは proxy_hide_header）。

WordPress

サーバーの設定を変えられない場合は、WordPressの wp_headers フィルターで足せます。コードを wp-content/mu-plugins/ の直下に置くと自動で読み込まれ、テーマの変更でも消えず、管理画面から無効にもできません。

<?php
// wp-content/mu-plugins/security-headers.php として保存する
add_filter( 'wp_headers', function ( $headers ) {
    $headers['X-Content-Type-Options'] = 'nosniff';
    $headers['Referrer-Policy']        = 'strict-origin-when-cross-origin';
    $headers['X-Frame-Options']        = 'SAMEORIGIN';
    $headers['Permissions-Policy']     = 'camera=(), microphone=(), geolocation=()';
    return $headers;
} );

このフィルターは、公式リファレンスにあるとおりWP::send_headers()の中で適用され、効くのは公開ページの応答だけです。管理画面、ログイン画面、REST API、画像やCSSには付かないため、HSTSはサーバーかCDNで付けます。

WordPress 6.9以降は、管理画面とログイン画面に、本体が X-Frame-Options: SAMEORIGIN と frame-ancestors 'self' のCSPを付けます。サーバー側でCSPを付けるときは、この2つの画面でも値が食い違わないかの確認が必要です。

Cloudflare

Cloudflareでは、Rules Overviewの「Create rule」から「Response Header Transform Rule」を作ります。操作は、同名のヘッダーを上書きする「Set static」を選びます。「Add」は既存のヘッダーを残したまま足すため、オリジンの値と2本並びます。

HSTSは、Edge Certificatesの画面にある専用の設定で付けられます。マネージド変換の「Add security headers」は、OWASPが勧めない X-XSS-Protection: 1; mode=block や廃止済みのExpect-CTも付けるため、個別のルールで付ける方が推奨値にそろえやすくなります。

HSTSの設定方法と、max-ageを延ばす手順

HSTSは、HTTPSがサイト全体で安定してから、max-ageを5分、1週間、1か月と延ばし、最後に1年以上にします。HSTSを覚えたブラウザでは、証明書の期限切れなどのエラーのとき、利用者が警告を越えて進めなくなります。そのため、証明書の更新の自動化を先に済ませます。

HSTSを受け取ったブラウザは、受け取った時点からmax-ageの秒数だけそのホストを覚え、HTTPのURLもHTTPSに切り替えて接続します（RFC 6797）。HTTPの応答に付けたHSTSは無視されるため、HTTPSの応答に付けます。

1. 前提をそろえる全ページがHTTPSで表示され、混在コンテンツが無く、HTTPからHTTPSへ301で転送していることを確かめます。証明書の自動更新と期限の監視も整えます。期限の確かめ方は、SSL/TLS証明書のチェック方法で説明しています。
2. サブドメインを含めるか決めるincludeSubDomainsは、社内向けを含むすべてのサブドメインがHTTPSで動く場合だけ付けます。付けるなら、登録窓口のhstspreload.orgが勧める手順のとおり、最初の5分の段階から付けて試します。
3. max-age=300で配信する全ページと各サブドメインを開き、問い合わせ、決済、ログインまで動かします。
4. 1週間、1か月と延ばす604800、2592000の順に延ばします。各段階では、その値の期間が過ぎるまで待ってから次へ進みます。
5. 1年以上にする最終値は31536000（1年）以上にします。OWASPとhstspreload.orgの例は63072000（2年）です。

# 段階ごとの値（includeSubDomainsは、付けると決めた場合だけ）
Strict-Transport-Security: max-age=300; includeSubDomains
Strict-Transport-Security: max-age=604800; includeSubDomains
Strict-Transport-Security: max-age=2592000; includeSubDomains
Strict-Transport-Security: max-age=31536000; includeSubDomains

CSPの設定例と、Report-Onlyからの段階導入

CSPは、まずContent-Security-Policy-Report-Onlyという名前で配信して違反を集め、正当な取得元を許可リストに足します。違反が出なくなったら、ヘッダー名をContent-Security-Policyに変えて強制します。Report-Onlyは読み込みを何も止めないので、本番のサイトで影響だけを測れるのが利点です。

1. Report-Onlyで配信する最初は、自サイト以外の取得元を違反として記録するだけの方針にします（下の設定例）。
2. 全ページを巡回して違反を集めるトップ、記事、フォーム、決済、管理画面まで開き、Consoleの違反を記録します。
3. 許可リストを直すアクセス解析、フォント、地図、動画などの取得元を、必要なディレクティブにだけ足します。
4. ヘッダー名を変えて強制する違反が出なくなったら、Content-Security-Policyに切り替えます。さらに厳しくする案は、Report-Onlyで同時に送って試せます。
5. nonceかハッシュで厳しくするインラインスクリプトを許す 'unsafe-inline' を外し、web.devが勧める厳格なCSPへ近づけます。

# Apache（行末の\は次の行へ続く印。\の後ろに空白を入れない）
Header always set Content-Security-Policy-Report-Only "default-src 'self'; \
    img-src 'self' data: https:; object-src 'none'; base-uri 'self'; \
    form-action 'self'; frame-ancestors 'self'"

# nginx（serverブロックに書く。長い値は変数に分けて組み立てる）
set $csp "default-src 'self'; img-src 'self' data: https:; ";
set $csp "${csp}object-src 'none'; base-uri 'self'; ";
set $csp "${csp}form-action 'self'; frame-ancestors 'self'";
add_header Content-Security-Policy-Report-Only $csp always;

default-srcが代わりを務めるのは、script-srcやimg-srcなどの取得系の指定だけです。base-uri、form-action、frame-ancestorsは個別に書きます。object-src 'none' はプラグインによる埋め込みを止める指定で、web.devの推奨にも含まれる値です。

Chrome 146では、違反はConsoleに情報（Info）として表示され、末尾に『The policy is report-only』で始まる一文が付きます。強制に切り替えると同じ違反がエラーになり、末尾は『The action has been blocked.』に変わります。インラインスクリプトの違反に示される『sha256-…』の値をscript-srcに足すと、そのスクリプトだけを許可できます。

違反をサーバーに集めるには、受け口を Reporting-Endpoints ヘッダーで示し、ポリシーに report-to を足します。設定例はMDNのContent-Security-Policy-Report-Onlyにあり、古いブラウザ向けに report-uri も併記しています。受け口には、ブラウザが送るJSONを保存する仕組みが別に要ります。

強制に切り替えた後は、web.devが勧める厳格なCSPへ近づけます。web.devは、ドメインを並べる許可リスト方式は多くの構成で回避されうるとし、nonce（応答ごとの乱数）かハッシュで許可する方式を勧めています。nonceは暗号学的に安全な乱数（128ビット以上が望ましい）で、応答のたびに作り直します。

# web.devが勧める厳格なCSP（{RANDOM}は応答ごとに作る乱数）
Content-Security-Policy: script-src 'nonce-{RANDOM}' 'strict-dynamic';
    object-src 'none'; base-uri 'none';

# HTML側は、許可するscriptタグに同じ値を付ける
<script nonce="{RANDOM}" src="/js/app.js"></script>

同じヘッダーが2本届いたときに起きること

同名のヘッダーが2本届いたときの扱いはヘッダーごとに違い、HSTSは最初の1本だけ、CSPは両方が効いて厳しい側が勝ちます。X-Frame-Optionsは値が食い違うと、同じサイトの枠の中でも表示を拒否します。重複はエラーにならず黙って起きるため、確認の段階で本数を数えます。

根拠をChrome 146の動作とした行は、他のブラウザで扱いが異なる場合があります。重複を残さないことが、どのブラウザでも確実な対策です。

X-Frame-Optionsの値が食い違うと、Chrome 146はConsoleに次の例のように表示し、DENYとして扱います。

Refused to display 'https://example.com/' in a frame because it set multiple
'X-Frame-Options' headers with conflicting values ('DENY, SAMEORIGIN').
Falling back to 'deny'.

主な原因は、アプリとサーバーによる二重の付与と、Apacheの Header add やCloudflareの「Add」のような追加の操作です。付ける場所を1つに絞り、操作はsetにそろえます。

設定できたかをcurlと開発者ツールで確かめる

確認は設定ファイルではなく、外から取った実際の応答で行います。トップページ、存在しないURL、HTTPSのリダイレクト、画像やCSS、ログイン画面の5種類で、各ヘッダーが1本ずつ付いていれば合格です。

# ヘッダーだけを取得する（-IはHEADリクエスト）
curl -sI https://www.example.com/
# GETで取得し、応答ヘッダーだけを表示する
curl -s -D - -o /dev/null https://www.example.com/
# 404の応答にも付いているか
curl -sI https://www.example.com/no-such-page/
# wwwへ転送するリダイレクトに、HSTSが付いているか
curl -sI https://example.com/ | grep -i -E '^(HTTP|location|strict-transport)'
# 重複していないか（1なら合格）
curl -sI https://www.example.com/ | grep -ci '^x-frame-options:'
# Windows PowerShell 5.1は curl.exe と書き、findstrで絞る
curl.exe -sI https://www.example.com/ | findstr /i "x-frame-options"

Windows PowerShell 5.1では curl がInvoke-WebRequestの別名のため、.exe まで書きます。HEADとGETで違う応答を返すサーバーもあるので、GETの結果も見ておくと確実です。

• トップページ（200）に、入れたヘッダーがそれぞれ1本ずつ付いている
• 存在しないURL（404）にも、同じヘッダーが付いている
• wwwの有無をそろえる転送など、HTTPSのリダイレクトにHSTSが付いている
• 画像、CSS、JavaScriptにも付き、Content-Typeが種類どおりになっている
• ログイン画面や管理画面で、X-Frame-OptionsやCSPの値が食い違っていない

ブラウザでは、F12キーで開発者ツールを開き、Network（ネットワーク）タブで再読み込みします。先頭の文書を選んでHeaders（ヘッダー）のResponse Headers（レスポンス ヘッダー）を見て、CSPの違反はConsole（コンソール）タブで確かめます。

主なヘッダーをまとめて確かめるには、無料のWebサイトのセキュリティチェックも使えます。URLを入れると、HSTSの有無と有効期間、サブドメインへの適用、CSP、X-Frame-Optionsなど6種類のヘッダーを確認し、AからFの判定と直し方を表示します。ヘッダー以外の確認項目は、Webサイトのセキュリティチェック項目の一覧にまとめています。

表示や機能が壊れたときの戻し方

CSP、X-Frame-Options、Permissions-Policyは、設定を戻せば次の読み込みから元に戻ります。HSTSだけは、ブラウザが覚えた期間が残るため、すぐには戻せません。

ヘッダーの設定を1つのファイルにまとめて変更の履歴を残すと、1行の変更で戻せます。影響範囲を見極めにくい場合や、原因のヘッダーを切り分けられない場合は、診断や設定についての相談窓口からお問い合わせください。

よくある質問

関連記事

関連記事Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表 関連記事SSL/TLS証明書のチェック方法｜有効期限・チェーン・通信方式の確認手順 関連記事WordPressの脆弱性を確認する方法｜本体・プラグインの更新と対処の手順 関連記事簡易チェックと脆弱性診断の違い｜無料ツールでできることと、専門業者が必要な場面

The post セキュリティヘッダーの設定方法｜HSTS・CSPの設定例つき first appeared on 総合デジタルマーケティング企業 エスライン・テクノロジーズ.

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 総合デジタルマーケティング企業 エスライン・テクノロジーズ.