SSL証明書の期限切れの対処｜更新のしかたと警告が消えないときの確かめ方

• SSL証明書の期限が切れたサイトでは、訪問者のブラウザが警告画面を出します。作業する場所は、証明書をどこで更新しているかで決まります
• 自動更新が止まっていたなら次の3つの点から原因を確かめます。更新の処理が動いていないか、ドメインの確認に失敗しているか、発行された証明書が使われていないかです
• 更新したあとは、本サイトの診断 (以下、「診断」という) で読んだ証明書の有効期間の始まりが控えた値より新しくなり、証明書の問題の項目が出ていないかで確かめます
• 期限が近いと「要確認」で出ただけの場合、自動更新が有効で前回も自動で更新されていたなら何もしなくて構いません

診断の表示から、読む場所を決めてください

まずSiteKensaの診断で、警告が出ているドメインを調べてください。そのうえで表を上から順に見て、最初に当てはまる行へ進んでください。

最後の行のときは、まずその端末の日付と時刻を確かめてください。Chromeのヘルプは、端末の日付と時刻が正確でないときに次のエラーが出ることがあると書いています（Chromeのヘルプ）。

NET::ERR_CERT_DATE_INVALID

日付と時刻が正しいのにエラーが続くなら、その端末で開いているURLのホスト名を診断で調べ、表の上から見直してください。

サイトの訪問者として警告画面を見た方は、サイトの管理者に知らせてください。この記事は、サイトを運営している側の作業を書いています。

出てくる用語

ステップ 1/4：有効期間と更新している場所を控えてください

更新の前にいまの証明書の発行者と有効期間（始まりと終わり）を控えます。控えた値は、ステップ 4/4 で新しい証明書に替わったかを確かめるときに使います。

有効期間を控える

SiteKensaの診断で調べ、証明書の項目の「観測した内容を見る」を開くと発行者と有効期間が出ます。

発行者: Amazon RSA 2048 M04
対象: sitekensa.com, www.sitekensa.com
有効期間: Jul 27 00:00:00 2026 GMT 〜 Feb  9 23:59:59 2027 GMT

「〜」の前が有効期間の始まりで、後ろが終わりです。時刻は、グリニッジ標準時（GMT）で出ます。日本時間は、これに9時間を足した時刻です。

診断は、http:// で開いて転送をたどった先のホストの証明書を見ます。転送をたどれなかったときは、入力したドメイン名の証明書を見ます。入力と違うホストを見たときは、「証明書は転送先の ○○ を確認しました」と出ます。

macOSかLinuxのターミナルでも、次のコマンドで指定したホスト名の証明書を読めます。診断が転送先を見たときは、そのホスト名を入れてください。sitekensa.com の2か所を自分のホスト名に置き換えて実行してください。

$ echo | openssl s_client -connect sitekensa.com:443 -servername sitekensa.com 2>/dev/null | openssl x509 -noout -issuer -dates
issuer=C=US, O=Amazon, CN=Amazon RSA 2048 M04
notBefore=Jul 27 00:00:00 2026 GMT
notAfter=Feb  9 23:59:59 2027 GMT

notBefore が有効期間の始まりで、notAfter が終わりです（openssl-x509のマニュアル）。期限が切れた証明書でも同じ形で出ます。

$ echo | openssl s_client -connect expired.badssl.com:443 -servername expired.badssl.com 2>/dev/null | openssl x509 -noout -issuer -dates
issuer=C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
notBefore=Apr  9 00:00:00 2015 GMT
notAfter=Apr 12 23:59:59 2015 GMT

どちらも2026年9月10日にOpenSSL 3.6.3で実行した出力です。何も出ないときやエラーが出たときは、入れたホスト名を確かめてください。それでも出ないときは、診断で控えてください。Windowsを使っているときも、診断で控えてください。

更新している場所を確かめる

2つ以上に当たるとき（certbotで取った証明書をCDNに登録しているなど）は、取った場所で更新し、登録した場所でも新しい証明書に替えてください。

どれに当たるか分からない場合は、サイトを作った制作会社か、サーバーの契約者に聞いてください。問い合わせるときは、控えた発行者と有効期間を添えてください。

ステップ 2/4：自動更新が止まった原因を3つの点から確かめてください

購入して自分で入れた証明書を期限までに入れ替えていなかっただけならこのステップを飛ばして、ステップ 3/4 へ進んでください。

レンタルサーバーの無料SSLは、管理画面のSSLの設定で状態やエラーの表示を先に確かめてください。さくらインターネットは、更新が完了しなかったときにエラーのメールを送ると案内しています（無料SSL（Let's Encrypt）更新時のよくある質問）。表示やメールに原因が書かれていれば、それに従ってください。

下の3つの点で原因が分からないときは、控えた発行者と有効期間を添えて、更新している場所の事業者に問い合わせてください。

更新の処理が動いていない

