目的

ALBのSNIサポートによって複数の証明書を選択した際に、クライアントからのHTTPSリクエストが失敗する問題が発生しました。そのためALBのSNIに関する注意点を備忘録としてまとめます。

ALBのSNIサポートについて

ALBで複数のドメインを捌きたい際に、これまでは複数のALBを用意する必要がありました。しかしアップデートにより、同一のロードバランサで複数の証明書を使えるようになりました。
Application Load BalancerがSNIを利用した複数のTLS証明書のスマートセレクションをサポートしました

HTTPSリクエスト失敗に至った経緯

エラー発生に陥ったイベントを時系列にまとめます。
(1) これまでサードパーティからACMへImportしたEVSSL(prod.exaple.com)が近日中に失効する。
(2) 応急処置として、ACM側で発行した証明書(*.exaple.com)をALBに追加。この時は2つのSSL証明書がアタッチされている。
(4) (1)でImportした証明書の期限が切れた後、クライアントからのHTTPSリクエストが失敗していることが発覚。

原因

ALBが選択する証明書の優先順位ロジックによるもの。

この問題が引き起こされるまでは複数の証明書がALBにアタッチされていたとしても、有効な証明書が自動で選択されると思っていましたが、ちょっと違いました。

↓↓↓↓↓以下公式Docより↓↓↓↓↓↓↓↓↓↓↓
ALBは以下の優先順位によって、複数存在する証明書から最適な証明書を動的に判断。

ロードバランサーは、SNIをサポートするスマート証明書の選択アルゴリズムを使用します。クライアントから提供されたホスト名が証明書リスト内の単一の証明書と一致する場合、ロードバランサーはこの証明書を選択します。

Application Load Balancer 用の HTTPS リスナーを作成する

つまり、今回の場合はサードパーティからImportしたEVSSL(prod.exaple.com)が、ACM側で発行した証明書(*.exaple.com)よりも優先順位が高く判断されたため、有効期限を迎えたEVSSLが引き続き使用されたことでHTTPS通信が失敗する問題が発生しました。

一応、ALBの証明書の選択アルゴリズムは下記の優先順位で判定されます。
・パブリックキーアルゴリズム (ECDSA よりも RSA を優先）
・ハッシュアルゴリズム (SHA よりも MD5 を優先）
・キーの長さ (最大が優先)
・有効期間

今回の場合はこのアルゴリズムの前にクライアントからのホスト名が、EVSSL(prod.exaple.com)に一致すると判断されて、有効期限を迎えても引き続き使われていました。（ALBログから確認）

まとめ

今回はALBのSNIサポートによって複数の証明書を選択する機能でハマったところを共有しました。
有効期限を迎えた証明書は不必要にALBに残さないようにします。