こんにちは、技術1課の多田です。
日本全国が梅雨入りしていますが、皆さんいかがお過ごしでしょうか?
梅雨の時期は洗濯物を干すタイミングが命な感じがしていますが、どうしても雨が続くとどうやって洗濯物を干すかを迷いますよね?
AWSを使っていてもシステムの条件上、こんな場合どうしよう?ということがあります。今回は、そんな記事です。
CS課の坂本が書いている【そんなときどうする?】シリーズで、私も書いてみたいネタが出てきたので投稿します。
ちなみに、本シリーズでは、「そんなときどうする?」となった時に、様々ある解決方法の中の1つをご紹介します。
過去の投稿記事は、以下の通りです。
- 【そんなときどうする?】CloudWatchのデータを2週間以上残したい!
- 【そんなときどうする?】CloudWatchのデータを2週間以上残したい! Lambda編
- 【そんなときどうする?】別のアカウントにセキュアにアクセスしたい! いまさらきけないSTSとは?
- 【そんなときどうする?】DynamoDBのデータを可視化したい! LambdaのBlueprintを使って、Elasticsearch Serviceと簡単連携
- 【そんなときどうする?】Lambdaでの開発を楽にしたい! 「Serverless Framework」で楽々開発
今回の記事について
今回は、ACMを使う際、証明書の認証にドメイン認証を使用します。
ドメイン認証の際、確認メールが送信されます。具体的には、下記のユーザー宛でメールが送信されます。
- administrator@ドメイン名
- postmaster@ドメイン名
- admin@ドメイン名
- hostmaster@ドメイン名
- webmaster@ドメイン名
そのメールを受信するメールサーバーがない場合(ドメインは取得したけど、そのドメインで作ったメールサーバーがない等)、どうやって対処するかをまとめています。
ACMについてより詳しくは、同じ課の高橋の記事をご覧ください!
AWS Certificate ManagerでSSLをお手軽に!
尚、記載内容は、ブログ投稿日時点のサポート情報になります。
対処法は?
SESのメール受信機能を使います。
SESは、メールを送信することだけでなく、メールを受信することができるようになりました。
【AWS発表】Amazon SESがメール受信、そしてその処理に対応しました
それでは、実際に、SESの受信機能を使ったACMのドメイン認証を行う手順を確認してきましょう。
事前準備
今回の前提となるのは、Route53を権威DNSで利用されていることが条件となります。
SESを利用して、メールを受信する場合、Route53を使ってドメインのMXレコードをSESのエンドポイントを指定する必要があります。
エンドポイントは、リージョンによって異なりますので、こちらをご確認ください。
今回は、日本から近いオレゴンリージョンのSESを使用します。
SESで使用したいドメインを作成します。
DNSにはRoute53を使うので、「Use Route53」を選択します。
Route53に登録するレコード一覧が表示されます。
この時に、「Email Receiving Record」のチェック項目にチェックを入れて「Create Record Sets」を選択します。
Route53側でもTXTレコードとMXレコードが登録されているかを確認します。
ちゃんとTXTレコードとMXレコードが登録されています。
SESのダッシュボードに戻り、ドメインのステータスが「verified」になっているかを確認します。
これで事前準備が完了です。
メール受信のセットアップ
次に、SESの受信ルールを作ります。
SESによるメール受信処理制御は、2つの方法があります。
1つは受信者に基づいて実行するアクションを指定する方法、もう1つは発信元IPアドレスに基づいて制御する方法です。
今回は、受信者に基づいて実行するアクションを指定する方法を利用します。
左メニューより「Email Receiving -> Rule Sets -> View Active Rule Set -> Create Rule」の順番で選択します。
まずは、Eメールを受信するドメイン名を記載して、「Add Recipient」をクリックします。
その後、「Verification status」が「Verified」になっていることを確認して、「Next Step」をクリックします。
次は、実際にEメール受信後のアクションを設定します。
SESで設定できるアクションは次の通りです。
- S3アクション:メールをバケットに保存します。
- SNSアクション:メールをSNSで通知します。
- Lambdaアクション:Lambda関数でメールを処理します。
- バウンスアクション:送信元にバウンス応答を返すことによってメールを拒否します。
- ヘッダー追加アクション:受信メールにヘッダーを追加します。
- WorkMailアクション:メールをWorkMailで処理します。
- 停止アクション:設定された受信ルールの評価を終了します。
今回は、ACMのメールを受信するだけの用途なので、S3に保存する方法を取ることにします。
S3を使う場合、バケットの作成とSESのメールを受信できるバケットポリシーを設定する必要があります。
以下のように定義しました。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowSESPuts-1466315224036", "Effect": "Allow", "Principal": { "Service": "ses.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::S3バケット名/*", "Condition": { "StringEquals": { "aws:Referer": "ハイフンなしのAWSアカウントID" } } } ] }
上記の設定が完了後、メールを受信するバケットを指定して、「Stop Rule Set」を選択した上で、「Next Step」をクリックします。
受信ルールの詳細設定ページです。
今回は、受信ルール名のみ設定します。
「Rule name」に任意のルール名を設定し、「Next Step」をクリックします。
確認画面に移るので、問題なければ「Create Rule」をクリックします。
有効な受信ルールのページに遷移されて、「Status」が「 Enabled」になっていることが確認できれば、SESの受信の準備はできました。
ACMのセットアップ
いよいよ、ACMのセットアップを行います。
今回は、東京リージョンにてセットアップを実施します。
使いたいドメインは、zone apexのドメインとその他のサブドメインのため、zone apexとワイルドカードをつけて「確認とリクエスト」を選択します。
S3にバケットに行ってみます。
おぉ、たくさんオブジェクトがありますね。5人のユーザー×2つのドメイン認証要求のため10通メールがあります。
手動でダウンロードするのは時間を要するので、AWS CLIでまとめてダウンロードしました。
$ aws s3 cp s3://s3バケット名/ . --recursive
まとめてダウンロードしたファイルから、「https://」から始まるURLを抽出します。
方法は、様々あると思いますが、私は以下の方法で抽出しました。
$ cat * | grep "^https" | sort -u https://certificates.amazon.com/approvals?code=xxxx&context=xxxx https://certificates.amazon.com/approvals?code=xxxx&context=xxxx
認証のメール2通分のURL先で「I Approve」を選択します。
ACMのダッシュボードに戻り、状況が「発行済み」になっていることを確認します。
以上でACMのドメインに認証が完了しました。
まとめ
今回は、ACMのドメイン認証を受信するメールサーバーが無い場合の対処法を紹介しました。
このためだけにSESとS3を利用する場合は、作業が完了したら使用したリソースの削除をオススメします。
全てAWSのサービスのみで完結する作業となりますし、SESで実現している方法なのでメールサーバーの運用も不要です。
ぜひ、メールサーバーが無い場合ご活用ください。
最後に、ACMはCloudFrontとELBのHTTPS通信をサポートしているのですが、それぞれのリージョン毎のサポート状況をまとめます。
ACMで証明書が使えるようになっても必要なサービスで使えないと残念な結果になってしまうので。
サービス名 | 対応リージョン |
CloudFront | バージニア |
ELB | バージニア、オレゴン、カリフォルニア、アイルランド、 フランクフルト、東京、ソウル、シンガポール、シドニー、サンパウロ ムンバイ |
CloudFrontのみバージニアでしか証明書を取得できないため、注意が必要です。
私も東京リージョンで証明書を取得したのに、CloudFrontで使えないということがありました。。