期限切れSSL証明書の直し方：手順を順番に

「証明書の期限切れ」が実際に意味すること

TLS証明書はどれも2つの日付を持ちます。これ以前は無効とこれ以降は無効。ブラウザーは接続のたびに時計をこの日付と突き合わせます。これ以降は無効の日付を過ぎると、証明書は何の有効な証明にもならないため、ブラウザーは続行を拒み、サイトの代わりに全画面の警告を表示します。

ここから3つのことが導かれ、これがこの問題を見た目の話ではなく緊急の話にしています。

• サーバー側は何も壊れていません。サイトは動き、ファイルも問題なく、データベースも問題ない。日付が過ぎただけです。
• 徐々に悪くなるのではありません。縮退運転はなく、期限切れの瞬間までサイトは動き、その後はすべての訪問者に警告ページが出ます。
• 影響はブラウザーにとどまりません。APIクライアント、モバイルアプリ、決済事業者からのWebhook、厳格なHTTPライブラリを使うものはすべて接続を拒みます。しかも多くは、はるかに分かりにくいエラーで。

直し方はいつも同じ形です。新しい証明書を取得し、導入し、それを配信しているサービスを再読み込みする。この問題で費える時間の大半は、1番目ではなく2番目と3番目の手順に消えます。

まず、本当に期限切れなのかを確認する

見た目の似た警告ページを出す問題はいくつもあり、対処はそれぞれまったく違います。見出しではなくエラーコードを読んでください。

• NET::ERR_CERT_DATE_INVALID——これが期限切れです（またはサーバーの時計が大きく狂っている）。このまま読み進めてください。
• NET::ERR_CERT_COMMON_NAME_INVALID——証明書は有効ですが、アクセスした名前を覆っていません。wwwや新しいサブドメインが漏れている場合によくあります。
• NET::ERR_CERT_AUTHORITY_INVALID——自己署名、発行元が信頼されていない、あるいはサーバーが送る内容に中間証明書が欠けている。
• SSL_ERROR_BAD_CERT_DOMAIN（Firefoxの表現）——上と同じ名前の不一致です。

日付は、いま開いているブラウザーではなく自分のマシンの外から確認してください。ローカルのキャッシュや古いプロキシに惑わされないためです。SSL証明書チェッカーなら、発行元、有効期間の開始と終了、残り日数、そして証明書が覆うすべての名前が分かります。終了日が過去なら確定であり、同時に必要な名前が証明書に入っているかも分かるので、同じ作業を二周せずに済みます。

再発行と導入：4つの手順

この4手順が作業のすべてです。3番目が、みなが飛ばすところです。

1. 新しい証明書を取得する

Let's Encryptや任意のACMEクライアントなら、通常はコマンド1つ——certbot renew、または管理画面の更新ボタンです。単に期限を過ぎているのではなく更新が失敗しているなら、下の更新失敗の節に進んでください。同じコマンドをもう一度実行しても同じように失敗します。

有料証明書では、CSRを作り直し、ドメイン検証をやり直し、発行されたファイルをダウンロードする必要があるかもしれません。CSRを作った秘密鍵は保管しておいてください。それがなければ証明書は役に立ちません。

2. 証明書だけでなく、チェーン全体を導入する

サーバーは、あなたの証明書と、それを信頼されたルートへつなぐ中間証明書を送る必要があります。認証局は通常、リーフのファイルとバンドル（チェーン）ファイルの両方を渡します。リーフだけを入れると一部のクライアントで発行元が無効というエラーになり、「自分のブラウザーでは見られる」という説明のつかない状況が生まれます。ブラウザーはほかのサイトから中間証明書をキャッシュしていることが多く、新しいクライアントはそうではないからです。

設定はチェーン全体のファイル（Let's Encryptではfullchain.pem）と、対応する秘密鍵を指すようにします。

3. サービスを再読み込みする

ファイルを書くだけでは何も変わりません。動いているプロセスは起動時に古い証明書をメモリへ読み込んでおり、指示がない限りそれを配信し続けます。nginx、Apache、Caddy、HAProxy、ロードバランサー、あるいはTLSを終端しているものを再読み込みしてください。正しく更新した証明書がそれでも期限切れと表示される理由は、圧倒的にこれです。

TLSが別の場所で終端されている場合——CDN、リバースプロキシ、マネージドのロードバランサー、プラットフォームのエッジ——新しい証明書が必要なのはそこであり、オリジンサーバー上のファイルは無関係かもしれません。

4. 外から検証する

本番のホスト名を自分のネットワークの外からもう一度調べ、新しい終了日と覆う名前を確認します。自分のブラウザーは信用しないでください。キャッシュされた接続や中間ページをまだ見せている可能性があります。wwwとApexの両方がサイトを配信しているなら別々に確認を。証明書が別であることがあります。

自動更新が静かに止まっていたとき

ACMEクライアントがあるのに証明書が切れたということは、更新が何週間も失敗していたということです。たいていは誰も読まないcronジョブの中で。よくある原因を、おおよその頻度順に。

• HTTP-01チャレンジがサーバーに届かなくなった。HTTPの通信をすべてHTTPSへ送る新しいリダイレクト、ファイアウォール規則、あるいは/.well-known/acme-challenge/を捕まえるリライトが検証を壊します。このパスは平文のHTTPで到達できるままにしておく必要があります。
• DNSが変わった。名前が別の場所を指すようになり、トークンを持たないホストがチャレンジを返している。最近ホスティングを移したならほぼこれです。名前を問い合わせ、DNSクエリツールで実際にどこへ解決するかを確かめてください。
• 証明書に載っている名前が消えた。ACMEは一式をまとめて更新するため、解決しなくなった廃止済みのサブドメイン1つで、まだ生きている名前も含め更新全体が失敗します。
• タイマーやcronが動いていない。サーバー移行やOSのアップグレードの後、systemdのタイマーやcronのエントリーが単純に消えていることがよくあります。
• クライアントが古すぎる。ACME v1のエンドポイントはとうに停止しており、数年更新していないクライアントでは何も更新できません。

