個人学習プロジェクト 「Security Learning Lab（SLL）」 の学習記録です。
今回は、サブドメインをEC2に紐付け、Let’s EncryptとCertbotでHTTPS化するところまでの内容をまとめます。
学習時間
約1〜2時間
今日やったこと
- 本番ブログに影響を与えないよう、学習用のサブドメインを新設する方針を確認
- ConoHa WINGのDNS設定画面で、Aレコードとして学習用サブドメインをEC2のIPアドレスに紐付け
- ブラウザで学習用サブドメインにアクセスし、EC2のNginxが表示されることを確認
- certbotとNginx連携プラグイン(python3-certbot-nginx)をインストール
- certbotコマンドを実行し、メールアドレス登録・利用規約同意を経て証明書をリクエスト
- nginx.confのserver_nameがワイルドカード(_)のままで証明書のインストールに失敗したため、ドメイン名に書き換えて再実行
- HTTPS化に成功し、鍵マーク付きでアクセスできることを確認
学習内容
Aレコードとサブドメイン
Aレコードは「ドメイン(またはサブドメイン)が指すIPアドレス」を記録する設定。@はルートドメインそのものを表す特殊記法で、サブドメイン名を指定すると、それぞれ別のFQDN(完全修飾ドメイン名)としてIPアドレスに紐付けられる。本番ドメインに影響を与えず学習するため、新しいサブドメインを追加する形を取った。
TTLの役割
TTL(Time To Live)は、DNS情報がキャッシュされる有効時間。3600秒(1時間)であれば、その間は世界中のDNSサーバーが情報を覚えておき、期限が切れると再度問い合わせる仕組み。
certbotとLet’s Encryptの関係
certbotはLet’s Encryptプロジェクトの一部として開発された専用クライアントで、ツール自体にLet’s Encryptとの連携があらかじめ組み込まれている。–nginxオプションを使うと、証明書の取得だけでなくNginxの設定ファイルの書き換えまで自動化してくれる。
server_nameとcertbotの関係
certbotがNginxの設定に証明書を自動反映するには、対象のserverブロックに正しいドメイン名(server_name)が設定されている必要がある。ワイルドカード(_)のままだとどのブロックに設定すべきか特定できず、エラーになる。
困ったこと・つまずいたこと
certbotの証明書インストールでエラーが発生
- 何に困ったか:証明書は取得できたものの「Could not automatically find a matching server block」というエラーでNginxへの自動設定が失敗した
- どう解決したか:nginx.confのserver_nameが_のままだったことが原因と判明し、実際のドメイン名に書き換えてからcertbot install –cert-nameを再実行することで解決した
今日の学び・気づき
- DNSのAレコード追加からHTTPS化まで、実際に手を動かして一通り体験したことで、「ドメインを取得してWebサービスを公開する」という一連の流れが、単なる知識ではなく手順として身についた実感があった
- certbotのエラーメッセージを読み解く中で、以前学んだnginx.confのserver_nameの意味が実際のトラブルシューティングに直結し、過去の学習が今回の理解の土台になっていることを実感した
- 無料のLet’s Encrypt証明書でも、暗号化の強度自体は有料証明書と変わらないと知り、個人開発やサブドメインでの学習用途に十分な選択肢だと理解できた
今日の達成
HTTPS化達成
サブドメインをEC2に紐付け、Let’s EncryptとCertbotを使ってHTTPS通信を実現した。
次回やること
- Phase2の残り、またはPhase3「Docker」への準備
今日のひとこと
普段、当たり前のようにHTTPS通信のWebサイトにアクセスしている。しかし、実際に自分でHTTPS化しようと思ったら、コマンドにて必要なツールや証明書をインストールするなどの一定の工数がかかる。何気ないこと、当たり前のことでも、その実現には細かな作業のうえに成り立っていると実感した次第です。
