ちょっと話題の記事

AWS ALB(新しいELB)のホストベースルーティングとSSL/TLS証明書の関係を理解する

2017.04.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。
本日、AWSの新しいロードバランサALB(Application Load Balancer)でホストベースルーティングがサポートされました。早速以下の記事で検証しています。

今回の機能追加によって、ロードバランサ自身にホストベースのバーチャルホスト機能が追加されたわけですね。使い勝手大幅アップ!という感じなのですが、ホストベースバーチャルホストとHTTPSを提供するためのSSL/TLS証明書は切っても切れない重要な関係かなと思い、その組み合わせについて調べてみました。

結論から言うと、現時点でALBの同一のポートでホスト名ごとに証明書を分けることはできません。ワイルドカードやマルチドメインなど複数のホスト名を1つの証明書で扱う対応を検討しましょう。

2017年10月にALBが複数証明書に対応したため、現在は証明書の使い分けが可能です。
ALBで複数のSSL/TLS証明書を設定できるSNIに対応しました | Developers.IO

ALBの構成要素と紐付け

まずは、ルーティングと証明書がロードバランサとどう紐付けられるのか、ALBの設定から構成要素とその紐付けを整理します。

ALBの構成要素

ざっと挙げると以下になります。

  • ロードバランサ(Load Balancer) : ALB本体。
  • リスナ(Listener) : ALBで待ち受け(Listen)るポート。
  • 証明書(Certificate) : HTTPSをListenするためのSSL/TLS証明書。ACMとIAMに対応。
  • ルール(Rule) : 転送先のターゲットグループを決定するための条件。現在はHostヘッダとリクエストパス(あるいは両方)を設定。
  • ターゲットグループ(Target Group) : トラフィックを転送するEC2を指定するグループ。

他にも、ターゲットに紐付くヘルスチェックやEC2インスタンス/AutoScalingグループもありますが、今回は省略します。で、紐付けを図にすると以下になります。

Load_Balancer
├── Listener_1
│   ├── Certificate_1
│   ├── Rule_1
│   │   └── Target_Group_1
│   └── Rule_2
│       └── Target_Group_2
└── Listener_2
    ├── Certificate_2
    ├── Rule_3
    │   └── Target_Group_3
    └── Rule_4
        └── Target_Group_4

ポイントは証明書とルールが同じ階層にあるところで、複数のホストベースのルールとそれに対応する証明書を紐付けるのは、仕組み上できないことがわかるでしょう *1

リスナと証明書の関係

また、リスナに設定する証明書は、リスナを作成するCreateListener APIなどを一見するとArray(配列)なので複数設定できるように見受けられます。

  • CreateListener - Elastic Load Balancing
  • Certificates.member.N
    • The SSL server certificate. You must provide exactly one certificate if the protocol is HTTPS.
    • Type: array of Certificate objects
    • Required: No

しかし、Descriptionをよく見ると、「You must provide exactly one certificate if the protocol is HTTPS.」とあるので、リスナ(≒ポート)につき証明書は1つしか設定できないことがわかります。

実際にAWS CLIなどで複数の証明書をリスナに設定すると、リストに指定した最後の証明書のみが有効になることを確認しました。

おまけ: SNIサポートは不要

HTTPSで複数の証明書を扱うと言うとSNIのサポート有無が気になるところですが、リスナにひもづく証明書は1つなので、SNIサポートは現時点で不要です。1つのリスナで証明書を複数ハンドリングできるようになるタイミングで必要になるかも、と想像します。

まとめ

ALBのホストベースルーティングとSSL/TLS証明書の関係を解説してみました。ポート(リスナ)を分けない限りは、複数のHostルールを設定したとしてもそれをHTTPSで通信するためには共通の証明書が必要になります。ワイルドカードやマルチドメインの証明書であれば対応できそうですね。

443ポート以外が利用できるのであれば、リスナを追加して、そちらで異なる証明書および異なるルールで対応することもできます。また、サブドメインなどに分けることが許容されるのであればALB自体を複数作成して同じEC2インスタンスをターゲットに登録するのも、もちろんアリです。

ALBを利用したHTTPSコンテンツ配信の設計に役立てば幸いです。

参考URL

脚注

  1. 今後の機能拡張で、ルールと証明書を対応付ける新たな仕組みが提供される可能性はもちろんあります。