SSL/TLS証明書の期限切れ対策｜certbotとacme.shでLet’s Encryptを自動更新するLinuxサーバー実践ガイド

「SSL証明書の期限が切れてしまい、社内外のユーザーからサイトにアクセスできないと問い合わせが殺到した」——実際のインシデントとして、こういった事例は決して珍しくありません。更新タスクを手動で管理していると、忙しい時期に見落とすリスクが常につきまといます。

SSL/TLS証明書は、Webサーバーと利用者の間の通信を暗号化し、そのサーバーが正規の運営者のものであることを第三者が保証するための仕組みです。有効期限が切れると、ブラウザは即座に「安全でない接続」と判定し、ユーザーへの警告ページを表示します。企業のWebサイトや社内システムがこの状態になると、信頼性の低下だけでなく、業務停止にまで発展しかねません。

この記事では、無料のSSL証明書サービス「Let’s Encrypt」を使い、certbotとacme.shで証明書の取得・自動更新を設定する実践的な手順を解説します。Apache・nginxの両環境に対応した設定例を含め、Linuxサーバーで今日から設定できます。

SSL/TLS証明書とは？なぜ有効期限が重要か

SSL/TLS証明書（以下「証明書」）は、認証局（CA: Certificate Authority）と呼ばれる第三者機関が「このサーバーは確かに正規の運営者のものだ」と電子署名した公開鍵の証明書です。Webブラウザはこの署名を検証し、信頼できる認証局のチェーンに連なる証明書であれば「安全な接続（HTTPS）」として扱います。

証明書には有効期限があります。現在、Let’s Encryptは90日を上限としており、Google・Apple・Mozillaが共同で推進する業界方針では「2027年までに最大47日へ短縮」が予定されています。期限が短くなるほど、手動での更新管理は現実的でなくなります。自動更新の仕組みを今のうちに整備しておくことは、インフラ担当者の必須対応です。

証明書が内部で果たす役割（公開鍵基盤・信頼チェーンの構造）については、PKI（公開鍵基盤）とは？認証局・信頼チェーン・デジタル証明書の仕組みをわかりやすく解説で詳しく解説しています。TLSのハンドシェイクの仕組みについてはTLS・SSLとは？仕組み・HTTPS化・証明書の種類をわかりやすく解説も参考にしてください。

証明書の期限切れが引き起こす現実の問題

証明書が期限切れになったとき、現場で何が起きるかを整理しておきます。

・ブラウザの警告画面: Chrome・Safari・Firefoxはいずれも、期限切れ証明書のサイトに対して「この接続ではプライバシーが保護されません」などの赤い警告ページを表示します。一般ユーザーが「詳細設定」から先へ進むことはほぼありません。
・API連携の停止: 外部サービスとのREST API通信でTLSハンドシェイクが失敗し、自社サービスと連携しているシステムが一斉にエラーになります。
・メール送受信への影響: STARTTLSを使用するメールサーバーで証明書エラーが発生すると、メール配信が失敗することがあります。
・SEOへの影響: Googleはhttpsを評価要素としており、長期間の証明書エラーはクロール失敗・インデックス削除につながる可能性があります。

攻撃者視点では、期限切れ直後に同一ドメインを偽装したフィッシングサイトを立てると、ユーザーはすでに「本物サイトが怪しい状態」に慣らされているため、偽サイトへの誘導成功率が上がります。期限切れはセキュリティ上の弱点でもあります。

Let’s Encryptとは？ACMEプロトコルの仕組み

Let’s Encryptは、インターネット・セキュリティ・リサーチ・グループ（ISRG）が運営する非営利の認証局です。無料でドメイン認証（DV）証明書を発行し、自動化を前提とした設計になっています。

証明書の取得はACMEプロトコル（Automatic Certificate Management Environment）を通じて行われます。サーバーがドメインの所有権を自動的に証明し、認証局から証明書を取得する仕組みで、主な認証方式は2種類です。

・HTTP-01チャレンジ: ドメインの80番ポートに特定のトークンを配置し、Let’s Encryptのサーバーがそれを取得することでドメイン所有権を証明します。最も一般的な方式です。
・DNS-01チャレンジ: DNSのTXTレコードにトークンを設定して証明します。ワイルドカード証明書（*.example.com）の取得や、80番ポートが使えない閉域環境に適しています。

発行される証明書の有効期限は90日で、60日目を過ぎたタイミングでの更新が推奨されています。

certbotで証明書を取得・自動更新する手順

certbotはElectronic Frontier Foundation（EFF）が開発したACMEクライアントの代表的な実装です。Apache・nginxの設定ファイルを自動で書き換えてHTTPSを有効化する機能を持ち、多くのLinuxディストリビューションで標準的に使われています。

1. certbotのインストール（RHEL系・Debian系共通）

snapdを使うのが現在の推奨インストール方法です（従来のyum/aptによるインストールはメンテナンス終了済み）。

# snapdを使ってcertbotをインストール
sudo snap install --classic certbot

# シンボリックリンクを作成して実行可能にする
sudo ln -s /snap/bin/certbot /usr/bin/certbot

# バージョン確認
certbot --version

2. 証明書の取得（Apache・nginx対応）

# Apacheを使っている場合（設定ファイルの自動書き換えも行う）
sudo certbot --apache -d example.com -d www.example.com

# nginxを使っている場合
sudo certbot --nginx -d example.com -d www.example.com

# Webサーバー設定を触らず証明書だけ取得したい場合（certonly）
sudo certbot certonly --webroot -w /var/www/html -d example.com

Apacheの設定全体のセキュリティ強化についてはLinuxのApache（httpd）セキュリティ設定入門も合わせて確認してください。nginxを使っている場合はLinuxのnginxセキュリティ設定入門を参照してください。

