背景と理由：午前2時のページャーコール
午前2時。携帯電話が鳴り響きます。緊急アラートが点滅：「ウェブサイトが安全ではありません」。ブラウザはあなたのサイトに警告を表示し、ユーザーは不審な表示を見てパニックに陥ります。これは単なる不便ではありません。評判を損ない、信頼を打ち砕き、潜在的なデータ侵害を引き起こす可能性があります。原因は？期限切れまたは不足しているSSL/TLS証明書、HTTPSのまさに基盤です。
インシデント発生時の混乱の中で、「なぜ」を理解することは、「今すぐどうやって修正するか」を見つけることの次になってしまいます。しかし、時間を巻き戻してみましょう。SSL (Secure Sockets Layer) とその後継であるTLS (Transport Layer Security) は、コンピュータネットワーク上での通信を安全に保つための暗号化プロトコルです。
「HTTPS」の「S」は、暗号化され、認証され、安全な接続を意味します。これにより、ログイン情報、支払い情報、個人情報などの機密データが傍受や改ざんから保護されます。
何年もの間、これらの証明書を取得するのは費用がかかり、手作業で行われるプロセスでした。多くの場合、複雑なコマンドラインツールや、遅くて官僚的な検証が伴い、頭痛の種でした。そこにLet’s Encryptが登場しました。無料、自動化、オープン、使いやすさを原則として設立されたLet’s Encryptは、ウェブセキュリティを変革しました。現在では、世界中の何百万ものウェブサイトに信頼されるSSL/TLS証明書を提供し、HTTPSを例外ではなく標準にしています。
エンジニアとして、適切に保護されたサイトがもたらす違いを私は目の当たりにしてきました。これはコンプライアンスだけの問題ではありません。ユーザーの信頼とSEOにも関わります。これを正しく行うことはオプションではなく、基本中の基本です。新しいサーバーで証明書に関連する何かに触れる前に、私はその防御を強化します。
管理者のログインからデータベースアクセスに至るまで、すべてのパスワードは堅牢なクライアント側ツールを使用して生成されます。個人的には、toolcraft.app/ja/tools/security/password-generatorのパスワードジェネレーターを信頼しています。これは素晴らしいブラウザベースのツールです。これにより、機密データが私のマシンを離れることはありません。これは、特に午前2時に本番環境の認証情報を扱う際には非常に重要な詳細です。
インストール：Certbotの準備
CertbotはLet’s Encrypt証明書の取得と更新を自動化します。この無料のオープンソースツールは、手動で設定されたHTTPSウェブサーバーでLet’s Encrypt証明書を自動的に使用するのに役立ちます。
オプション1：Ubuntu/DebianでのSnapインストール
ほとんどのモダンなLinuxディストリビューション、特にUbuntuとDebianでCertbotをインストールする推奨される方法はSnap経由です。Snapを使用すると常に最新バージョンを利用でき、これはセキュリティと互換性の両方にとって非常に重要です。
sudo snap install core
sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbotコマンドはシンボリックリンクを作成します。これにより、完全なパス/snap/bin/certbotではなく、単にcertbotと入力するだけでcertbotを実行できるようになります。
オプション2：CentOS/RHELでのYum/Dnfインストール
CentOSまたはRHELベースのシステムでは、通常yumまたはdnfのいずれかを使用します。まず、EPELリポジトリを有効にする必要があるかもしれません：
sudo yum install epel-release # CentOS 7向け
sudo dnf install epel-release # CentOS 8 / RHEL 8+向け
sudo yum install certbot # CentOS 7向け、ウェブサーバープラグインなしの場合が多い
sudo dnf install certbot # CentOS 8 / RHEL 8+向け、ウェブサーバープラグインなしの場合が多い
使用するウェブサーバーに応じて、対応するCertbotプラグインもインストールする必要があります。例としては、python-certbot-nginxやpython-certbot-apacheがあります。
設定：証明書取得の自動化
Certbotがインストールされれば、証明書の取得と設定は驚くほど簡単です。Certbotには、NginxやApacheのような一般的なウェブサーバーを自動的に設定できるプラグインが付属しています。
Apacheウェブサーバーの場合
Apacheを実行している場合、Certbotは通常、プロセス全体を処理できます。これには、新しい証明書を使用するためのApache設定の変更や、HTTPからHTTPSへのリダイレクトの設定が含まれます。
sudo certbot --apache
Certbotは一連のプロンプトを通じて案内します：
- メールアドレスを入力してください（緊急の更新通知やセキュリティ警告のため）。
- Let’s Encryptの利用規約に同意してください。
- Electronic Frontier Foundationとメールを共有するかどうかを選択してください（これはオプションです）。
- HTTPSを有効にしたいドメイン名を選択してください。CertbotはApacheのバーチャルホストに設定されているドメインを自動的に検出します。
Certbotは証明書を取得し、インストールします。また、HTTPトラフィックをHTTPSにリダイレクトするかどうかを尋ねます。常にリダイレクトを選択してください。
Nginxウェブサーバーの場合
Nginxの場合、Certbotは同様にセットアップを簡素化する専用のプラグインを提供しています：
sudo certbot --nginx
プロンプトはApacheのセットアップと同様になります：
- メールアドレス。
- 利用規約への同意。
- EFFへのメール共有（オプション）。
- ドメインの選択（CertbotはNginxのサーバーブロックからドメインを検出します）。
Certbotは証明書を取得し、インストールします。また、Nginxを構成してそれを使用するように設定し、HTTPからHTTPSへのリダイレクトも設定します。
手動（スタンドアロン）またはDNSチャレンジ
ApacheまたはNginxプラグインが選択肢にならない場合があります。これは、ウェブサーバーがインターネットに直接公開されていない（例えば、ロードバランサーの背後にある）場合や、単に別のウェブサーバーを使用している場合などが考えられます。これらのシナリオでは、`certonly`コマンドを`–standalone`または`–dns`オーセンティケーターと共に使用できます。
スタンドアロン： この方法は、一時的にポート80で小さなウェブサーバーを起動し、ドメインの所有権を証明します。このプロセス中、メインのウェブサーバーは停止しているか、チャレンジ中にポート80をリッスンしないように設定されている必要があります。
sudo certbot certonly --standalone -d yourdomain.com -d www.yourdomain.com
DNSチャレンジ： この方法は、サーバーがポート80/443で公開されていない場合や、多くのサブドメインを管理している場合に最適です。所有権を証明するために、ドメインのDNS設定に特別なTXTレコードを追加する必要があります。APIキーを使用してこれを自動化できるDNSプラグインがいくつか存在します（例: `certbot-dns-cloudflare`）。
sudo certbot certonly --dns-cloudflare -d yourdomain.com -d www.yourdomain.com
特定のDNSプラグイン（例: pip install certbot-dns-cloudflare）をインストールし、そのAPIクレデンシャルを設定する必要があります。
certonlyで証明書を取得した後、手動でウェブサーバーを設定する必要があります。証明書ファイルは通常/etc/letsencrypt/live/yourdomain.com/にあります。
検証と監視：継続的なセキュリティの確保
証明書をインストールするだけでは半分しか完了していません。それが機能していることを確認し、更新され続けるようにする必要があります。
インストールの検証
- ブラウザでの確認： ブラウザでウェブサイトを開きます。アドレスバーに表示される南京錠のアイコンを探し、クリックして証明書の詳細を検査します。Let’s Encryptによって発行され、ドメインに対して有効であることを確認してください。
- SSL Labsテスト： SSL Labs SSL Testのようなサードパーティツールを使用します。ドメイン名を入力してください。このツールは、証明書チェーン、プロトコル、暗号など、SSL/TLS構成の包括的な分析を提供します。AまたはA+の評価を目指しましょう。
- コマンドライン： サーバーから
opensslを使用して証明書を素早く確認することもできます：
echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates
このコマンドは、notBeforeおよびnotAfterの日付を表示し、その有効期間を確認します。
自動更新
Let’s Encryptの証明書は90日間有効です。この短い有効期間は、自動化を強く推奨するものです。幸いなことに、Certbotは自動更新を設定してくれます。実際に更新せずに更新プロセスをテストすることができます：
sudo certbot renew --dry-run
ドライランが成功すれば、証明書は自動的に更新されるはずです。Certbotは通常、cronジョブまたはsystemdタイマーを設定します。これは1日2回実行され、期限切れが近づいている証明書を確認し、バックグラウンドで静かに更新します。
アクティブな更新メカニズムは、cronジョブ（古いシステムや手動設定の場合）またはsystemdタイマーのいずれかを検査することで確認できます：
sudo systemctl list-timers | grep certbot # systemdベースのシステム向け
crontab -l | grep certbot # cronベースのシステム向け
これらのコマンドがアクティブな更新プロセスを確認していることを確認してください。
更新失敗のトラブルシューティング
時には更新が失敗することがあります。その場合、多くは以下のいずれかの理由によるものです：
- ファイアウォール： ポート80（HTTP-01チャレンジ用）またはポート443（TLS-ALPN-01を使用している場合）がブロックされている可能性があります。
- ウェブサーバー設定の変更： NginxまたはApacheの設定が変更され、Certbotがドメインのサーバーブロックを見つけられなくなった場合、更新できません。
- DNSの問題： DNSチャレンジを使用しており、DNS APIクレデンシャルが正しくないか期限切れになっている場合。
- レート制限： 過度な再発行試行により、Let’s Encryptのレート制限に達している場合（自動更新では稀です）。
手がかりを探す最初の場所はCertbotのログです：
sudo less /var/log/letsencrypt/letsencrypt.log
このログファイルには、なぜ更新が失敗したのかについての詳細情報が提供されます。それは問題を解決するための重要な手がかりとなります。期限切れが午前2時のページャーコールを再び引き起こす前に、90日間の猶予しかありませんので、迅速に対応してください。