もう一度スケジュールして期待するのではなく、手で更新を実行してエラーを読んでください。ドライランは、次の自動実行が成功するかどうかを教えてくれます。重要な問いはそれだけです。

証明書は問題なく、チェーンが問題のとき

自分の証明書は十分に有効なのに、それでもサイトが失敗することがあります。よくある説明は、チェーンの中間証明書が期限切れになっているか、サーバーが、すでに期限の切れたクロス署名ルートを含む古いチェーンを送っている、というものです。

これは2021年に有名な障害を起こしました。広く使われていたルートが期限切れになり、古いチェーンを配信していた何千ものサイトが、当時の最新ブラウザーでは完全に正常に見えながら、古いクライアントで失敗し始めたのです。症状は特徴的で、最新のデスクトップブラウザーは満足し、一方で古い端末、一部のモバイルアプリ、サーバー側のHTTPクライアントが接続を拒みます。

対処は、何年も前にダウンロードしたファイルではなく、認証局がいま公開しているチェーンを入れ直し、そして再読み込みすること。自分が送っていると思っているものではなく、サーバーが実際に送っているものを確かめ、チェーンの各証明書とその期限を証明書チェッカーで確認してください。

直したのにまだ「期限切れ」と出る理由

更新し、導入し、再読み込みしたのに警告が消えない。次の順に当たってください。

• TLSを終端しているのは別のもの。オリジンの前のCDNやプロキシが、訪問者には自分の証明書を出しています。そちらを更新します。
• その名前の後ろにサーバーが複数ある。ロードバランサーの背後に複数のバックエンドがある場合、1台だけ入れ替えても訪問者のおよそ半分は古いものを見ます。ページを再読み込みすると直ることがある、というのがその手がかりです。
• ブラウザーがキャッシュ状態を見せている。プライベートウィンドウ、別のブラウザー、あるいはネットワークの外からの確認を試してください。
• バーチャルホストが複数あり、更新したのは1つ。試したホスト名は訪問者が使う名前ではありません。名前ごとに確認します。
• 再読み込みが実際には起きていない。設定テストの失敗は、サービスが古い設定と古い証明書のまま動き続けていることを意味する場合が多い。コマンドの終了コードだけでなく、サービスの状態を見てください。

二度と起こさないために

期限切れは、最も防ぎやすい障害です。期日が何か月も前から公開されているのですから。

• 更新を自動化し、その自動化を検証する。ACMEクライアントとタイマー、そして自分の目で成功を確かめたドライラン。検証していない自動化は自動化ではありません。
• 稼働監視ではなく残り日数を監視する。死活監視は期限切れの瞬間まで合格し続け、事前には何も教えません。21日と、もう一度7日で通知を。
• 証明書の名前一覧を正直に保つ。廃止したサブドメインは外し、死んだ名前が更新全体を落とさないようにします。
• 有効期間の短縮に備える。証明書の寿命は年々短くなっており、さらに短くなる見込みです。人間が覚えていることに頼る運用は壊れます。自動化はもう任意ではありません。
• 移行のあとはチェーンを確認する。ホスティングの引っ越しは、古い中間証明書や忘れられたTLS終端が姿を現す瞬間です。

証明書に何が入っているのか、チェーンをどう読むのかを通して知りたい場合は、SSL/TLS証明書を確認するためのガイドが各項目をたどっています。

よくある失敗

• 新しい証明書を入れてサービスを再読み込みしない。「直したのにまだ壊れている」の最大の原因です。
• 中間チェーンなしでリーフだけ入れる。自分のブラウザーでは動き、ほかのクライアントでは失敗します。
• 失敗する更新をそのまま再実行する。同じように失敗します。まずエラーを読んでください。
• すでに使っていたブラウザーで直ったと判断する。ネットワークの外から検証を。
• Apexを直してwwwを忘れる、またはその逆。
• 慌てて秘密鍵を消す。それがないと新しい証明書を導入できません。
• 期限切れの警告を稼働監視に期待する。それはできません。

まとめ

期限切れの証明書はサーバーの問題ではなく日付の問題です。エラーが本当にNET::ERR_CERT_DATE_INVALIDかを確認し、新しい証明書を発行し、対応する秘密鍵とともにチェーン全体を導入し、TLSを終端しているサービスを再読み込みして、新しい期限を自分のネットワークの外から検証します。更新が自動のはずだったなら、もう一度スケジュールする前に、なぜ止まったのかを突き止めてください。たいていはACMEチャレンジのパスが塞がれている、DNSが変わった、サブドメインを廃止した、のどれかです。そのうえで残り日数を監視し、次の期限がゼロに達しないようにします。任意のドメインの証明書とチェーン、正確な期限は無料のSSL証明書チェッカーで確認でき、名前がどこを指しているかはDNSルックアップツールで確かめられます。

関連ツールとガイド：

• SSL証明書チェッカー — 任意のドメインの SSL 証明書、発行者、有効期限、残り日数を確認。
• セキュリティヘッダーチェッカー — HSTS、CSP、X-Frame-Options など主要なセキュリティヘッダーを確認。
• SSL証明書チェッカー：SSL/TLS証明書を確認する完全ガイド — SSL証明書チェッカーで任意のドメインのSSL/TLS証明書を調べる方法

よくある質問