CloudFrontからカスタムオリジンまでの通信をHTTPS化する方法を2パターン
西澤です。サーバ証明書を利用した試験もACMが利用できるようになってやりやすくなりましたね。今回は、CloudFrontからカスタムオリジン（今回はELBオリジンの想定です）までの通信をHTTPS化したいときの構成パターンについて整理します。
前提条件
CloudFrontからAWSの各VPC内に用意したAWSリソースまでの通信は、インターネットを経由することになります。VPCに入るまでの通信はHTTPSにしておきたいというのが今回やりたいことです。ここで、CloudFrontからカスタムオリジンまでの通信をHTTPSにしたい場合には、オリジン側で下記のいずれかの証明書を用意する必要があります。
証明書のドメイン名の 1 つは、次の値の 1 つまたは両方と一致する必要があります。
- ディストリビューションの該当するオリジンの [Origin Domain Name] に指定した値。
- Host ヘッダーがオリジンに転送されるように CloudFront を設定した場合は、Host ヘッダーの値。
CloudFront とカスタムオリジンとの間の通信に HTTPS を必須にする - Amazon CloudFront
その１：CloudFrontとオリジンで異なるCommonNameのサーバ証明書を用意する
一般的にはこのような構成を取るケースが多いと思います。ユーザに見えるサーバ証明書とは別に、www-origin等の別の名前でサーバ証明書を用意してオリジン側に設定する方法です。オリジンのURLとサーバ証明書のCommonNameが同じになる必要があります。
詳細な手順は下記記事が詳しいので、ぜひご覧ください。
ACMでサーバ証明書が無料で利用できるようになったので最近は困ることがほぼ無くなりましたが、購入する場合はワイルドカード証明書または複数の証明書を用意する必要があります。
その２：CloudFrontとオリジンで同じCommonNameのサーバ証明書を利用する
あえてこちらを推奨はしませんが、このような構成も取れるということでもう1パターンもご紹介します。Hostヘッダーを転送することで、CloudFrontと同じCommonNameのサーバ証明書をELBに設定することが可能です。
ここでは、Hostヘッダーのみ転送する設定としてみました。
オリジンのURLとサーバ証明書のCommonNameが同じである必要はなく、逆に転送されたHostヘッダーと同じCommonNameでサーバ証明書を設定してあれば問題なく動作します。
CloudFrontとオリジンで同じCommonNameを利用する場合の注意
この同じCommonNameを用いた構成の問題点としては、ざっと以下が挙げられると思います。
- ELBに対して直接HTTPSでの稼働確認ができなくなる為、問題発生時に切り分けが困難となる場合がある
- 構成が把握しにくくなる為、運用上の混乱が生じやすい
ただし、以下のような点ではこの構成が有用な場合も考えられると思います。
- 異なるサーバ証明書を用意する必要がないので、手間やコストを節約できる
- DNSの名前解決先をCloudFrontとオリジンとで変更することにより、CDNの付け外しを容易に行うことができる（特殊なBahavior設定がない場合のみ）
まとめ
仕様上どこまで可能なのかを確認した上で、検討した結果、結局別ドメイン、別証明書とすることにしました。システム構成を把握していない担当者が、Route 53、CloudFront、ELBのそれぞれの設定を確認し、アクセス経路を整理するのはただでさえ難しい作業なので、運用上混乱の起きやすい構成は避けるべきだろうという判断に至りました。ただ、調べるまでこのような構成が可能であることも把握していなかったので、きちんと調べて検証することが大切だなと改めて思ったのでした。
どこかの誰かのお役に立てば嬉しいです。
