SSL 期限切れの警告が出た時の直し方｜Web 担当者の緊急対応
目次
この記事でわかること
- SSL の警告が出た瞬間にやるべき確認 3 ステップ
- 自社環境別（レンタルサーバー / 自社サーバー / Cloudflare 等の CDN）の修正手順
- 復旧後に再発を防ぐための備え
SSL の役割を含めた基礎は SSL とは｜Web 担当者向けにわかりやすく解説 でも整理しています。
警告が出た瞬間の影響を理解する
ブラウザに「この接続は安全ではありません」「保護されていない通信」「NET::ERR_CERT_DATE_INVALID」といった画面が出ているとき、サイトのアクセスはほぼ止まっています。一般のユーザーは警告を突破しないため、フォーム送信・決済・問い合わせはすべて停止します。期限切れ以外の原因（HTTP 配信 / ドメイン不一致 / mixed content）も含めた切り分けは Chrome「保護されていない通信」警告の直し方 を併読してください。
社内システムや基幹システムでもサーバー間通信が止まっている可能性があります。決済代行のコールバック、外部 API、メール基盤などが連鎖的に停止しているかを、復旧後に必ず点検してください。
直し方の前に：3 ステップで原因を特定する
闇雲に証明書を再発行する前に、原因を切り分けます。
ステップ 1: 警告メッセージの種類を確認
ブラウザが出すエラーコードによって、原因がほぼ特定できます。
NET::ERR_CERT_DATE_INVALID→ 期限切れ（最も多い）NET::ERR_CERT_AUTHORITY_INVALID→ 認証局が信頼されていない（自己署名 or 中間証明書の不備）NET::ERR_CERT_COMMON_NAME_INVALID→ ドメイン名と証明書が一致しないSSL_ERROR_BAD_CERT_DOMAIN→ 上記と同義（Firefox 系の表記）NET::ERR_CERT_REVOKED→ 証明書が失効されている
ステップ 2: 期限を実際に確認する
ブラウザのアドレスバー左の鍵マーク（または警告マーク）→ 「証明書」→ 「詳細」で有効期間が確認できます。コマンドラインから確認したい場合は次の openssl コマンドが便利です。
echo | openssl s_client -servername example.co.jp -connect example.co.jp:443 2>/dev/null | openssl x509 -noout -dates
notAfter の日付が現在より過去であれば期限切れ確定です。
ステップ 3: 影響範囲を確認
メインドメイン（example.co.jp）と www サブドメイン（www.example.co.jp）、その他キャンペーン用サブドメインなど、複数ドメインで同じ証明書を使っている場合は同時に切れています。SSL 証明書 単発チェック でドメインごとに状態を確認するのが速いです。
環境別の即時対応手順
Let's Encrypt + 自社サーバーの場合
# certbot を使っている場合（特定証明書を指定）
sudo certbot renew --cert-name example.co.jp --force-renewal
sudo systemctl reload nginx # または apache2
renew がエラーで止まる場合は、acme クライアントの認証経路（HTTP-01 / DNS-01）に問題があります。よくあるのは:
- ドメイン認証用の
.well-known/acme-challenge/が 404 / リダイレクトに変わっている - DNS-01 を使っているのに API トークンの権限が不足している
- 80 番ポートが塞がれている
レンタルサーバー（Xserver / ConoHa Wing / ロリポップ等）の場合
各社の管理画面に「SSL 設定」「無料 SSL」のメニューがあります。Xserver なら「サーバーパネル」→ 「SSL 設定」→ 対象ドメインの「独自 SSL 設定追加」から Let's Encrypt を再取得できます。所要は 5 分程度ですが、反映まで数十分待つケースがあります。
Cloudflare 配下のサイトの場合
Cloudflare ダッシュボード → SSL/TLS → Edge Certificates から Cloudflare が発行する Universal SSL の状態を確認します。「Pending」のまま止まっていることがあり、その場合は CAA レコードの確認、Cloudflare のネームサーバー設定の確認が必要です。
商用証明書（Cybertrust / GMO グローバルサイン / セコム等）の場合
各認証局のマイページから更新手続きを行います。発行に審査時間（数営業日）がかかるため、即時復旧は困難です。一時的に Let's Encrypt 等の無料証明書で繋ぐのも実務的な対応です。
復旧したら、必ず確認すること
警告が消えたあとも、油断せずに次の 3 点を確認します。
1. 全サブドメインの状態確認
メインだけ更新できても、mail. app. api. 等が古いままだと、メール送信や API 連携で別の問題が起きます。
2. 中間証明書チェーンの完全性
サーバーに証明書をアップロードしたとき、中間証明書（intermediate certificate）の追加を忘れると、一部の OS / ブラウザで「認証局が信頼されていません」エラーが出ます。SSL Labs のテストサイトや SSL 証明書 単発チェック でチェーンを確認してください。チェーンが途切れていたときの原因特定と修復は SSL chain incomplete の原因と修復手順 で詳しく解説しています。
3. HSTS と HTTP リダイレクトの整合
HSTS（Strict-Transport-Security）が設定済みのサイトで証明書が切れた場合、HSTS が有効な期間中は HTTP へフォールバックできず、警告画面のまま放置されます。HSTS の max-age 設定を確認しましょう。
再発を防ぐ 3 つの備え
備え 1: 自動更新を有効化する
Let's Encrypt は 90 日ごとの更新を前提とした設計です。手動運用では必ず取りこぼします。自動更新の設定方法と「自動更新が壊れる代表的なパターン」は SSL 自動更新の仕組みと現実解 で詳しく解説しています。
備え 2: 期限前アラートを複数チャネルで受け取る
担当者 1 人のメールにのみ届く通知は、退職・異動・長期休暇のタイミングで取りこぼされます。共有メールアドレスとチャットツール（Slack / Chatwork 等）の両方に、期限の 30 日・14 日・7 日・1 日前の段階通知が届く運用が安全です。
備え 3: 年 1 回の棚卸し
未使用ドメインや忘れられたサブドメインに古い証明書が残っているケースは頻発します。詳しい確認手順は SSL 証明書の有効期限を確認する 3 つの方法 を参照してください。
まずは現状を把握しましょう
警告が消えたあとも「他のドメインは大丈夫か」「自動更新は本当に動いているか」が気になる方は、SSL 証明書 単発チェック で 30 秒の現状診断ができます。複数ドメインの棚卸しから自動更新セットアップまでまとめて任せたい場合は、SSL 棚卸し・自動更新支援（5 万円〜）でご相談ください。
緊急対応が必要な状況であれば、お問い合わせフォーム で「SSL 関連のご相談」を選択してご連絡ください。状況を伺った上で 24〜48 時間以内の応急対応をご提案します。