late advent calendar article: certbot

src/content/blogs/2024-12-10-certbot.md

@@ -0,0 +1,69 @@
+---
+title: Let's Encrypt 証明書を VirtualHost 含めて一括セットアップ
+description: |
+    この記事は OUCC Advent Calendar 2024 の 10 日目の記事です。Let's Encrypt 証明書を VirtualHost 含めて一括でセットアップする方法を説明します。
+author: watamario15
+category: tech
+tags: [advent-calendar]
+---
+
+この記事は [OUCC Advent Calendar 2024](https://adventar.org/calendars/10655) の 10 日目の記事です。昨日はまだ記事がないようですが、逆に明日は [AHC040に参加した件](../2024-12-11-ahc040/)が既に上がっています。本日は、遅ればせながら枠が空いていたので Let's Encrypt 証明書を VirtualHost 含めて一括でセットアップする方法を説明します。環境は例によって Ubuntu を想定しますが、他の環境でも差分は Certbot のインストール方法とパスぐらいだと思います。
+
+## Certbot とは
+
+説明するまでもない気がしますが、一応 Certbot とは何かを説明しておきます。
+
+まず、現在主流となっているプロトコルである HTTPS は HTTP を拡張したもので、データをブラウザ・サーバ間で暗号化して通信します。この暗号化通信においては鍵を使うわけですが、同時に「サーバが本物か」の確認も行います。これは、せっかく暗号化通信していても、その相手となるサーバが偽物では全く意味がないからです。それにあたり、各サーバは「私はこの証明書の通り本物のサーバである」として SSL/TLS 証明書 (Certificate) をブラウザに対して提示しますが、この証明書は通常、第三者機関 (Certificate Authority) に高額料金を支払って作成してもらう必要があります。
+
+しかし、それでは HTTPS が主要大企業にしか普及しない事態になるので、様々な企業からの後援のもと非営利団体 [Internet Security Research Group (ISRG)](https://www.abetterinternet.org/) が **[Let's Encrypt](https://letsencrypt.org/ja/)** という、無償で証明書を発行するサービスを提供しています（他の類似サービスとしては [ZeroSSL](https://zerossl.com/) などがあります）。当然ながら有償のものよりも証明書の「質」は低く信頼度も最低という位置付けですが HTTPS 対応（暗号化）には十分であり、個人サイトを中心に広く使用されています。
+
+そんな証明書ですが、有償無償問わず有効期限が定められており、それを過ぎると不正な証明書として扱われます（Let's Encrypt の場合は 90 日）。たまに見かける、突然ブラウザが警告画面を出すようになった Web サイトの裏でよく起きています。そうならないために、有効期限内に証明書の再発行を行う必要があります。きっちりした有償サービスの場合は再申請してインストールという手続きが必要になりますが、Let's Encrypt の場合はそこまで信頼度が要求されていないため、自動化プロトコルが用意されています。そのプロトコルを使用して全自動で証明書の発行・再発行を実施する公式スクリプトが **[Certbot](https://certbot.eff.org/)** というわけです。
+
+## 導入
+
+まず、Certbot をインストールします。APT に置かれているものは古くなっているようなので Snap を使います（評判はあまり良くないですが...）。互換ツールとして [lego](https://github.com/go-acme/lego) も存在するようですが、どこまで互換性があるのかは知りません。
+
+```sh
+sudo snap install --classic certbot
+```
+
+ここで、これから証明書を取得するドメインについて、既に旧サーバなどで Let's Encrypt 証明書を作成している場合は、以下のコマンドを**旧サーバ側で**実行して失効させておきます。
+
+```sh
+sudo certbot revoke --cert-name 証明書の名前（大抵は代表ドメインそのまま）
+```
+
+そして、新しいサーバ側で以下のコマンドを実行し、証明書を作成します。サーバソフトウェアが Apache でない場合は `--apache` を対応するサーバソフトウェアのプラグイン名に変えれば、同様に動作するはずです。
+
+```sh
+sudo certbot certonly --apache --agree-tos --no-eff-email -m メールアドレス -d ドメイン1 -d ドメイン2 -d ...
+```
+
+コマンドの意味は以下のとおりです。
+
+- `certonly`: 証明書発行のみ
+  - Apache の設定ファイルを勝手に変更されないようにする
+  - 複雑な設定をしていない場合は、これを外して自動で Apache の HTTPS 周りの設定をさせてもよい
+- `--apache`: Apache 用プラグインを使って認証する
+  - ReverseProxy などで実体が他サーバになっているものは DocumentRoot 下に Certbot が認証用一時ファイルを置く通常の方法を使えないため、Apache と連携して認証する
+  - メール用ドメインなどでも、80 番ポートに Apache が居る IP アドレスならこれで認証できる
+- `--agree-tos`: 利用規約に同意する（**予め内容を確認しておくこと**）
+- `--no-eff-email`: アナウンスメールなどを受信しない
+- `-m`: `メールアドレス` でアカウント登録する
+- `-d`: 証明書発行対象ドメイン（複数可）
+
+成功した旨表示されれば OK です。注意点として、サーバソフトウェア連携で認証する場合は一時的に `http://ドメイン/.well-known/acme-challenge/` が作成されて、これを Let's Encrypt 側のサーバから参照できることを確認することで認証されるので、アクセス制限などでこのパスへのアクセスを禁止していると認証が通りません。
+
+## 動作確認
+
+既に証明書が作成されているはずなので、まずはそれを実際にサーバソフトウェアに設定し、HTTPS 通信できることを確認しましょう。問題なければ、次は証明書の再発行が正しくできるかをテストします。本格稼働後に証明書の更新トラブルに見舞われないようにするため、なるべく設定などを実稼働に近づけた状態で確認することをお勧めします。
+
+```sh
+sudo certbot renew --dry-run
+```
+
+成功した旨表示されれば OK です。なお、Ubuntu の Snap 版においては自動で systemd の timer として定期的な再発行機能が設定されます。`sudo systemctl list-timers` で確認できます。
+
+## おわりに
+
+本日は、Let's Encrypt 証明書を VirtualHost 含めて一括でセットアップする方法を解説しました。Certbot の記事自体はたくさん出てきますが、大量のドメインで一部に ReverseProxy を含む特殊な VirtualHost を提供しているような環境で HTTPS 対応するための情報はなかったので、まとめてみました。個人レベルではなかなかないと思いますが、そういった環境を担っている方の参考になれば幸いです。