ドメイン移行に伴う、ALBに複数のドメイン証明書を付与するやり方

概要

TechTrainのバックエンドのドメインを techtrain.dev に変更した際に、ALBに複数のドメイン証明書を入れる必要があったので、その対応について書きます。

↓自分が迷っていた際のXのPost。

https://x.com/suguru_ohki/status/1752358480076505315?s=20

なぜその対応をやったのか？

1. TechTrainは、以前 techbowl.co.jp という企業のドメイン配下でサービスを提供してた
2. 現在のドメインである techtrain.dev は後からフロントエンドの移行のみを先行して行った
3. Third Party Cookieの対応のため、APIについても移行が必要となる

Third Party Cookieの説明については他にもたくさんあるため、割愛しますが、First Party Cookieの取り扱いとするためにも、バックエンドのドメインをtechtrain.devとする必要がありました。

どうやって対応したのか？

ALBに複数のドメイン証明書を入れる必要があります。
Server Name Indication(SNI)という便利な機能がALBにはあるため、それを利用すると良いです。

AWSの画面における場所(2024.01現在)

1. EC2 > ロードバランサー > ALBをクリック
2. 「SNI のリスナー証明書」の証明書の追加

すでにACMにて発行している証明書なら上記から追加が可能です。

注意点1

ACMに限らずですが、証明書利用の際にワイルドカード証明書というものがあります。
サブドメイン許可を考慮して、発行の際に指定しておかないと利用できないものです。
例えばですが、techtrain.devだけではなく、*.techtrain.dev というドメインに対して有効な証明書です。
ただこのワイルドカードが結構厄介で、a.techtrain.dev というサブドメインに対して有効ですが、、a.b.techtrain.dev というサブドメインに対しては有効ではありません。
この点を勘違いしていると、サブドメインのきりかたをミスして、証明書が有効にならないということが起こります。

• api.techtrain.dev -> *.techtrain.dev というワイルドカード証明書があれば有効
• test.api.techtrain.dev -> *.*.techtrain.dev というワイルドカード証明書があれば有効

自分の場合は、後者の適用範囲が *.techtrain.dev で有効であるという勘違いをしていたため、時間がかかってしまいました。
もし後者の想定があるなら、証明書の範囲を後者にまで広げておくと良いかもしれません。（その分OKとなるドメインの範囲がかなり広がってしまうため、その点に関しては注意した方が良い）

注意点2

https://docs.aws.amazon.com/ja_jp/acm/latest/userguide/gs-acm-request-public.html

上記にも書いてあるのですが、ACMにおいては、 *.*.techtrain.dev といった2階層とも*を利用したワイルドカード証明書は発行できません。そのため、*.api.techtrain.dev といった1階層目のサブドメインを指定したワイルドカード証明書を発行する必要があります。