SSL証明書が期限切れになった場合は、まずエラーと対象URLを確認し、公開サーバーが提示している証明書の有効期限を調べてください。期限切れが事実なら、サーバーや証明書の管理方法に合った手順で再発行・更新し、WebサーバーやCDNへ反映したあと、利用者と同じ経路でHTTPS接続が正常になったことを確認します。
「この接続ではプライバシーが保護されません」「NET::ERR_CERT_DATE_INVALID」と表示されても、原因は必ずしもサーバー証明書の期限切れとは限りません。パソコンの時刻が誤っている場合や、別の証明書が公開されている場合もあります。またCloudflareのエラー526は、オリジンサーバーの証明書を検証できないときに発生するもので、期限切れ以外の原因も考えられます。
この記事は「すでにHTTPSの警告・接続障害が発生し、原因を切り分けて復旧したい」Webサイト管理者向けです。症状の確認から、レンタルサーバーの管理画面・Certbotを使ったサーバー・CDNを利用した構成まで整理し、最後に復旧確認チェック表を掲載します。SSL・TLSの基本から確認したい方はSSL証明書とは？HTTPS・TLSの仕組みもご参照ください。平常時の予防監視や、ブラウザで期限を一度だけ調べる詳しい方法は別記事に分けています。
まず結論：SSL証明書が期限切れになったときの対応順序
障害発生時は原因を推測して設定変更を始めるより、事実を確認してから変更箇所を絞ることが重要です。特に本番環境では、他のサービスまで停止しないよう、管理権限・影響範囲・作業対象を整理して進めます。
最初に行う5つの作業
基本の順序は「①警告とURLを記録する → ②提示される証明書を確認する → ③該当する管理環境で更新する → ④必要に応じてWebサーバーへ反映する → ⑤公開側で復旧を確認する」です。原因が期限切れ以外と判明した場合は、証明書の更新ではなく、その原因に対応します。
このうち③と④は実際の環境によって操作が大きく異なります。共有レンタルサーバーの自動SSL、Linux上のCertbot、ロードバランサー、クラウドの証明書管理サービス、Cloudflareを同じ操作で更新できるわけではありません。先に管理方法を特定しましょう。
障害中は「警告を無視してアクセス」を案内しない
証明書の警告は、接続先が適切に認証できていないことを利用者に示すものです。実際の原因が期限切れと分かっていても、ログインや決済のために警告を無視するよう利用者へ案内するのは適切ではありません。提供者側が有効な証明書と正しい接続設定を復旧する必要があります。
利用者への影響が確認できた場合は、問い合わせ窓口や障害情報の案内先を通じて、影響しているURL・現在の対応状況・次回の情報更新予定など、確認できた事実を伝えます。原因がまだ確定していなければ「調査中」と明記します。
復旧完了は「作業終了」ではなく「外部から接続成功」
証明書を発行し直したという管理画面の表示だけでは、公開サイトが新しい証明書を提示しているとは限りません。更新後に古い証明書が残っていたり、別の接続先だけ設定が古い場合もあります。利用者がアクセスする正式なURLで警告が解消し、必要な操作ができることを確認してから復旧完了とします。
本当にSSL証明書の期限切れなのか症状を確認する
ブラウザに安全な接続の警告が表示されても、原因は複数あります。最初に警告文・エラーコード・URL・発生時刻を記録し、期限切れかどうかを確かめます。ここで誤判定すると不要な再発行や設定変更を招く可能性があります。
代表的な警告と、そこから分かること
Google Chromeでは「この接続ではプライバシーが保護されません」という警告と、NET::ERR_CERT_DATE_INVALID などのコードが表示される場合があります。このコードは証明書の日付に関係する問題の手掛かりですが、端末の時計が誤っている可能性もあります。エラーコードだけで「サーバーの証明書が失効した」と断定しないでください。
| 表示・症状 | 確認するポイント | 注意点 |
|---|---|---|
| NET::ERR_CERT_DATE_INVALID | 証明書の有効期間、端末の日時 | 時刻ずれでも発生する |
| SEC_ERROR_EXPIRED_CERTIFICATE | 公開側の証明書の有効期限 | 発生したURLを特定する |
| 証明書の名前が一致しない | SAN、wwwの有無、接続先 | 期限が有効でも発生する |
| Cloudflare 526 | Cloudflareとオリジン間の証明書 | 期限切れ以外の検証失敗もある |
| HTTPS接続に失敗 | TLS・接続先・サーバーの状態 | 証明書を取得できない場合もある |
この表は原因の可能性を整理したものです。実際の表示はブラウザや接続構成で変わります。警告のスクリーンショットを保存する際は、URL内のトークンや顧客情報などが写らないようにしてください。
自分の端末だけで起きるか、複数の環境で再現するか
まず端末の年月日・時刻・タイムゾーンが正しいか確認します。誤っている場合は正しい日時に修正して再確認します。Chromeの公式ヘルプでも、NET::ERR_CERT_DATE_INVALID は端末の日時設定が正しくないときに生じる場合があると案内されています。
可能なら別のブラウザや端末、通常利用する別の通信環境でも同じ公式URLを確認します。ただし、複数端末で発生したからといって必ず証明書期限切れとは断定できません。公開証明書の実際の有効期間を調べて裏付けを取ります。
URLの違いで影響範囲が変わらないか確認する
example.com、www.example.com、app.example.com は異なるホスト名です。すべて同じ証明書を提示する場合も、別々の証明書を提示する場合もあります。障害が発生したホスト名をそのまま記録し、勝手にwwwあり・なしを同一視しないことが重要です。
リダイレクトされるサイトでは、転送元と転送先のどちらに問題があるかも確認します。元のURLが正しい証明書を提示できない場合、転送先のページが正常でも利用者が安全に到達できないことがあります。
復旧前に記録する状況確認チェック表
影響範囲と現時点の事実を記録しておくと、変更前後の違いや作業担当者への引き継ぎが明確になります。最初の調査で確認できない項目は空欄にするか「未確認」と記録し、推測で埋めないようにしましょう。
| 確認項目 | 記録する内容 | 確認の目的 |
|---|---|---|
| 対象URL | https://example.com など正式なURL | 別ホストと混同しない |
| 確認日時 | 年月日・時刻・JSTなどの基準 | 発生経過を追う |
| 警告内容 | 文面・エラーコード | 原因を分類する |
| 証明書のnotAfter | 実際に提示された終了日時 | 期限切れの有無を確かめる |
| 影響ホスト | www、サブドメインなど | 復旧対象を洗い出す |
| 配信経路 | レンタルサーバー・CDN・ロードバランサーなど | 更新先を特定する |
| 証明書の管理者 | 社内・開発会社・サーバー事業者 | 権限のある担当へ連絡する |
| 直近の変更 | 移転、DNS変更、CDN設定変更など | 発生要因の候補を整理する |
最初に確認した時刻と障害開始時刻は違う
利用者から14時に問い合わせが届いたとしても、14時に期限切れが始まったとは限りません。証明書の終了日時が取得できる場合はその日時を、利用者からの報告時刻とは別に記録します。タイムゾーンがUTCの場合は、日本時間への換算を明記してください。
障害開始時刻を正確に特定できなければ「発生開始は調査中」と記録します。利用者へ案内する際も、把握していない範囲を断定しないことが重要です。
変更作業の前に設定と担当者を確認する
SSLの設定変更は本番サイトの通信に関わります。作業権限がある担当者が、現在の証明書の管理場所、秘密鍵の管理、Webサーバーの構成、変更手順と切り戻し手順を把握してから進めます。証明書を発行するサービスと、実際にHTTPS接続を受ける機器が別の場合もあります。
安易にサーバーを再起動したり、秘密鍵をチャットやメールへ貼り付けたりしないでください。必要な場合は運用管理者と連携し、作業内容と結果を記録します。
公開中のSSL証明書が期限切れか確認する方法
管理画面に保存された証明書ではなく、利用者の接続経路で実際に提示されている証明書を確認することが、原因を特定する第一歩です。ブラウザだけで確認できる場合もありますが、コマンドを使える担当者向けにOpenSSLの例も示します。
ブラウザの証明書表示で終了日時を確認する
Chrome・Edge・Firefoxなどで証明書ビューアーを開き、アクセス先に対応したサーバー証明書の有効期間を確認します。見るべき終了日時は notAfter に相当する項目です。中間認証局の証明書を誤って選ばないよう、対象のホスト名と発行先を確認します。
ブラウザの操作場所は更新によって変わる可能性があります。詳しい操作方法はSSL証明書の有効期限をブラウザとOpenSSLで確認する手順でまとめています。本記事では、期限切れの有無を判断したあと復旧へ進むことを中心に扱います。
OpenSSLで公開サーバーが提示する証明書を調べる
OpenSSLが利用できるLinux・macOS環境では、次のようにTLSサーバーへ接続して証明書の日付と対象情報を表示できます。example.com は説明用のドメインなので、実際には管理権限のある対象ホストへ置き換えます。このコマンドは確認用で、証明書を更新しません。
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuernotAfter に現在より過去の日時が表示されれば、その接続で取得した証明書は期限切れです。一方、証明書が取得できない場合は、ネットワークやTLSハンドシェイクの問題も考えられます。証明書の読み取り失敗を期限切れと同義にしないでください。2>/dev/null は診断メッセージを隠す指定なので、問題を調べる際は外して実際のエラーも確認します。
ファイルの期限と公開証明書の期限を取り違えない
サーバー内に新しい証明書ファイルが存在していても、Nginx・Apache・ロードバランサーなどに正しく反映されていなければ、利用者には古い証明書が提示される場合があります。ファイルの更新日時や管理画面の「発行済み」表示だけで、復旧済みとは判断しないでください。
また、CDNを利用している場合は「ブラウザ→CDN」と「CDN→オリジンサーバー」で別々の証明書が使われる場合があります。どの接続区間で期限が切れたのかを切り分ける必要があります。
原因を切り分ける：期限切れと設定不備の違い
症状が同じように見えても、対応すべき場所は違います。公開側の証明書の有効期間が過去である場合と、有効な新しい証明書があるのに適用されていない場合、端末の時計が誤っている場合を分けます。
実際に提示されたサーバー証明書の期限が過去
公開URLから取得したサーバー証明書の notAfter が過去なら、発行・更新と公開設定を確認する対象です。証明書をどのサービスで取得・更新しているか調べ、更新方式に合った手順へ進みます。すべてのサーバーにCertbotが使われているとは限らないため、管理方法を確認するまでは特定のコマンドを実行しません。
新しい証明書があるのに古い証明書が提供される
新しい証明書の発行に成功しても、Webサーバーが以前のファイルを参照していたり、反映操作が行われていなかったり、複数サーバーの一部だけ更新されている場合があります。この場合、必要なのは再発行ではなく、設定や配信経路の確認かもしれません。無用な再発行を繰り返す前に、管理側の証明書と公開側の証明書を比較します。
端末側の時計・証明書名・認証局の問題
利用者の端末だけ日時がずれている、証明書が別のドメイン名向けである、証明書チェーンが不完全であるなど、期限以外の原因もあります。公開証明書の期限が有効であれば、これらの原因を調べます。証明書が期限切れではないと判明した場合、期限切れ用の更新操作を漫然と進めないことが大切です。
Cloudflareエラー526はオリジンの検証失敗
Cloudflareの公式資料では、Full（strict）モードでオリジンサーバーの証明書を検証できないとエラー526が発生すると説明されています。期限切れは原因の一つですが、ドメイン名の不一致、信頼関係、証明書チェーンなどでも起こり得ます。エラー526を見ただけで「期限切れ確定」とせず、オリジンサーバーが提示する証明書を確認します。
レンタルサーバーや管理画面での復旧手順
共用レンタルサーバーやマネージドサービスでは、運営会社がSSL証明書の発行・更新機能を提供していることがあります。利用者がOSのコマンドを操作できない環境でも、管理画面のSSL設定から復旧できる場合があります。
手順1：対象ドメインのSSL管理画面を開く
契約中のレンタルサーバーやWebホスティングの管理画面で、対象ドメインの「SSL設定」「無料独自SSL」「証明書管理」などの項目を探します。画面名は事業者によって異なります。実際の管理画面に表示された対象ドメイン名と、障害の起きたURLが一致しているか確認してください。
サイト管理用アカウントと証明書管理アカウントが別の場合は、必要な権限のある担当者へ依頼します。プランや構成によっては、サーバー事業者側での対応が必要になることがあります。
手順2：更新失敗の表示や発行状態を確認する
管理画面に有効期限・更新状態・失敗理由が表示されている場合は、その内容を記録します。自動更新に失敗したときには、ドメイン認証、DNSの変更、サイト移転、設定上の問題などが関係している場合があります。ただし、画面に原因が表示されていなければ推測で原因を断定しません。
手順3：提供事業者の正式な再発行・更新操作を行う
管理画面で証明書の再発行・更新を実行できる場合は、対象ドメインと影響範囲を確かめ、事業者の手順に従います。自動更新設定が存在しても、手動での再発行が必要な場合や、申請の条件を直す必要がある場合があります。証明書を削除してから作り直す操作は接続をさらに悪化させることもあるため、事業者の案内がない状態で行わないでください。
手順4：完了表示のあと公開URLで確認する
管理画面に「設定完了」「発行済み」と表示されても、公開URLで新しい証明書が提示されるまで確認します。対象ホスト名ごとにブラウザ警告が消えたか確認し、ログイン・問い合わせなど重要な操作も点検します。復旧が確認できない場合は、管理画面の成功表示と公開側の期限を添えて事業者へ問い合わせると状況を伝えやすくなります。
Certbotを使っているサーバーの復旧手順
LinuxサーバーでCertbotが証明書を管理している場合は、証明書の管理状況を確認し、更新処理とWebサーバーへの反映を分けて考えます。ここに示すのはCertbotの利用が確認でき、必要な権限を持つ管理者向けのコマンド例です。未知の本番環境へそのまま実行せず、現在の構成・バックアップ・作業手順を確認してください。
手順1：Certbotが管理する証明書を一覧表示する
Certbot公式のユーザーガイドで案内される certificates サブコマンドを使います。これは証明書の一覧と名称、有効期限、保存先などの情報を調べるための操作です。
sudo certbot certificates出力の Certificate Name、Domains、Expiry Date、Certificate Path を確認します。対象ドメインが一覧にない場合は、Certbot以外で管理されている可能性もあるため、勝手に新規発行へ進まず実際の管理方法を調べます。
手順2：対象を特定して更新の実行条件を確認する
Certbotの renew は、以前取得した証明書のうち更新対象となるものを更新しようとします。--cert-name で証明書名を指定すると対象を絞れます。Certbot公式資料では、現在のバージョンでは証明書の有効期間に応じて更新対象を判断すること、--dry-run が試験的な更新であり本番証明書の更新結果を意味しないことが説明されています。
試験できる構成なら、更新条件や認証の問題がないか確かめるための --dry-run を検討できます。ただし、設定されたフックやプラグインによってはサーバーの設定変更やリロードが発生する可能性もあるため、これも本番運用担当者の確認を経て実施します。
sudo certbot renew --cert-name example.com --dry-runexample.com は certbot certificates で実際に確認した証明書名へ置き換えます。試験の成功は「本番の証明書がすでに更新された」という意味ではありません。検証後に本番の更新を別途確認する必要があります。
手順3：本番の更新を実行して結果を確認する
管理者が更新先と設定を確認したうえで実際の更新を行う場合、Certbotでは次のように対象を指定して更新できます。このコマンドは証明書の発行・更新を試みる変更操作であり、読み取り専用ではありません。本番サービスへの影響と実行権限を確認した担当者が判断してください。
sudo certbot renew --cert-name example.com実行結果に成功・失敗・更新対象外などの区別が表示されます。期限がすでに過ぎている場合でも、認証の失敗や通信の問題などが解消していなければ更新に失敗します。成功のメッセージだけで作業を終えず、実際に公開側の新しい証明書へ反映されているか確認します。
手順4：新しい証明書の参照先と適用状態を確認する
Certbotでは標準的な構成で /etc/letsencrypt/live/ 配下に証明書への参照が置かれますが、Webサーバーがそれを直接参照するとは限りません。設定ファイルの証明書パス、秘密鍵の参照先、CDNやロードバランサーなど他のTLS終端がないか確認します。
新しい証明書を用意できても、Webサーバーが古い証明書を読み込み続ける場合があります。次の章で、設定の検証と反映を分けて確認します。秘密鍵を外部へ送信したり、権限のない作業者へ渡したりしないでください。
Nginx・Apacheへ証明書を反映する際の注意点
証明書が更新されたあと、Webサーバーの設定やプロセスが新しい証明書を読み込む必要がある構成があります。すべての環境で同じ操作が必要なわけではありません。Certbotのプラグインや自動更新フックで反映まで完了する場合もあるため、二重の操作を避けてください。
Nginxは設定テストと再読み込みを分ける
Nginx公式ドキュメントでは、-t が構文や参照ファイルをテストし、-s reload が設定の再読み込みを行うと説明されています。管理者が反映作業を必要と判断した場合、まず設定テストを行い、成功が確認できてから手順に沿って再読み込みします。
sudo nginx -t設定テストが成功しており、利用環境で再読み込みが必要と確認できた場合の例です。実際の稼働方式がコンテナやマネージドサービスなら、提供環境に合う操作が必要です。
sudo nginx -s reload再読み込みができたというメッセージだけでは、利用者向けのすべての経路が復旧したことを示しません。公開ホスト名で証明書を再取得し、期限と接続を確認してください。
Apacheはconfigtestとgracefulの意味を理解する
Apache HTTP Server公式の apachectl 資料では、configtest は構文確認、graceful は設定検証を伴う穏やかな再起動として説明されています。実際の起動方式や配布形態によりコマンドが異なることがあるため、権限を持つ担当者が確認したうえで実施します。
sudo apachectl configtest設定が正常で再読み込みが必要と判断した場合の例です。事前の停止影響と手順に問題がないことを確認してください。
sudo apachectl gracefulApacheでも、新しい証明書を読み込めたかは公開HTTPS接続で確認します。設定テストの失敗を無視して再読み込みしたり、エラー内容を確認せず何度も再起動したりしないでください。
共有サーバー・コンテナ・マネージド環境では直接操作しない
同じWebサーバー製品を使っていても、運営会社の管理画面、コンテナのデプロイ、ロードバランサーの証明書設定などによって反映方法は異なります。サーバー管理者の指示がないまま上記のコマンドを実行しないでください。まずどこでTLS通信が終了するかを整理することが重要です。
Certbotの更新に失敗するときに確認する項目
更新の実行で失敗した場合、同じコマンドを繰り返す前に、失敗した段階とエラーメッセージを確認します。証明書発行のためのドメイン認証に失敗した場合と、証明書を発行できたが反映に失敗した場合では対処が異なります。
HTTP-01の検証では80番ポートと対象URLが重要
Let’s Encryptの公式資料では、HTTP-01チャレンジは80番ポートを使い、指定された /.well-known/acme-challenge/ 配下のファイルへ認証局がアクセスしてドメインの管理権限を確認すると説明されています。DNSの向き先、80番ポートの到達性、Webサーバーのルーティングなどに問題があると失敗することがあります。
ただし、すべての更新がHTTP-01を使うわけではありません。利用中の認証方式を確認し、証明書取得のために必要な経路を把握してください。認証を通すためだけに公開Webサービスの安全設定を無制限に解除するような対応は避けます。
DNS-01ではTXTレコードとDNS反映を確認する
DNS-01を利用している場合は、認証に必要なTXTレコードが正しいDNSで参照できるかを確認します。Let’s Encrypt公式資料では、DNS-01がワイルドカード証明書の発行に利用できること、DNSの反映に時間差が生じる場合があることなどを説明しています。
DNSの更新には別の管理権限が必要な場合があります。DNSの権限やAPI認証情報を必要以上に広く共有せず、ドメイン管理者と連携して設定を確認してください。
実行ログに失敗理由が出ているか確かめる
証明書の取得や更新に失敗した場合は、Certbotの実行結果と関連するログを確認します。ドメインの確認、認証局との通信、レート制限、Webサーバー設定など、原因の候補は複数あります。エラー文面が不明な状態で「証明書が壊れた」「認証局に障害がある」と決めつけないでください。
ログを外部へ共有する場合は、ドメイン・IP・認証情報・メールアドレスなどの扱いを確認し、必要部分だけを共有します。手順書に記載されていない強制更新や、管理ファイルの無断削除は避けてください。
Cloudflare・CDN利用中にSSL期限切れが起きた場合
CloudflareなどのCDNを利用している場合は、利用者から見える証明書と、CDNがオリジンサーバーへ接続するときの証明書が別になります。この区別をつけることで、更新すべき場所を間違えにくくなります。
ブラウザから見える証明書とオリジンの証明書を分ける
利用者が https://example.com へアクセスしたとき、CDNがHTTPS接続を受け付けていれば、ブラウザにはCDNが提供する証明書が表示される場合があります。一方、CDNからオリジンサーバーへのHTTPS接続には別の証明書が使われる構成があります。
ブラウザから確認した証明書が正常でも、オリジン側が期限切れなら接続に失敗する可能性があります。CDN管理画面での証明書状態と、オリジンサーバーの証明書をそれぞれ確認してください。
Cloudflare 526ではオリジン証明書を調べる
Cloudflareの公式説明では、エラー526はFull（strict）モードでオリジン証明書の検証に失敗した場合などに表示されます。期限切れのほか、ドメイン一致、発行者、証明書チェーンなども確認対象です。公式資料には別モードへの切り替えによる回避の記述もありますが、証明書の検証を弱める設定を安易に恒久対策として使うことは推奨しません。
復旧の基本は、問題のある証明書・名前・信頼関係を修正し、適切なSSL/TLSモードで接続できる状態に戻すことです。緊急回避が必要な場合も、セキュリティ上の影響と変更権限を確認したうえで担当者が判断する必要があります。
複数の配信先で証明書が異ならないか確認する
CDN、ロードバランサー、複数サーバー、IPv4とIPv6の接続先によって、別々の証明書が使われている場合があります。ひとつの経路で正常になっても、別の経路では期限切れの証明書が残る可能性があります。管理者は運用している配信経路を洗い出し、必要な場所の状態を確認します。
すべてのサイトに多拠点調査が必要という意味ではありません。まず実際の配信構成を確かめ、利用者への影響が残る経路がないかを判断してください。
やってはいけない復旧方法と注意点
障害発生時は早くサイトを表示させたくなりますが、警告を見えなくすることと安全な接続を復旧することは同じではありません。利用者の安全性を損なう可能性がある操作は、正式な復旧と区別する必要があります。
証明書警告を無視する操作を利用者へ案内しない
「詳細設定から強制的に進む」「証明書検証を無効にする」といった方法は、接続先の認証に関する安全性を損なうおそれがあります。公式サービスの利用者にこれらの操作を勧めるのではなく、提供者側で有効な証明書を設定してください。復旧するまでは機密情報の入力やログインを控えてもらう案内が必要になる場合があります。
HTTPへ戻すことを一般的な復旧方法にしない
HTTPSが使えないからといってHTTPでログインや個人情報入力を再開させると、通信の保護が失われます。証明書の問題を解消することが基本であり、HTTP化を安易な対策として扱わないようにします。
秘密鍵の流出や既存設定の破損を起こさない
証明書と秘密鍵は別です。復旧作業のために秘密鍵をメールやチャットへ貼り付けたり、外部の不明なサイトへアップロードしたりしないでください。証明書の保存先やサーバー設定を編集するときは、復旧手順を把握した権限のある担当者が作業し、必要なバックアップと変更記録を残します。
更新を何度も強制せず失敗理由を確認する
ドメイン認証やレート制限に関する問題が残っている場合、同じ更新操作を繰り返しても解決しない場合があります。実行ログと管理画面の状態を確認し、必要な設定を修正してから再試行します。原因が把握できない段階では、サービス事業者や管理担当者への確認を優先してください。
更新後にHTTPSが復旧したか確認する方法
証明書の更新操作が成功したら、必ず利用者側の経路で確認します。確認するのは証明書の有効期限だけではありません。正しいドメイン名でHTTPS接続でき、必要な画面や操作が正常に利用できる状態を目指します。
公開URLが提示する証明書の有効期限を再確認する
更新前と同じホスト名で公開証明書を確認し、notAfter が将来の日時になっているかを見ます。新しい証明書の発行に成功していても、別のサーバーやCDNが古いものを返している可能性があるため、管理画面の表示だけではなく外部から確認することが重要です。
OpenSSLで再確認する場合は、変更前と同じホスト名とSNI指定を用います。証明書ファイルの表示と、公開サーバーで提示される証明書の表示を区別し、結果が食い違う場合はWebサーバー設定や配信経路を見直します。
期限だけでなくHTTPS接続と画面を確認する
期限が未来であっても、証明書チェーンやドメイン名の不一致などがあれば警告が残ります。実際のブラウザで公式URLを開き、証明書エラーの有無を確認します。必要であれば、HTTPのリクエストがHTTPSへ正しく転送されるか、画像・CSS・JavaScriptが読み込めるかも確認してください。
CLIでHTTPの到達を確認する場合は、次のように通常のGETを使う例があります。example.com は説明用です。証明書検証を無効にする -k や --insecure は使用しません。
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/HTTPのステータスが表示されても、ログイン、申込み、決済、フォーム送信などの機能まで正常とは限りません。重要な操作は実際のブラウザで、適切な検証環境・テストデータを用いて確認します。
www・サブドメイン・CDN経路まで確認する
障害が発生したホスト名と、同じ証明書を使う可能性のある重要なホスト名を確認します。CDNや複数サーバーを利用している場合は、実際の配信経路を踏まえて確認する範囲を決めます。すべての経路が正常になったか分からない場合は、復旧済みの範囲と調査中の範囲を分けて記録します。
利用者への復旧案内は確認済みの範囲だけで行う
サービス全体で復旧したか確認できていない場合は「ログイン画面での接続は復旧を確認しました」など、確認できた内容に限って案内します。障害発生中に利用者へ状況を告知した場合は、同じ案内先で復旧確認時刻と影響範囲を更新しましょう。
SSL証明書の復旧確認チェック表
障害対応の締めくくりでは、更新作業・設定反映・外部接続・利用者影響を別々の確認項目として記録します。チェックが済んでいない項目を「完了」にしないことが、部分的な未復旧を見逃さないための基本です。
| 段階 | 確認する項目 | 完了とする条件 |
|---|---|---|
| 1．原因 | 対象ホストと証明書の終了日時 | 期限切れか別の原因か確認できた |
| 2．管理先 | 証明書を更新するサービス・担当者 | 対象環境と変更権限を確認できた |
| 3．発行・更新 | 証明書の発行または更新結果 | 対象名に対応する有効な証明書を用意できた |
| 4．反映 | Webサーバー・CDN・ロードバランサー | 必要な場所で適用を確認できた |
| 5．公開証明書 | 公開URLのnotAfterと名前 | 期限が未来で対象名に対応する |
| 6．接続 | HTTPSの警告とページの表示 | 利用者と同じ経路で正常に接続できた |
| 7．主要機能 | ログイン・問い合わせ等の操作 | 影響した必要な機能を確認できた |
| 8．周辺ホスト | www・サブドメイン・別経路 | 対象範囲を調べ未確認分を明記した |
| 9．連絡 | 対応記録と利用者向けの復旧案内 | 確認事実と完了時刻を記録・共有した |
「期限切れが直った」と「サービスが完全に復旧」は別
証明書の期限が有効になっていても、アプリの不具合や一部のサブドメインでの問題が残る場合があります。修復した部分と未確認の部分を分けることで、利用者へ過剰な復旧宣言をすることを防げます。
復旧時刻と作業完了時刻を混同しない
14時に証明書を更新し、14時15分に公開サイトの復旧を確認した場合、どの時点で利用者への影響が解消したかを正確に特定できないこともあります。そのときは「14時15分に正常接続を確認」と記録するなど、実測や確認に基づいて案内します。
障害対応の記録は、後日問い合わせを受けたときの説明材料にもなります。詳細な原因が確定していない場合は「調査中」としたまま、判明後に必要な報告へ反映してください。
復旧を確認してから行う報告と記録
障害が起きた際の技術的な復旧と、利用者への説明は別の作業です。復旧を確認した後は、影響範囲と対応の経緯を整理し、必要に応じてステータスページや個別のお知らせを更新します。
利用者への報告は事実と未確認事項を分ける
報告に含める内容は「影響した機能」「確認できた症状」「復旧確認時刻」「利用者に必要な操作」「未確認の事項」です。例えば「対象ドメインのHTTPS接続について、〇時〇分に証明書警告が表示されないことを確認しました」と、確認した内容を明示します。
「情報流出はありません」「全サービスに影響はありません」といった断定は、別途の調査で確認できていない限り避けてください。SSL証明書の期限切れが起きたことだけで、情報流出の有無を自動的に判定できるわけではありません。
担当者向けの記録には変更内容を残す
更新した証明書の対象名、管理サービス、変更した設定、作業した日時、検証に使ったURL、復旧確認結果などを残します。秘密鍵の内容や不要な内部情報を、公開向けの報告書へ掲載しないようにします。
利用者への障害の伝え方はステータスページの解説、第一報の整理方法は障害一次報告書の記事も参考になります。今回は復旧手順に重点を置いています。
SSL証明書の期限切れについてよくある質問
復旧作業で迷いやすい点をまとめます。証明書の管理方法によって対応が変わるため、状況に合わないコマンドや設定変更を実施しないことが重要です。
Q．SSL証明書が期限切れになったらサイトは必ず停止しますか？
Webサーバー自体が稼働していても、ブラウザが証明書の有効性を確認できず警告を表示し、利用者が安全にアクセスできなくなる場合があります。HTTPの応答が返るかどうかと、HTTPSで正常に利用できるかは別です。利用者の環境や証明書の状態によって表示は異なります。
Q．期限切れの証明書は再発行しないと直りませんか？
有効な新しい証明書を取得・更新する必要がある場合と、すでに新しい証明書が存在していて、公開サーバーへの反映だけができていない場合があります。管理画面の状態と公開URLで提示されている証明書を比較し、必要な対応を判断してください。
Q．Certbotの更新を実行すれば自動的に復旧しますか？
必ずしも復旧するとは限りません。更新に失敗する場合や、証明書は更新されてもWebサーバーへの反映が必要な場合があります。Certbotを利用していること、対象の証明書名、更新の実行結果、公開側への反映を確認する必要があります。
Q．エラー526なら証明書が期限切れという意味ですか？
いいえ。Cloudflareのエラー526はオリジン証明書の検証に失敗したことを示します。期限切れは一因ですが、ドメイン名の不一致、信頼できない証明書、チェーンの問題なども考えられます。
Q．無料のSSL証明書でも復旧できますか？
費用の有無だけで有効なTLS接続が決まるわけではありません。対象ドメインに対応した、利用環境で信頼される有効な証明書を適切に設定する必要があります。無料のLet’s Encryptでも、利用条件と発行・更新の仕組みが合っていればHTTPSに使えます。
Q．証明書の期限はまだ未来なのに警告が出ます。
端末の時刻、ドメイン名の不一致、証明書チェーンや認証局への信頼、CDNの別経路などを確認してください。期限が未来であることだけでは、証明書全体の検証に成功するとは限りません。
Q．更新後、いつ「復旧済み」と判断できますか？
利用者の正式なURLで、期限が有効な正しい証明書が提示され、安全なHTTPS接続ができ、影響した主要な操作が正常に利用できることを確認した段階が目安です。複数のホストや経路で影響があった場合は、それぞれの確認結果を分けてください。
Q．エンリンクは期限切れの証明書を自動復旧しますか？
現行の公開機能一覧で確認できるのは、SSL証明書の有効期限・残り日数の確認や期限接近の管理画面内通知などです。証明書の再発行やサーバーへの反映を自動的に代行する機能は公開情報で確認できないため、そのようには案内していません。
まとめ：期限切れの確認から公開HTTPSの復旧まで追う
SSL証明書の期限切れが疑われるときは、警告内容と正式なURLを記録し、公開サイトが提示している証明書の有効期限を調べるところから始めます。期限切れであると確認できたら、証明書を管理している環境を特定し、更新・設定への反映・公開側での接続確認を順に進めます。
レンタルサーバーの管理画面、Certbotによる更新、Nginx・Apacheへの反映、Cloudflareのオリジン証明書では必要な操作が違います。エラーを見ただけで原因を断定せず、設定変更を急ぐ前に影響範囲と管理権限を整理してください。復旧完了の判断には、証明書の更新結果だけでなく利用者の接続が正常であることが必要です。
今回の復旧をきっかけに、同様の障害を防ぐための確認体制を整える場合は、SSL証明書の期限切れを防ぐ監視方法をご参照ください。エンリンクでは、公開機能一覧でSSL証明書の有効期限・残り日数の表示などを案内しています。現在の条件は料金ページで確認でき、最大5サイトまで登録できる無料プランは無料登録から利用できます。エンリンクが期限切れ証明書の再発行・復旧を代行するという意味ではありません。
参考にした公式資料
以下は手順・用語を確認した一次資料です（確認日：2026年10月26日）。コマンドの実行可否は、実際のサーバー構成・管理権限・ソフトウェアの設定によって異なります。
- Google Chromeヘルプ：一般的なエラー メッセージ — 証明書警告と端末時刻の確認。
- OpenSSL：s_client公式マニュアル — TLS接続とSNIの指定。
- OpenSSL：x509公式マニュアル — 証明書の
notBefore・notAfterの表示。 - Certbot公式ユーザーガイド — 証明書一覧、更新、
--dry-run、設定管理。 - Let’s Encrypt公式：チャレンジの種類 — HTTP-01、DNS-01の認証条件。
- Nginx公式：コマンドラインパラメータ —
-tと-s reload。 - Apache HTTP Server公式：apachectl —
configtestとgraceful。 - Cloudflare公式：Error 526 — オリジン証明書の検証失敗と確認事項。
