SSL/TLS証明書の有効期間短縮にどう備える？Certbotでの初回取得から自動更新の設定手順まで
Webサイトのセキュリティ確保に欠かせないSSL/TLS証明書ですが、近年、その有効期間を短縮する動きが急速に進んでいます。かつては数年単位で運用可能だった証明書の有効期間は、現在では90日〜100日程度となっており、将来的には40日台へと短縮される見込みです。
本記事では、証明書の有効期間の短縮が進む背景とタイムラインを整理したうえで、Linuxサーバー環境において定番のACMEクライアントであるCertbotを用いた証明書の初回取得および自動更新（フック処理・cron設定）の手順を詳しく解説します。
この記事の目次
SSL/TLS証明書の有効期間短縮が進む背景
近年、GoogleやApple、Mozillaをはじめとする主要ブラウザベンダー、およびCA/Browser Forum（証明書発行に関する業界団体）は、パブリックSSL/TLS証明書の有効期間（Validity Period）を段階的に短縮する方針を示しています。かつて最大3〜5年だった有効期間は、現在では1年未満（398日）となり、今後はさらに数ヶ月・数週間単位へと短縮されます。
有効期間の短縮が進む主な理由は以下の3点です。
秘密鍵漏洩リスクの低減
万が一、秘密鍵の漏洩や証明書の誤発行が発生した場合でも、有効期間が短ければ脅威に晒される期間（リスクウィンドウ）を低減できます。
失効検証処理（CRL / OCSP）への依存の低減
証明書の失効情報をリアルタイムで検証する仕組み（CRLやOCSP）は、通信遅延やプライバシー上の課題を抱えています。証明書自体の有効期間を短縮することで、複雑な失効検証への依存度を下げる方向へシフトしています。
暗号アジリティ（Crypto Agility）の向上
暗号アルゴリズムの脆弱化への対応や新しいセキュリティ標準への切り替えを迅速に行えるよう、証明書の全自動更新体制を業界全体で標準化することを目的としています。
証明書の有効期間短縮のタイムライン
パブリック証明書の業界規約（CA/Browser Forum）および、無料のACME認証局として広く利用されている「Let’s Encrypt」における短縮ロードマップは以下の通りです。
CA/Browser Forum（パブリック証明書全般）
| 適用時期 | 最大有効期間 | 概要・補足 |
| 2020年9月〜 | 398日（約13ヶ月） | 従来の2年（825日）から1年間へ短縮済み |
| 2026年3月〜 | 200日（約6.5ヶ月） | Ballot SC-081v3などに基づく段階的短縮が開始 |
| 2027年3月〜 | 100日（約3.3ヶ月） | 約3ヶ月運用への移行段階 |
| 2029年3月〜 | 47日（約1.5ヶ月） | 最終的な短縮段階（45日〜47日） |
Let’s Encrypt（独自の短縮ロードマップ）
| 適用時期 | デフォルト有効期間 | 認証再利用期間（Authorization Reuse） |
| 2026年5月より前 | 90日間 | 30日間 |
| 2026年5月〜 | 45日間（検証用） | オプトイン用 tlsserver プロファイルの追加 |
| 2027年2月〜 | 64日間（標準化） | 10日間 |
| 2028年2月〜 | 45日間（標準化） | 7時間（完全自動化が必要） |
運用上のポイント
証明書の有効期限が45日〜64日になると、年に6回〜8回以上の更新作業が発生するため、手動更新による運用は現実的ではありません。Webサーバーおよびインフラ層で自動更新の仕組みを構築する必要があります。
Certbotを用いたSSL/TLS証明書の初回取得と設定
ここからは、実際にLinuxサーバー上でCertbotを利用してLet’s Encrypt証明書を取得し、ApacheなどのWebサーバーにセットアップする手順を解説します。
Step 1：Certbotのインストール
お使いのディストリビューションに応じたパッケージマネージャー（または snap / pip）を用いてCertbotを導入します。
RHEL / Rocky Linux / AlmaLinux 系：
Bash
sudo dnf install -y epel-release
sudo dnf install -y certbotUbuntu / Debian 系：
Bash
sudo apt update
sudo apt install -y certbotStep 2：初回証明書の発行（HTTP-01認証）
HTTP-01認証（standalone や webroot モード）を利用する場合、対象ドメインの80番ポート（HTTP）へ外部からアクセスできる状態にしておく必要があります。以下は、Webサーバーを立ち上げる前、または一時停止して証明書を取得する standalone モードでの発行例です。
# standaloneモードで証明書を取得（※80番ポートの外部開放が必要）
Bash
sudo certbot certonly --standalone \
-d www.example.com \
-m admin@example.com \
--agree-tos --non-interactiveセキュリティ補足：80番ポートのアクセス制御について
Let’s Encrypt は多角的なネットワーク検証（Multi-Perspective Validation）を行っているため、検証用IPアドレスの固定（ホワイトリスト化）はサポートされていません。つまり、HTTP-01認証を利用する場合は「80番ポートをインターネット全体に対して常時開放する」か、以下のようなアクセス制御策を導入する必要があります。
80番ポートを常時開放することに制約がある場合は、以下の対策を検討します。
1. 検証ディレクトリの絞り込み
/.well-known/acme-challenge/* 宛の通信のみ80番ポートで許可し、その他のパスは拒否（403）またはHTTPS（443）へリダイレクトします。
2. User-Agent による絞り込み
Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org) をUser-Agentに含む通信のみを許可します（偽装対策として、パス制限との併用が推奨されます）。
Step 3：生成されるファイル群と役割
証明書の取得に成功すると、/etc/letsencrypt/live/<ドメイン名>/ ディレクトリ内に以下のシンボリックリンクが生成されます。
- cert.pem：発行されたサーバー証明書（Server Certificate）
- privkey.pem：証明書に対応する秘密鍵（Private Key）※非公開・厳重管理
- chain.pem：中間CA証明書（Intermediate CA Certificate）
- fullchain.pem：cert.pem と chain.pem を結合したファイル（Nginxや一部のWebサーバー構成で利用）
Step 4：Apacheへの証明書適用（VirtualHost設定）
取得した証明書ファイルを Apache（httpd）に組み込む設定例です（/etc/httpd/conf.d/ssl.conf など）。
Apache
<VirtualHost *:443>
DocumentRoot /var/www/html
ServerName www.example.com
<Directory /var/www/html>
AllowOverride All
Require all granted
Options -Indexes
</Directory>
SSLEngine on
SSLProtocol all -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
# Certbot で生成されたファイルへのパスを指定
SSLCertificateFile /etc/letsencrypt/live/www.example.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.example.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.example.com/chain.pem
ErrorLog /var/log/httpd/ssl_error_log
CustomLog /var/log/httpd/ssl_access_log combined
</VirtualHost>証明書の自動更新設定（certbot renew と Deploy Hook）
証明書の有効期限短縮に対応するため、証明書の自動更新スクリプトと更新後のWebサーバーの再読み込み処理を設定します。
更新実行時のWebサーバー再読み込み（–deploy-hook）
証明書ファイルが更新された際、Webサーバー側のプロセスに新しい証明書を読み込ませる必要があります。–deploy-hook オプションを指定すると、証明書が実際に更新された場合のみ指定したコマンド（systemctl reload httpd など）を実行できます。
動作確認を行う場合は、–dry-run（テスト実行）と組み合わせてコマンドを実行します。
Bash
# –deploy-hook を含めた自動更新の動作テスト（ドライラン）
sudo certbot renew --dry-run --deploy-hook "systemctl reload httpd"cron または systemd-timer による定時実行
certbot renew コマンドは、証明書の残り有効期間が30日未満（または設定された短縮閾値）になった場合のみ更新処理を行うため、毎日実行しても問題ありません。
/etc/cron.d/certbot や root の crontab に以下を追加します。
コード スニペット
# 毎日 AM 3:00 に更新チェックを実行（更新成功時のみ Apache をリロード）
0 3 * * * certbot renew --deploy-hook "systemctl reload httpd" --quietsystemd-timer を利用している場合
Ubuntu 22.04 や RHEL 9 などでは、パッケージ導入時に certbot.timer が自動登録される場合があります。その場合は /etc/letsencrypt/cli.ini 内に以下を記述しておくことで、タイマー経由の実行時にも自動でリロードが行われます。
Ini, TOML
deploy-hook = systemctl reload httpdまとめ
SSL/TLS証明書の有効期間は、今後さらに短縮が進み、数ヶ月から数週間単位での運用が前提となります。
- 期限切れのリスクを抑えるため、手作業による更新運用から早期に脱却する
- Certbot の –deploy-hook や定時タスクを活用し、証明書の更新からサーバーの再読み込みまでを完全自動化する
- 80番ポートのアクセス制御が必要な場合は、パス制限やDNS-01認証などの適切な代替案を取り入れる
インフラ全体の運用設計を見直し、証明書の更新漏れによるサービス停止を未然に防ぐ体制を整えましょう。
サーバー運用・自動化でお困りなら「ベアサポート」へ
ベアサポートでは、証明書更新の自動化設計をはじめ、Webサーバーの構築・運用・保守、障害監視まで、お客さまのシステム環境に応じた最適な運用サポートを提供しています。
「有効期間の短縮に伴う更新自動化の設計に不安がある」「ロードバランサーや複数サーバー構成での証明書同期を自動化したい」など、お困りの際はお気軽にご相談ください。
