Amazon CloudFront の代替ドメイン名(CNAMEs)設定に SSL 証明書が必須になりました

はじめに

みなさん、CloudFront 使ってますか！（挨拶

今年 ('19) 4/8 付けのアナウンスになりますが、 CloudFront の代替ドメイン名（Alternate Domain Names, CNAMEs）を設定する際、該当する SSL/TLS 証明書の登録が必須になりました。

• Amazon CloudFront がディストリビューションに代替ドメイン名を追加する際のセキュリティを強化

ドキュメントも、英語版の方には記述が追加されています。

• Requirements for Using Alternate Domain Names - Using Custom URLs for Files by Adding Alternate Domain Names (CNAMEs) - Amazon CloudFront

To add an alternate domain name (CNAME) to use with a CloudFront distribution, you must attach to your distribution a trusted, valid SSL/TLS certificate that covers the alternate domain name. This ensures that only people with access to your domain's certificate can associate with CloudFront a CNAME related to your domain.

今後は、HTTPS は不要、HTTP のみで CloudFront を使いたいという場合（実際にそのような需要があるかどうかはわかりませんが）でも SSL 証明書が必要・・・ということになります。

試してみた

試しに SSL 証明書を選択せずに（Default CloudFront Certificate を選択したまま）代替ドメインを設定しようとしてみました。

com.amazonaws.services.cloudfront.model.InvalidViewerCertificateException: To add an alternate domain name (CNAME) to a CloudFront distribution, you must attach a trusted certificate that validates your authorization to use the domain name. For more details, see: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-requirements (Service: AmazonCloudFront; Status Code: 400; Error Code: InvalidViewerCertificate; Request ID: c334bd60-xxxx-xxxx-xxxx-7f3b5a403a9a)

上述の通りエラーとなり設定できません。「trusted な証明書を attach しろ」と言ってますね。

なぜこのような仕様変更が、という背景説明はあとにして、取りあえず対策をまとめてみます。

傾向と対策

とりあえずどうすればいい？

該当する証明書を適用しましょう。 ACM でも構いませんし、ワイルドカード証明書でも結構です。

CNAMEs に設定するドメイン	必要な証明書
example9.jp	example9.jp
www.example9.jp	www.example9.jp または *.example9.jp
www.sub.example9.jp	www.sub.example9.jp または *.sub.example9.jp

証明書は正規の、有効なものでなくてはなりません。

ワイルドカード証明書でも良い？

上述の通りです。大事なことですね。

証明書がないんだけど

残念です。

今回の仕様変更は「そのドメインを扱う権利があるか」どうかを「証明書を用意できるかどうか」で確認するためなのでご理解ください。

証明書はあるけど、別の AWS アカウント上の ACM にある

ACM で作成したパブリックな証明書は、他の AWS アカウントにエクスポート/インポートしたり、アカウント間認証させたりといったことが出来ません。

同じドメイン用に証明書は何枚も発行できるので、CloudFront を作成した AWS アカウントの ACM （バージニア北部リージョン）にてもう 1枚発行してください。その際には DNS 検証を選択して発行すると良いでしょう（検証のための DNS はどこにあっても構いません）。

ちなみにその証明書が他所で作成しインポートしたものなら、再びインポートすれば使えると思います。ただし、証明書の発行元によっては、規約上取り直しが必要な場合もありますのでご注意ください。

CNAMEs に www.example9.jp と www.sub.example9.jp を設定したい

ワイルドカード証明書は、サブドメインの階層が異なるとマッチしません。また、ひとつのディストリビューションに複数の証明書を設定することはできません。

両方の名前を含む証明書を 1枚にまとめて発行し使用してください。

ていうか、以前証明書を設定せずに作ったんだけど？

既にあるものはそのまま動く（「機能し続ける」）そうです。

ただし新しい代替ドメインを追加する際には当然チェックされますし、（もしかしたらそのために）設定変更などが出来なくなる可能性もあるので、早めに対応しておくことをお勧めします。

なにゆえこんなことを？

英語版のアナウンスの方に詳しい経緯が書かれています。

• Continually Enhancing Domain Security on Amazon CloudFront | Networking & Content Delivery

かいつまんで説明すると、昨年から続く「dangling DNS entry」によるセキュリティリスクへの対策の一環ということになります。

この dangling （宙ぶらりんの、宙に浮いた状態の） DNS entry というのは、既に存在しない・設定が削除された IP アドレスを指し示したままになっている DNS エントリのことです。これが放置されることで、第三者がフィッシングやハイジャックなどに利用するセキュリティリスクにつながります。

• 参考 : Dangling DNS Records are a Real Vulnerability – Nabeel Yoosuf – Medium

つまり、正しい権限を持たない誰かが勝手に代替ドメイン(CNAMEs)を設定したりできないようにしなければならないわけです。これとは別に、CloudFront は既存の代替ドメイン設定がディストリビューションから削除される際に、該当の DNS エントリがあるかないかをチェックするようになっています。

試しに DNS エントリを残したまま代替ドメインを削除するようにしてみたところ、下記のような警告が表示されました。

DNS レコードが残ったまま代替ドメイン(CNAME)を削除することは危険だ、DNS と代替ドメイン名の設定は整合性を維持せよ、と書いてありますね！

まとめ

CloudFront の代替ドメイン名の扱いがよりセキュアになった、というアップデートを紹介しました。ACM の証明書は DNS や Eメールで検証された結果発行されますから、このような設定の健全性を確保するためにも使えるわけですね。

使い勝手が悪くなるという印象もありますが、 HTTP のみで使いたいと思っている場合を除くとほぼ影響はないかと思います。一方で複数の AWS アカウントを複合的に活用していたり、ACM 以外の、例えば EV 証明書などを利用している場合は注意が必要かもしれません。ご利用の状況に合わせて検討してみてください。