ある日突然Cloudfrontが502エラーを返したら、ALB側のSSL証明書を疑うべし

私の失敗談なのですが。。。

ある日突然「サイトにアクセスできない」と問い合わせがあり、サイトにアクセスしてみると

“502 ERROR ERROR: The request could not be satisfied.”

が返ってきました。

サーバーが落ちているわけではないし、ALBに直接アクセスすると問題なくページが開きます。

CloudFrontの障害か!?と思ったのですが、調べてみるとALB側のSSL証明書が未更新のままで有効期限が切れていたことが原因でした。

SSL証明書の2重管理問題

CloudfrontとALB間をHTTPSで通信する場合には、双方にSSL証明書を設定する必要があります。

設定にはACM(Amazon Certificate Manager)を使用します。ACMにSSL証明書を登録(インポート)しておくことで、あとはCloudfrontやALBの設定画面から登録済みの証明書を選択するだけで設置が完了します。

ACMを使うと簡単にSSL証明書を設定できるのですが、1つ大きな問題があります。

  • CloudFrontではバージニアリージョンのACMに登録したSSL証明書しか使用できません
  • ALBではALBと同じリージョンのACMに登録したSSL証明書しか使用できません

例えばALBが東京リージョンにある場合には、バージニアリージョンと東京リージョンのACMにそれぞれSSL証明書を登録しておく必要があります。

つまり2重管理が発生するわけです。

ALB側の証明書の期限が切れると502エラーが発生する

502エラーが発生した理由は、CloudFront側のSSL証明書は更新されていたが、ALB側の証明書が更新されてなかったためです。

CloudFront側のSSL証明書だけを更新してブラウザにアクセスすると、正しくページが開き、証明書情報も更新されており一見問題がないように見えます。ALB側の証明書が古いままでも有効期限が切れていない限りCloudFrontとALBの間は正しく通信が行われるからです。

しかし、古いままとなったALB側のSSL証明書の有効期限が切れた途端、CloudFrontとALB間は正しく通信がされなくなります。

その結果、CloudFrontが502エラーを返すことになります。

Related Posts