3. 自動更新の確認とデプロイフックの設定

certbotをsnapでインストールすると、systemdのタイマーが自動で設定されます。手動でドライランを実行し、正常に動作するか確認しておきましょう。

# 自動更新のドライラン（実際には更新しない）
sudo certbot renew --dry-run

# systemdタイマーの状態確認
sudo systemctl status snap.certbot.renew.timer

# 証明書の有効期限一覧確認
sudo certbot certificates

証明書の更新後にWebサーバーのリロードが必要です。デプロイフックを使って自動実行します。

# /etc/letsencrypt/renewal-hooks/deploy/ にスクリプトを配置する
# ファイル名例: /etc/letsencrypt/renewal-hooks/deploy/reload-webserver.sh

#!/bin/bash
# 更新後にWebサーバーをリロード（Apacheの場合）
systemctl reload httpd

# nginxの場合は以下
# systemctl reload nginx

# スクリプトに実行権限を付与
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-webserver.sh

acme.shを使った代替手順（root不要・高機能）

acme.shはシェルスクリプトのみで動作するACMEクライアントです。rootなしでの運用が可能で、ワイルドカード証明書の取得や多様なDNSプロバイダAPIとの連携に強みがあります。certbotの代替として国内でも広く使われています。

1. acme.shのインストール

# 一般ユーザーで実行可能（rootなし）
curl https://get.acme.sh | sh -s email=admin@example.com

# インストール後、シェルを再読み込み
source ~/.bashrc

# バージョン確認
acme.sh --version

2. 証明書の取得とWebサーバーへのインストール

# webrootモードで証明書取得
acme.sh --issue -d example.com -d www.example.com --webroot /var/www/html

# 取得した証明書をApache用ディレクトリにインストール
# --reloadcmdで更新時にWebサーバーを自動リロード
acme.sh --install-cert -d example.com   --cert-file /etc/httpd/ssl/example.com.cer   --key-file /etc/httpd/ssl/example.com.key   --fullchain-file /etc/httpd/ssl/fullchain.cer   --reloadcmd "systemctl reload httpd"

3. 自動更新の確認

acme.shはインストール時にcronジョブを自動で設定します。設定内容を確認しておきましょう。

# cronに登録された自動更新ジョブを確認
crontab -l | grep acme

# 手動で更新テスト（--dryrunで実際には更新しない）
acme.sh --renew -d example.com --force --dryrun

# 証明書の一覧と期限確認
acme.sh --list

acme.shの証明書は ~/.acme.sh/<ドメイン>/ に保存されます。秘密鍵を含むため、ディレクトリのパーミッションを700に保ち、他ユーザーからの読み取りを防いでください。

なお、証明書の発行・検証では時刻の正確さが重要です。サーバーの時刻がずれていると検証エラーが発生することがあります。NTPセキュリティ完全ガイド｜chronydで実現する認証・監視設定でサーバーの時刻同期も確認しておいてください。

中小企業でも今日からできること

情シス1人体制でも、以下の手順を順番に実施すれば証明書の期限切れ事故はほぼ防げます。

・証明書の棚卸し: 社内のWebサーバー・VPN装置・メールサーバー・監視ツールなど、TLS証明書を使っているエンドポイントをすべてリストアップします。
・有効期限の一括確認: コマンドで各サーバーの期限を確認し、スプレッドシートにまとめます。

# 外部からドメインの証明書期限を確認するコマンド
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null   | openssl x509 -noout -enddate

・Let’s Encryptへの段階的移行: 商用証明書を使っているサーバーのうち、DV証明書で要件を満たすものからLet’s Encryptに切り替えて自動更新を設定します。
・更新失敗の通知設定: certbotのログ /var/log/letsencrypt/letsencrypt.log を監視し、ERRORが出たら管理者にメールが届くよう設定します。
・月1回の手動確認: 自動更新を設定済みでも、月1回は certbot certificates や acme.sh --list で証明書の有効期限を目視確認する習慣をつけます。

サービス間でmTLSを実装している場合はクライアント証明書の管理対象も増えます。mTLS（相互TLS認証）とは？ゼロトラスト環境でサービス間通信を保護する仕組みと実践ガイドも合わせて参考にしてください。

Linuxサーバーのセキュリティ全般については、姉妹サイトLinuxMaster.JPでコマンド操作や設定の詳細を解説しています。

よくある誤解と注意点

・「自動更新を設定したから大丈夫」という過信: cronやsystemdタイマーが正常に動いているかを定期的に確認しないと、ジョブが無音で失敗していることがあります。ドライランを定期的に手動実行して確認してください。
・更新成功≠Webサーバーが新証明書を使っている: 証明書が更新されてもWebサーバーのリロードを忘れると、古い証明書を使い続けます。デプロイフックで必ずリロードを自動実行してください。
・Let’s Encryptのレート制限: 同一ドメインへの証明書発行は1週間に5件まで。設定テスト中は --staging フラグ（または --test）を使って本番枠を消費しないようにしてください。
・OV/EV証明書が必要なケース: Let’s EncryptはDV（ドメイン認証）のみです。証明書に組織名を表示したい場合や、決済・金融系でOV/EV証明書を要求される場合は商用CAを利用してください。
・内部ドメインへの非対応: *.internal.example.local のようなプライベートドメインにはLet’s Encryptが使えません。自己署名証明書またはプライベートCAを構築する必要があります。

本記事のまとめ

証明書の期限切れは「忘れた」から起きるのではなく、「自動化していなかった」から起きます。certbotまたはacme.shを使った自動更新の仕組みを一度整備してしまえば、以後の運用負荷はほぼゼロになります。まずは社内のサーバーを棚卸しして、手動管理のものを洗い出すところから始めましょう。