--- title: "SSL証明書の更新手順：certbotの自動更新と反映されない原因の確認【2026年】" url: "https://www.issoh.co.jp/tech/details/19039/" published: 2026-10-29 updated: 2026-10-29 categories: ["セキュリティ"] publisher: "株式会社一創" --- # SSL証明書の更新手順：certbotの自動更新と反映されない原因の確認【2026年】 SSL証明書の更新は、期限が切れる前に新しい証明書を発行し、サーバーに配置し直し、Webサーバーに読み込ませるまでが一連の作業です。この記事では、有効期間が2026年3月から段階的に短くなる日程、opensslで有効期限を確認するコマンド、certbotによる自動更新の設定とdry-runでの確認、更新したのに古い証明書が表示される原因の切り分け、期限切れを防ぐ監視の置き方までを順に扱います。手動更新を残してよい場面と、自動化に切り替えるべき場面の判断も条件付きで示します。 ## まとめ：SSL証明書の更新は、自動更新と反映の確認と期限監視の3つを一組で設計する 公開TLS証明書の最大有効期間は、2026年3月15日から200日、2027年3月15日から100日、2029年3月15日から47日へ短くなります。年1回の手動更新を前提にした運用は、2027年の時点で年4回近い作業に変わります。更新は自動化し、人が触る工程を残さない設計に切り替える時期です。 自動化しただけでは期限切れは防げません。新しい証明書のファイルが置かれても、nginxやApacheを再読み込みしなければ古い証明書が配られ続けます。certbotならdeployフックで再読み込みまで組み込み、外部から公開中の証明書の期限を定期的に確かめる監視を別系統で置く。この2つを足して、ようやく「更新が止まっても気づける」状態になります。 ## SSL証明書の更新が必要になる理由と、有効期間が47日まで短くなる日程 ### 証明書は書き換えられず、新しい証明書に差し替えるという更新の実体 SSL証明書（正確にはTLSサーバー証明書）には有効期限が署名付きで埋め込まれており、発行後に期限だけを延ばすことはできません。「更新」の実体は、同じドメインに対して新しい証明書を発行し直し、サーバー上のファイルを差し替える作業です。 差し替えの対象は証明書本体だけではありません。サーバー証明書と中間証明書の組（チェーン）と、対応する秘密鍵の3点がそろって初めて正しく動きます。TLSのハンドシェイクで証明書がどう検証されるかは、[TLSの仕組みとハンドシェイクの流れ](https://www.issoh.co.jp/tech/details/13318/)で詳しく扱っています。 ### 2026年3月の200日化から2029年3月の47日化まで、最大有効期間の推移 証明書の上限を決めているのは、認証局（CA）とブラウザベンダーが参加するCA/Browser Forumです。2025年4月の[Ballot SC081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/)で、最大有効期間を398日から47日へ段階的に縮める案が、発行者側25票の賛成・反対0、ブラウザ側4社全員の賛成で可決されました。 | 発行日 | 最大有効期間 | DigiCertの上限 | | ------------- | ------ | ----------- | | 2026年3月15日より前 | 398日 | 397日 | | 2026年3月15日以降 | 200日 | 199日 | | 2027年3月15日以降 | 100日 | 99日 | | 2029年3月15日以降 | 47日 | 46日 | 段階ごとの日付は[DigiCertのナレッジベース](https://knowledge.digicert.com/alerts/public-tls-certificates-199-day-validity)の整理によります。CAは上限ちょうどではなく1日短い期間で発行する例が多く、AWSのACMも同様に短縮されています（[ACMの有効期間198日化とACME対応](https://www.issoh.co.jp/tech/details/15898/)）。この規則の対象は公開TLS証明書で、社内CAが発行するプライベート証明書は含まれません。 ### Let’s Encryptの64日化・45日化で、60日固定の更新が期限切れを招く理由 無料証明書のLet’s Encryptは、すでに90日証明書を発行しており、さらに短くする計画を[公式ブログ](https://letsencrypt.org/2025/12/02/from-90-to-45)で公表しています。2026年5月13日から`tlsserver`プロファイルで45日証明書をオプトイン提供し、既定の`classic`プロファイルは2027年2月10日に64日、2028年2月16日に45日へ移ります。ドメイン認証の再利用期間も短縮の対象で、現行の30日から最終的に7時間になる予定です。 同じ記事は「60日ごとに固定で更新する運用はもう足りない」と明言しています。45日証明書を60日間隔で更新すると、15日間は期限切れのまま放置されるからです。更新間隔を日数で固定せず、残り期間の割合か、CAが示す推奨時期で判断する仕組みに移す必要があります。 ## 更新前の確認作業：公開中の証明書の有効期限・発行元・配置先を洗い出す ### opensslコマンドで公開中の証明書の有効期限と発行元を確かめる手順 更新作業の前に、いま外部から見えている証明書の期限と発行元を確認します。サーバー上のファイルではなく、実際に接続して返ってくる証明書を見るのがポイントになります。 ``` # 公開中の証明書の発行元・対象ドメイン・有効期限を表示する openssl s_client -connect www.example.com:443 -servername www.example.com /dev/null \ | openssl x509 -noout -issuer -subject -dates # 30日（2592000秒）以内に期限が切れるなら終了コード1を返す（監視スクリプト向け） openssl s_client -connect www.example.com:443 -servername www.example.com /dev/null \ | openssl x509 -noout -checkend 2592000 ``` `-servername`を付けないと、1台で複数ドメインを扱うサーバーでは別のドメインの証明書が返ることがあります。出力の`notAfter`が有効期限、`issuer`が発行したCAです。手元のOpenSSLの版による挙動差は[OpenSSL 4.0と3.5 LTSの違い](https://www.issoh.co.jp/tech/details/11733/)を参照してください。 ### 証明書の置き場所の棚卸し：Webサーバー・ロードバランサー・CDNの3層 更新漏れの多くは「どこに証明書を置いたか忘れていた」ことから起きます。同じドメインでも、TLSを終端している場所が1か所とは限りません。 - Webサーバー：nginx・Apache・IISの設定ファイルが参照する証明書ファイル - ロードバランサー：AWSのALB、Google Cloudのロードバランサーなどに登録した証明書 - CDN・ホスティング：CloudFront、Cloudflare、Vercelなどが自動発行または手動登録した証明書 - アプリケーション内部：Javaのキーストア、メールサーバー、VPN装置、IoT機器に埋め込んだ証明書 優先して洗うのは、利用者が最初に接続する層です。CDNの背後にあるWebサーバーの証明書が切れても、CDNがオリジンの検証を厳しく設定していなければ利用者には見えず、逆に設定次第では全面停止になります。各層で「誰が・何の仕組みで更新しているか」を一覧にしておくと、次の自動化の範囲が決まります。 ## certbotでSSL証明書の自動更新を設定し、dry-runで動作を確かめる手順 ### certbot renewの更新判定：残り期間が3分の1を切った証明書だけを更新 Let’s Encryptの証明書を扱う標準的なACMEクライアントがcertbotです。`certbot renew`は管理下の全証明書を調べ、期限が近いものだけを更新します。[certbotのユーザーガイド](https://eff-certbot.readthedocs.io/en/stable/using.html)によると、4.0.0以降は「残り期間が有効期間の3分の1未満」になった証明書が更新対象です。有効期間が10日以下の短期証明書では2分の1が基準になります。 4.0.0より前は「残り30日」の固定基準でした。古い版のcertbotのまま45日証明書を受け取ると、発行から15日後には毎回更新が走る計算になります。`certbot --version`で版を確認し、3系以前なら更新しておくと、証明書の有効期間が変わっても判定が自動で追従します。 ``` # certbotが管理する証明書の一覧（ドメイン・有効期限・ファイルの場所） sudo certbot certificates # 証明書ごとの更新設定はここに保存される（直接編集せず certbot reconfigure を使う） ls /etc/letsencrypt/renewal/ ``` ### systemdタイマーとcronで自動更新が登録済みかを確かめるコマンド パッケージやsnapでcertbotを入れた環境では、自動更新が最初から登録されていることが多く、二重に登録すると同じ処理が重複して走ります。まず既存の登録を確認します。 ``` # systemdタイマーに certbot の更新が登録されているか systemctl list-timers | grep -i certbot # cron に登録されているか grep -r certbot /etc/crontab /etc/cron.*/ 2>/dev/null ``` どちらにも無い場合は、ユーザーガイドが示す登録例を使います。1日2回、起動時刻を最大1時間ずらして実行する設定で、全利用者が同じ時刻にCAへ集中しないための工夫です。 ``` SLEEPTIME=$(awk 'BEGIN{srand(); print int(rand()*(3600+1))}'); echo "0 0,12 * * * root sleep $SLEEPTIME && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null ``` ### certbot renew –dry-runで更新経路をステージング環境に向けて試す 自動更新が登録されていても、ドメイン認証が通らなければ更新は失敗します。ファイアウォールで80番ポートを閉じた、Webルートの場所を変えた、DNSの事業者を移したといった変更のあとは、本番の期限が来る前に失敗に気づく必要があります。 ``` # ステージング環境に対して更新を試す（本番の証明書は置き換わらない） sudo certbot renew --dry-run # deployフックも含めて試す場合 sudo certbot renew --dry-run --run-deploy-hooks ``` `--dry-run`はLet’s Encryptのステージング環境を使うため、本番の発行回数制限を消費しません。注意点として、deployフックはdry-runでは既定で実行されません。再読み込みの処理まで確かめたいときは`--run-deploy-hooks`を付けます。 ### deployフックでnginxを再読み込みし、更新した証明書を反映させる設定例 certbotが新しい証明書を書き出しても、nginxは起動時や再読み込み時に読んだ証明書をメモリに保持したまま動きます。更新に成功したときだけ再読み込みを走らせるには、deployフック用のディレクトリに実行可能なスクリプトを置きます。 ``` # /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh #!/bin/sh # 設定に誤りがあれば再読み込みせずに終了する nginx -t && systemctl reload nginx ``` 作成後に`sudo chmod +x`で実行権限を付けます。このディレクトリのスクリプトは更新に成功したときだけ実行され、更新対象が無い日は動きません。`RENEWED_DOMAINS`という環境変数で更新されたドメインが渡されるため、ドメインごとに処理を分けることもできます。`certbot renew`の終了コードは「更新が不要だった」場合も0になるので、終了コードを見て再読み込みを判断する作りは避けてください。 ## 更新後に新しい証明書が反映されない原因と、層ごとに切り分ける手順 ### Webサーバーを再読み込みしておらず、古い証明書を配り続けている状態 「更新したのにブラウザでは古い期限が表示される」相談で最も多いのがこの原因です。確認は、サーバー上のファイルの期限と、外部から接続して返る証明書の期限を並べて比べます。 ``` # サーバー上のファイルの期限 sudo openssl x509 -in /etc/letsencrypt/live/www.example.com/fullchain.pem -noout -enddate # 外部から見た期限（前章のs_clientと同じ）と比べて、違えば再読み込み漏れ sudo nginx -t && sudo systemctl reload nginx ``` ファイルが新しく、接続先が古いなら再読み込み漏れです。[nginxの制御シグナルの説明](https://nginx.org/en/docs/control.html)のとおり、再読み込み（HUP）で新しい設定と証明書を読んだワーカーが起動し、古いワーカーは処理中の接続を終えてから止まります。停止を伴う再起動は必要ありません。なお[ssl\_certificateの説明](https://nginx.org/en/docs/http/ngx%5Fhttp%5Fssl%5Fmodule.html)にあるように、ファイル名に変数を使った設定ではハンドシェイクごとに読み込まれるため、この問題は起きませんが性能面の負担が増えます。 ### 中間証明書の欠落やチェーンの順序違いで、一部の端末だけエラーになる状態 PCのChromeでは正常なのに、Androidの一部端末や、curl・Javaで呼び出すAPIクライアントだけがエラーになる場合は、中間証明書を送っていない可能性があります。ブラウザは過去に見た中間証明書を補って検証することがあり、問題が隠れやすい箇所です。 nginxの`ssl_certificate`には、サーバー証明書を先頭に、その後ろに中間証明書を並べた1つのファイルを指定する決まりです。certbotでは`cert.pem`ではなく`fullchain.pem`を指定します。`openssl s_client -showcerts`で接続し、返ってくる証明書が2枚以上あるかを数えれば確認できます。 ### ロードバランサーやCDNに古い証明書が残っている状態の見分け方 Webサーバーの証明書を更新しても、TLSを終端しているのがその手前のロードバランサーやCDNなら、利用者に届くのはそちらの証明書です。前章のs\_clientの出力で`issuer`を見ると、どの層の証明書かを判別できます。Webサーバーで使っているはずのLet’s Encryptではなく、Amazon・Google・Cloudflareなどが発行元になっていれば、終端は手前の層です。 この場合は、各サービスの管理画面で証明書の状態を確認します。ドメイン所有の確認用DNSレコードを削除したために自動更新が止まる例が典型です。Vercelでの発行待ちの対処は[Vercelの独自ドメイン設定とSSL発行待ちの対処](https://www.issoh.co.jp/tech/details/18582/)にまとめています。 ## 期限切れを防ぐ監視：通知メール終了後の外部監視とARIによる更新時期の判断 ### Let’s Encryptの期限通知メールが2025年6月に終了した後の監視の置き方 Let’s Encryptは、期限が近い証明書の登録者へ送っていた通知メールを[2025年6月4日で終了](https://letsencrypt.org/2025/01/22/ending-expiration-emails)しました。自動更新が黙って失敗していても、CAから知らせが届くことはもうありません。 監視は、更新処理とは別の場所から行います。更新を担うサーバー自身が止まっていると、そのサーバー上の監視も一緒に止まるからです。前章の`-checkend`を別サーバーのcronや監視ツールから定期的に実行し、残り期間が有効期間の3分の1を下回ったら通知する設定が目安になります。90日証明書なら残り30日、47日証明書なら残り約15日です。同ブログでは外部の監視サービスも代替として案内されています。 ### ARI（RFC 9773）でCAが示す更新推奨期間に合わせて更新する仕組み ARI（ACME Renewal Information）は、CAが証明書ごとに「この期間に更新してほしい」という時間帯を返すACMEの拡張で、2025年6月に[RFC 9773](https://www.rfc-editor.org/rfc/rfc9773.html)として標準化されました。クライアントは`renewalInfo`というURLへ認証なしで問い合わせ、返ってきた`suggestedWindow`の開始と終了の間からランダムに更新時刻を選びます。 ARIの利点は、CAが証明書を大量に失効させる事態が起きたとき、更新を前倒しするよう指示できる点です。日数の固定基準では、失効に追従できません。Let’s Encryptも45日化に向けてARIの利用を推奨しています。使っているACMEクライアントがARIに対応しているか、対応していれば既定で有効かは、各クライアントの公式ドキュメントとリリースノートで確認してください。 ## SSL証明書の更新を自動化すべき範囲と、手動更新を残してよい場面の判断基準 ### 公開Webサーバーは自動更新が前提で、手動更新は2027年3月で運用が破綻 結論から書くと、インターネットに公開するWebサーバーの証明書は、2026年中に自動更新へ切り替えるべきです。100日上限が始まる2027年3月以降、手動更新は年4回近い作業になり、2029年3月の47日上限では年8回近くに増えます。担当者の異動や休暇が1回重なるだけで期限切れが起きる頻度です。 有料のOV・EV証明書も例外ではありません。SC081v3では、ドメイン名以外の確認情報（組織の審査結果など）の再利用期間は398日に収まるため、審査は年1回で済み、証明書の発行だけが頻繁になる形です。契約中のCAがACMEでの発行に対応しているかを確認し、対応していれば発行と配置を自動化します。「有料証明書だから手動」という区分けは、2027年3月までに見直す対象です。 ### 自動化を見送ってよい場面：社内CAの証明書と、書き換えに停止を伴う機器 手動更新を残してよいのは、次の2つに限られます。1つ目は社内CAが発行するプライベート証明書で、CA/Browser Forumの上限の対象外です。[mTLSのクライアント証明書](https://www.issoh.co.jp/tech/details/14378/)のように社内で完結する用途なら、有効期間を自社で決められます。 2つ目は、証明書を書き換えるために機器の再起動や保守窓口への依頼が必要な、組み込み機器や古いネットワーク装置です。ただし、これらを公開ドメインの証明書で動かしているなら、47日化の時点で運用が成り立ちません。手前にリバースプロキシを置いてTLSの終端を移し、機器側は社内CAの証明書に切り替える構成変更が必要です。 ### 更新運用の点検を外部の診断と組み合わせて、期限切れと設定不備を同時に潰す 自動更新の失敗は、証明書の期限が切れるまで表に出ません。棚卸しで見つかった終端の層ごとに、更新の仕組み・反映の方法・監視の有無の3点を表にし、空欄が残る層から手を入れるのが現実的な進め方です。 証明書の期限だけでなく、古いTLSバージョンの有効化や中間証明書の欠落といった設定不備は、外部からの診断で一度に洗い出せます。公開サーバーの数が多く棚卸しが追いつかない場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で証明書とTLS設定の点検をまとめて依頼する方法もあります。 ## SSL証明書の更新時期・反映されない原因・期限切れに関するよくある質問 SSL証明書の更新作業でよく寄せられる疑問に、公式ドキュメントの記述をもとに回答します。 ### SSL証明書はいつから更新できますか？ 多くのCAは期限前のどの時点でも新しい証明書を発行でき、早めに更新しても問題はありません。certbotは4.0.0以降、残り期間が有効期間の3分の1を切った時点で自動的に更新します。有料証明書では、旧証明書の残り日数を新しい証明書に繰り越すCAもありますが、2026年3月以降は上限の200日を超えて繰り越すことはできません。 ### SSL証明書を更新したのに古い期限が表示されるのはなぜですか？ 最も多い原因は、Webサーバーを再読み込みしていないことです。nginxやApacheは読み込んだ証明書をメモリに保持するため、ファイルを差し替えただけでは反映されません。再読み込みしても変わらない場合は、手前のロードバランサーやCDNがTLSを終端していないかを、opensslで接続した結果の発行元から確認してください。 ### Let’s Encryptの証明書は手動で更新できますか？ `sudo certbot renew`を実行すれば手動でも更新できます。特定の証明書だけなら`--cert-name`で指定します。ただし90日証明書を手で更新し続ける運用は、2027年の64日化、2028年の45日化で作業回数が増えるため勧めません。自動更新が動いているかを`systemctl list-timers`で確認し、無ければ登録してください。 ### SSL証明書の有効期間が47日になるのはいつからですか？ CA/Browser ForumのBallot SC081v3により、2029年3月15日以降に発行される公開TLS証明書の上限が47日になります。それまでの段階として、2026年3月15日から200日、2027年3月15日から100日です。社内CAのプライベート証明書は対象外で、Let’s Encryptは独自の日程で2028年2月に45日へ移ります。 ### SSL証明書の更新を忘れて期限が切れるとどうなりますか？ ブラウザは接続時に警告画面を表示し、多くの利用者はそこで離脱します。HSTSを設定したサイトでは警告を無視して進むこともできず、実質的にサイトが閲覧できない状態です。APIの呼び出し側では証明書検証のエラーで通信が失敗し、連携先のシステムまで止まります。期限切れに気づいたら、まず新しい証明書を発行して差し替え、Webサーバーを再読み込みします。 ## 関連記事 - [TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説](https://www.issoh.co.jp/tech/details/13318/)：証明書が検証されるハンドシェイクの流れとTLSのバージョン選び。 - [AWS Certificate Managerとは？有効期間198日化とACME対応・料金と採用判断](https://www.issoh.co.jp/tech/details/15898/)：AWS上で証明書の発行と更新を任せる場合の選択肢。 - [mTLSとは？相互TLS認証の仕組みとクライアント証明書・導入判断](https://www.issoh.co.jp/tech/details/14378/)：社内CAで発行するクライアント証明書の運用。 - [OpenSSL 4.0は非LTS｜最新4.0.3・EOL一覧と3.5 LTSの選び方](https://www.issoh.co.jp/tech/details/11733/)：証明書の確認に使うOpenSSLの版の選び方。 - [電子証明書とは？仕組み・種類・有効期限と取得方法をわかりやすく解説](https://www.issoh.co.jp/column/details/18142/)：認証局と有効期限の考え方を非エンジニア向けに整理。 --- 出典: [SSL証明書の更新手順：certbotの自動更新と反映されない原因の確認【2026年】]()（株式会社一創）