この項は、自分のサーバーでcertbotを使っている場合の確かめ方です。certbotの自動更新は、certbot renew を定期的に実行する設定で動きます。certbotのガイドは、LinuxとBSDでは、その設定がcrontabかsystemdのタイマーにあるかで確かめられると書いています（Certbot User Guide）。ガイドは、crontabの典型的な場所として /etc/crontab と /etc/cron.*/* を挙げています。タイマーの一覧は、systemctl list-timers で出ます。設定が見つからないときは、同じガイドの「Setting up automated renewal」の手順で登録します。

certbot renew --dry-run は、既定ではLet's Encryptの試験用のサーバーで証明書を取るところまでを試します（同じガイド）。失敗したら表示されたエラーを控えて、次の「ドメインの確認に失敗している」も確かめてください。

certbotで --manual を使って取った証明書は、認証の処理をするスクリプト（hook）と組み合わせていなければ自動では更新されません。hookを使っていないなら、証明書を取ったときと同じ certbot --manual のコマンドをもう一度実行して更新します（Certbot User Guideの「Renewal with the manual plugin」）。

ドメインの確認に失敗している

認証局は、申し込んだ人がそのドメインを管理していることを証明書を出す前に確かめます。確かめ方の1つであるHTTP-01では、認証局が http://{ドメイン名}/.well-known/acme-challenge/{トークン} というURLにHTTPで接続し、決まった中身のファイルが置かれているかを見ます（RFC 8555 セクション8.3）。

Let's Encryptは、この確認を80番ポートで始めます。転送は、httpかhttpsの80番か443番へ向かうものに限り、10回まで追います。Webサーバーが複数台あるなら全台にファイルが要ります（Challenge Types）。このため、ドメイン名が更新を行うサーバーとは別のサーバーを指している場合、確認に失敗することがあります。確かめ方は、HTTP-01のほかにもあります。レンタルサーバーがどの確かめ方を使っているかは、事業者の案内で確かめてください。

エックスサーバーは、無料独自SSLの自動更新が失敗したときに確かめる点として、次の3つを挙げています（エックスサーバーのよくある質問）。

• ネームサーバー、または「wwwあり」と「wwwなし」の両方のAレコードが契約しているサーバーを参照しているか
• サーバーパネルの「アクセス制限」が有効になっていないか
• サーバーパネルの「サイト転送設定」や、.htaccessのリダイレクトが設定されていないか

後の2つは、一時的に解除して更新を試すよう案内しています。エックスサーバーで更新を試す操作は、このよくある質問から開ける同社の「無料独自SSL」のマニュアルで確かめてください。ほかの事業者の条件は、それぞれの案内で確かめてください。

ネームサーバーがどの事業者かは、SiteKensaの診断に「DNSの設定は ○○ 側で行います」と出ます。ネームサーバーが2社に分かれていると出たら、ネームサーバーが一致しない・2社が混ざっているときを先に読んでください。

ネームサーバーが契約しているサーバーの会社のものでない場合は、「wwwあり」と「wwwなし」のAレコードをDNSの管理場所の画面で直します。

• Aレコードに入れる値: 契約しているサーバーの会社の案内で確かめます
• 直す画面: 診断に出たDNSの管理場所の画面です。事業者ごとの画面の場所は、事業者別の設定ガイドにあります

設定を一時的に解除するなら解除する前の設定を控えてください。更新がうまくいかなかったときも、解除した設定は元に戻します（一時的に変えた設定を元に戻してください）。

発行された証明書が使われていない

新しい証明書が発行されているのに診断で読んだ証明書が替わっていないなら、WebサーバーやCDNが古い証明書を使い続けています。

Webサーバーが新しい証明書を使っているかは、ステップ 4/4 の確認で分かります。新しい証明書を読み込ませる操作は、使っているWebサーバーのソフトの説明書で確かめてください。certbotは、更新に成功したときだけ動かす処理を --deploy-hook で指定できます（Certbot User Guide）。次回からの読み込み直しは、この処理に入れておけます。CDNに証明書を登録している場合は、CDNの管理画面で新しい証明書に替わっているかを確かめてください。

ステップ 3/4：証明書を更新してください

更新している場所ごとに作業します。

• レンタルサーバーの無料SSL: 管理画面のSSLの設定から更新します。画面の手順は、事業者の案内に従ってください
• 自分のサーバーのcertbot: 管理者の権限で certbot renew を実行します。certbot renew は、更新が必要な証明書が1つも無いときも正常終了します（Certbot User Guide）。更新されたかは、表示とステップ 4/4 の確認で見ます。--manual で取った証明書は、取ったときのコマンドを実行し直します
• CDN: CDNの管理画面で更新します
• 購入して自分で入れた証明書: 購入した事業者の案内に従って新しい証明書を受け取り、サーバーや管理画面に登録します。中間証明書の入れ方も、事業者と登録先の案内に従ってください

ステップ 2/4 でDNSの設定を直した場合は、時間をおいて診断を実行し直してからもう一度更新を試してください。日を改めても失敗するときは、控えた発行者と有効期間を添えて、更新している場所の事業者に問い合わせてください。

ステップ 4/4：新しい証明書に替わったかを確かめてください

有効期間の始まりがステップ 1/4 で控えた値より新しくなっていて、診断に証明書の問題の項目が出ていなければ新しい証明書に替わっています。

SiteKensaの診断をもう一度実行し、証明書の項目が「SSL証明書は有効です (残りN日)」になっていることを確かめます。あわせて「観測した内容を見る」で有効期間の始まりを見ます。

使っているホスト名（「wwwあり」と「wwwなし」など）ごとに確かめます。どのホスト名で開かれても同じ証明書が届くとは限らないためです。診断は転送先のホストを1つだけ見るので、macOSかLinuxでは次のコマンドで1つずつ見ます。出力の読み方は、ステップ 1/4 と同じです。

$ echo | openssl s_client -connect www.sitekensa.com:443 -servername www.sitekensa.com 2>/dev/null | openssl x509 -noout -dates

有効期間の始まりが変わっていないときは、ステップ 2/4へ戻ってください。

更新のあとに「SSL証明書の中間証明書が不足しています」か「SSL証明書の連鎖の中に有効期限の切れた証明書があります」と出たときは、ステップ 3/4 で中間証明書を登録先の案内どおりに入れたかを確かめてください。「SSL証明書がこのドメイン名に対応していません」と出たときは、診断で読んだ証明書がそのホスト名に対応していません。新しい証明書にそのホスト名が含まれているかは、証明書を取った場所で確かめてください。

「古い暗号化方式が使われています」は、診断がTLS 1.2以上で接続できず、古い版のTLSを許して接続し直すとつながったときに出ます。この項目は、サーバーが使えるTLSの版についてのもので、証明書を替えても消えません。サーバーの設定でTLS 1.2以上を使えるようにしてください。設定の場所は、レンタルサーバーやCDNなら事業者の案内で、自分のサーバーならWebサーバーのソフトの説明書で確かめてください。設定が見つからないときや自分で変えられないときは、診断したホスト名と診断の結果を添えて、事業者かサイトの管理を任せている会社に依頼してください。変えたあとは同じホスト名をもう一度診断し、この項目が出なくなったことを確かめてください。

一時的に変えた設定を元に戻してください

ステップ 2/4 でアクセス制限や転送の設定を解除したなら控えておいた設定へ戻します。更新がうまくいかなかったときも、戻してください。控えていない設定は、元の値に戻せないことがあります。

戻したあとは、もう一度診断して、証明書の項目とサイトの表示を確かめてください。

戻した設定が確認の接続を妨げていたなら次の自動更新でも同じ失敗が起きることがあります。事業者の案内で、確認の接続を通したまま制限や転送を掛ける方法を確かめてください。

期限が近いと出たとき

「SSL証明書の有効期限まで残り…です」が「要確認」で出たとき、証明書の自動更新が有効で前回も自動で更新されていたなら期限が近づくのは通常の状態です。何もしなくて構いません。

「要修正」で出たとき・手で更新している場合・自動更新が動いているか分からない場合は、期限までにステップ 1/4から進めてください。certbotなら更新の処理が動いていないの確かめ方がそのまま使えます。

診断が「要確認」と「要修正」を出す目安

SiteKensaの診断は、残りが証明書の有効期間の3分の1以下になると「要確認」、6分の1以下になると「要修正」として出します。有効期間が長い証明書でも、「要確認」は残り30日、「要修正」は残り14日より早くは出ません。

表に無い有効期間なら、有効期間を3で割った日数（30日まで）が「要確認」の出始めで、6で割った日数（14日まで）が「要修正」の出始めです。

有効期間に合わせているのは正常に自動更新していても残りが小さくなる証明書があるためです。Let's Encryptは、ARIに対応していないクライアントの許容できる動きとして、有効期間のおよそ3分の2が過ぎた時点での更新を挙げています（Decreasing Certificate Lifetimes to 45 Days）。certbotは、4.0.0から残りが有効期間の3分の1を切った証明書を更新の対象にしています。有効期間が10日以下の証明書は、2分の1です（Certbot User Guide）。ARIに対応したクライアントは、認証局が示した期間をもとに更新の時刻を選びます（RFC 9773 セクション4.2）。

期限切れを繰り返さないために

Let's Encryptは、期限が近いことを知らせるメールを2025年6月4日に止めました。知らせを受け取り続けたい人に第三者の監視サービスを勧めています（Expiration Notification Service Has Ended）。以前このメールで期限に気づいていたなら別の手段が要ります。Let's Encryptは、証明書が予定どおりに更新されなかったときに知らせる監視を置くことも勧めています（Decreasing Certificate Lifetimes to 45 Days）。

ブラウザが信頼するサーバー証明書では、有効期間の上限が発行した日によって下がっていきます（CA/Browser Forum Baseline Requirements 2.3.0 の「6.3.2 Certificate operational periods and key pair usage periods」）。上限は、発行した日ごとに決まっているので、すでに発行された証明書の期限が縮むわけではありません。

上限がいま使っている証明書の有効期間より短くなれば、手で更新する回数は増えます。

Let's Encryptは、既定の有効期間を2027年2月10日に64日、2028年2月16日に45日へ短くする予定です（Decreasing Certificate Lifetimes to 45 Days）。