AWSのAWS Certificate ManagerでSSL証明書を発行してもうら時に、疑問に思って調べたことメモしておきます。
先に自己所有のドメインをもっておくことが必要
ドメインを所有していることが【絶対条件】です。
SSL/TLS証明書というのは、いわば「ウェブサイトの身分証明書」です。
そして、その身分証明書は「このドメイン（住所）は、たしかにこの人（あなた）が正当に所有しています」ということを、第三者機関（今回でいえばAWS）が証明するために発行されます。
そのため、身分証明書を発行してもらう大前提として、まずその住所（ドメイン）をご自身で所有している必要があります。
もし、まだドメインをお持ちでない場合は、ムームードメイン、あるいはAWSのRoute 53といったサービスでドメインを取得するところから始めることになります。
既存サイトを別で運営しているときに、わざわざそこのサーバからSSL証明書をとってこなくて良い、ということ？
これこそが、最大のポイントであり、メリットです。
現在お使いのサーバー（例：レンタルサーバー）で取得した有料のSSL証明書があったとしても、それをわざわざAWSに持ってくる（インポートする）必要は全くありません。
AWSへ移行するにあたり、AWS（ACM）で新しく無料の証明書を発行して、それを使ってしまう方が、はるかに簡単で、今後の運用も楽になります。
なぜ、新しく発行する方が良いのか？
① 無料だから
現在有料の証明書をお使いでも、AWSのALBに設定する証明書はACMで無料で発行できます。コストがかかりません。
② 更新が全自動だから
既存サーバーから持ってきた証明書は、有効期限が来たら手動で更新し、再度AWSにインポートする必要があります。この作業を忘れると、ある日突然サイトが見れなくなります。
しかし、ACMで発行した証明書は、AWSが有効期限を自動で管理・更新してくれるため、更新忘れの心配がありません。
③ 手間がかからないから
既存サーバーから秘密鍵や証明書ファイルを安全にコピーしてくるのは、意外と手間がかかります。ACMで新規発行すれば、画面の指示に従ってドメインの所有確認（DNSのCNAMEレコード設定）をするだけで、そうした手間は一切かかりません。
ALBも利用するときの、推奨する流れ
- 【準備】 あなたのドメイン（例:
your-domain.com）を所有している状態にする。 - 【AWSでの作業】 所有しているドメイン名を使って、ACMで新しい無料のSSL証明書を発行する。
- 【AWSでの作業】 その発行した証明書をALBに設定する。
この流れで進めるのが、最もシンプルで、コストもかからず、将来の運用も楽になるベストな方法のようです。
ここで、ドメインとSSL証明書の更新について、自分のなかで混乱してしまったので、再整理しながら、疑問も一緒にまとめました。
証明書の更新とドメインの更新は別物？
SSL/TLS証明書の更新と、ドメインの更新は全くの別物です。混同しやすい部分ですが、以下のように役割と管理元が異なります。
| 項目 | ドメインの更新 | SSL/TLS証明書の更新 |
| 目的 | ドメイン名 (example.com) の所有権を維持するための手続き |
通信を暗号化する鍵の有効性を保ち、サイトの身元を証明するための手続き |
| 相手 | ドメインレジストラー（お名前.com, ムームードメイン, Route 53など） | 証明書発行機関（CA）（今回はAWS Certificate Manager） |
| 期間 | 通常1年〜10年単位 | 通常数ヶ月〜1年単位 |
| 作業 | 【手動】 ユーザー自身で更新手続きと支払いが必要 | 【全自動】 AWSが自動で行うため、ユーザーは何もしなくて良い |
そのため、ドメインの更新期限が来たら、手動で手続きをする必要がありますが、証明書についてはAWSで自動更新の設定をしていれば、気にする必要はありません。
ACMで、証明書の更新期間はどのくらいに設定すべき？
ACMの最大の利点こそがここで、ユーザー自身が更新期間を設定する必要は一切ないようです。AWSがすべて自動で行います。
ACMの自動更新の仕組み
- ACMが無料で発行する証明書の有効期間は13ヶ月（395日）です。
- AWSは、この有効期限が切れる60日前から、新しい証明書の検証と発行を自動的に開始します。
- 私たちが前回の手順で設定した「DNS検証」（CNAMEレコード）がDNSサーバーに存在する限り、AWSは「このドメインの所有者はまだあなたですね」と自動で確認できるため、ユーザーの操作なしで更新プロセスが完了します。
したがって、AWSの自動更新に完全に任せることで、手動での設定や管理から解放されるのが、ACMの大きな魅力です。
CloudFront利用時のSSL/TLS設定について
CloudFrontを利用する場合でも、ユーザーとの通信と、CloudFrontからALBへの通信、その両方をHTTPS化することが可能です。そして、それがセキュリティ上、強く推奨される構成です。
ただし、証明書を設定する場所が重要になります。この場合、通信経路は以下のようになり、2つの区間で暗号化が必要になります。
ユーザーブラウザ <--【区間①】--> CloudFront <--【区間②】--> ALB
これを実現するためには、証明書はALBだけに設定するのではなく、CloudFrontとALBの両方に設定します。
【区間①】 ユーザー ⇔ CloudFront 間の暗号化
-
- CloudFrontのディストリビューション設定に、ACMで発行したSSL/TLS証明書を設定します。
- これにより、ユーザーは
https://でサイトにアクセスできるようになります。 - 【最重要ポイント】 CloudFrontに設定する証明書は、必ずバージニア北部リージョン (us-east-1) で発行されたものである必要があります。東京リージョンで発行した証明書は使えないので注意。
【区間②】 CloudFront ⇔ ALB 間の暗号化
-
- こちらは、今まで通りALBのHTTPSリスナーに、ACMで発行した証明書（これは東京リージョンでOK）を設定します。
- そして、CloudFrontのオリジン設定で、ALBとの通信プロトコルを「HTTPS only」に指定します。
理想的な構成
結論として、CloudFrontを使う場合の理想的な構成は以下のようになります。
- バージニア北部リージョンで、
www.your-domain.com用の証明書をACMで発行する。 - 東京リージョンで、
www.your-domain.com用の証明書をACMで発行する（またはALB用の別名でも可）。 - CloudFrontに、バージニア北部で発行した証明書を設定する。
- ALBに、東京リージョンで発行した証明書を設定する。
この構成にすることで、エンドツーエンドでの暗号化通信が実現し、非常にセキュアなサイトを構築できます。
さらに質問形式で、理解を固めていきます。
1. ACM証明書の作成場所と更新について
この場合、ACMをバージニア北部と、東京リージョンの２ヶ所で使用し、それぞれにSSL証明書を作成して、全自動で更新してもらう、という理解であっていますか？
はい、その理解で正しいです。まさに、その通りに設定します。それぞれの役割をまとめると以下のようになります。
バージニア北部 (us-east-1) で発行する証明書
-
- 役割: CloudFront用。ユーザー（ブラウザ）とCloudFrontの間の通信を暗号化します。
- 理由: CloudFrontは世界中に拠点を持つグローバルなサービスであり、その仕様上、証明書はバージニア北部リージョンで管理されるためです。
東京 (ap-northeast-1) で発行する証明書
-
- 役割: ALB用。CloudFrontとALBの間の通信を暗号化します。
- 理由: ALBは東京リージョンで稼働しているリージョン内のサービスのため、同じリージョンの証明書を使います。
そして、最も重要な点として、この2つの証明書は、それぞれのリージョンで独立して、かつ全自動で更新されます。一度設定してしまえば、私たちはどちらの証明書の有効期限も気にする必要はなくなるようです。
2. 外部DNSサーバーのCNAMEレコード設定について
またこのとき、外部のDNSサーバのCNAMEレコードには、どこの何を具体的に設定していくことになるのでしょうか？
こちらも非常に良いご質問です。証明書を2つ作るため、DNS設定がどうなるのか混乱しやすいポイントですよね。
結論から言うと、DNSに設定するCNAMEレコードは1つだけです。そして、その設定先はCloudFrontになります。
なぜCloudFrontだけなのか？
ユーザーがウェブサイトにアクセスするときの通信の流れを追うと、理由がよくわかります。
- ユーザー: ブラウザで
https://www.your-domain.comを開きます。 - ブラウザ: DNSサーバーに「
www.your-domain.comはどこですか？」と問い合わせます。 - DNSサーバー: あなたが設定したCNAMEレコードをみて、「それは CloudFrontのドメイン (
d12345abcdef.cloudfront.net) ですよ」とブラウザに教えます。 - ブラウザ: 教えられたCloudFrontにアクセスします。（ここでバージニア北部の証明書が使われます）
- CloudFront: （キャッシュがない場合）オリジンとして設定されているALBにコンテンツを取りに行きます。（ここで東京の証明書が使われます）
このように、ユーザーからのアクセスはすべてCloudFrontが最初の窓口として受け止めます。ユーザー（ブラウザ）は、その後ろにあるALBの存在を直接知ることはありません。
そのため、私たちがDNSで「うちのサイトの窓口はここですよ」と案内する必要があるのは、CloudFrontの住所（ドメイン名）だけで良いのです。
具体的な設定値
- 設定する場所: お使いの外部DNSサービス（お名前.comなど）の管理画面
- レコードの種類:
CNAME - ホスト名（名前）:
www（www.your-domain.comの場合） - 値（ポイント先）: CloudFrontのディストリビューション作成後にAWSの画面に表示される「ディストリビューションドメイン名」
- （例:
d12345abcdef.cloudfront.net）
- （例:
この設定により、www.your-domain.com へのアクセスが、正しくCloudFrontに向けられるようになります。
