メール検証ACM→DNS検証ACMへの移行のススメ
まだメール検証ACMで消耗しているの？
私はもう暫くは東京で消耗したいです。トーキョー、スゴク楽シイ、ベンリ。 後、地元と違って村八分文化も無い程度には東京砂漠で有り難い。
▲うっそやろ「村八分」もあるのか。でもこのイラストだと、四捨五入した時村九分になってしまう……
こんにちは。AWS事業本部のしろたです。 クラスメソッドでは基本、入社して三ヶ月間程度は出社する(環境・業務に慣れる為)事になっておりますが、本日は台風に依り自宅勤務と相成っております。初めてのフルリモート勤務です。 通勤時間レスなのは大変嬉しい限りなのですが、今後のリモート生活を鑑みると良い椅子が欲しくなってしまいます。結構切実。 さて、雨ニモ風ニモ腰ニモマケズ。今日も参りましょう。
まだメール検証ACMで消耗しているの？
今回の本題なので、大事な事と判断して二度記述させて頂きました。 そもそも、ACM(AWS Certificate Manager)って凄く便利ですよね。 ELBとの紐付けも簡単だし、AWS上の環境における証明書の管理においては使うべきサービスであると感じております。 無料でSSL/TLS証明書が発行できるというのも強い。そんなACMについての記事まとめは以下からどうぞ。
「証明書の管理」につきものなのは、「証明書の更新」。 信頼されたWebページを提供し続ける為には、信頼されている証明書を使い続ける必要性があります。 ACMで発行したSSL/TLS証明書は、13ヶ月の有効期限が存在しています。約1年毎には証明書を更新し続けなければなりません。 勿論、AWSは証明書の期限が切れる前に通知を送ってくれます。ただ、メールやAWS Personal Health Dashboard等での通知があっても更新を忘れてしまう可能性はゼロではありません。
そこで、今回の提案です。
「今使用している、メール検証ACMをDNS検証ACMに移行しませんか？」
メール検証ACMをDNS検証ACMに移行してみた際の話をしていきたいと思います。
早速やってみた
まずは、検証用にメール検証ACMを作ってみました。 以下の記事を参考に、AWSのサービス内で全て完結させる検証環境を構築してみました。
[ACM] SSL証明書発行時のドメイン認証メールをSESで受け取ってみた
サブドメインの権限しか持ってなくても何とかなる。AWSのサービスのカバー範囲凄く強い。 では、早速ACMの検証をメールからDNSに切り替えていきましょう。 メール検証のACMを選択して、[Actions]を選択して、
無い。
私の勝手な想像だと[Change configuration type]とか出てくるイメージだったんだけど、無い。 これで分かった事は、メール検証のACMからDNS検証のACMに切り替える際には、 DNS検証のACMを新規作成する必要があるという事でした。
DNS検証のACM作成の大まかな流れと注意事項
つまり、メール検証のACMを使用している環境で、DNS検証のACMに移行する際には以下の流れで動く事になります。
- DNS検証のACMを新規作成
- DNS検証に用いる、CNAMEレコードが発行される
- CNAMEレコードを(AWSでDNS検証を行うのなら)Route53に登録する
こちら補足しますと、既に今回使用したドメイン名がRoute53に登録してある場合は以下のようなボタンが表示されて、これをクリックするとRoute53にCNAMEレコードが登録出来るようになってます。AWSでサービスを完結させようとすると凄く便利なのがここからも分かります。
そして、DNS検証のステータスが[Issued]になったら、早速運用していきましょう。
基本的に、DNS検証のステータスが確認されるまでには
- CNAMEレコードが反映される
- 反映されたCNAMEレコードをAmazonが検証し、OKなら証明書を発行する
上記の過程を経るため、数時間の検証時間が必要となります。(最長でも72時間/72時間経つと 検証はタイムアウトします )
この段階では、作成したてのACMの[In Use?]が[No]となっている筈です。
- ACMを使用しているELBでACMの付け替えを行う
今回のようなパターンだと、ドメイン名が全く同じで見分けがつかなくなりやすいので識別子(Identifier)を事前に確認してから、[Lisner]タブ内からACMを付け替えましょう。
付け替え後、前述したACMの[In Use?]のYes/Noが切り替わっていればACMの付け替えは成功です。
以降、切り戻しなどで前ACMが必要になる事が無さそうなら、削除してしまいましょう。
気を付ける事
作業自体は特記する事は無いように感じました。どちらかというと、作業完了後(DNS検証に用いたCNAMEの管理)や作業実施前(DNS検証ACMを導入して、きちんとDNS検証が機能する環境か)に気をつけた方が良いな、と。 作業実施後に「あれ、もしかして自動更新されないかも？」と気付いた場合は、以下の記事を読む事をオススメします。
ACMで管理されているSSL/TLS証明書の自動更新失敗について
実際にDNS検証へ切り替えて使用してみて
今回、DNS検証を試してみたのですが、実際の更新に関してはまだ経験していないのでその辺りに関しては特に何も言えません。流石に更新時期までタイムリープするのは難しいです。
ただ、初期導入に関してだけで言っても、 DNS検証の方が楽です 。
今までのメール検証だと、「検証のメールが来たと思うので確認して下さい」と連絡する手間や、実際にメール検証のメールが迷惑メールに入ってしまっていて気付くのに遅れたりなど、有効化する為のメールでロスタイムが発生してしまうリスクが少なからずあります。
また、どうしても検証の確認に人間が入って来る以上、物理的に離れた時差のあるところにいる人とのやり取りが発生したりする事もあるかと思います。外的環境を考慮する必要がDNS検証より大きいと考えられます。
今回はメール検証からDNS検証への切り替えという事で手順が若干複雑に感じられますが、初期からDNS検証を使う、という選択肢を取ればとてもシンプルな手順で作業自体を完了させる事ができるのではないでしょうか。
そして何より、一度DNS検証が上手くいけば次の更新時には自動でACMの証明書は更新されます。
つまり、今回の作業以外には 何もやる必要はありません 。やっぱり便利ですよね。
長期的な視野で見ると、導入自体はオススメしたい
若干の注意事項や、移行の際にACMの新規作成をしなければならない事などは存在しますが、それでもやっぱりDNS検証で毎年自動で証明書の更新がされるというのは魅力的なサービスだと思います。 工数は確実に減らせます。 事前の確認をしっかりして、導入出来そうだなと感じたらメール検証ACMからDNS検証ACMの移行を 是非実践してみて下さい。
