Fastly CDN に Self-managed 証明書を適用しようとして悩んだ話

Fastly 上で取り扱う証明書

前回の『Fastly を導入したので振り返る』という記事で触れた通り、先日 Fastly を導入し現在も利用中です。Fastly では他のクラウドサービスでもよくあるように、Fastly が用意してくれている Managed 証明書と Self-managed 証明書の 2 種類の証明書を取り扱うことができます。

Managed 証明書については、認証局が「Certainly」という Fastly が設立したパブリック認証局 (CA) になっているそうで、証明書の有効期限は 30 日と短いため安全性も高く、有効期限の 10 日前に自動更新してくれるので管理がとても楽です。ただし無料なのは 5 つのドメインまでで、 6 つ目のドメインからは 20 USD / 月の費用が発生します 💸 (といっても、月末に 6 つ以上存在するかどうかで課金されるため、月末に消すという運用ができれば 6 つ目以降も無料です) もう一方の Self-managed 証明書は言わずもがな、他の認証局も選択できるものの自分で取得・更新しないといけないため、管理が面倒ですね。

マルチCDN で Fastly CDN を利用する

弊社での Fastly の利用用途の中に、マルチCDN の一端として利用しているものがあります。CDN を Fastly 以外にも用意し、下図のような構成で複数の CDN へのトラフィックを Azure の TrafficManager によって切り替えています。この設計をしている際に、どこにどの証明書を割り当てなければいけないかで悩みましたので、そのお話をしたいと思います。今回は Fastly 以外の CDN として CloudFront を利用した場合を例に挙げます。 jpg

まず、ユーザがアクセスする TrafficManager には CNAME レコードを追加して弊社で管理しているドメイン hogehoge.asaih.co.jp を割り当てたいです。

hogehoge.asahi.co.jp.	CNAME	hogehoge.trafficmanager.net.

各 CDN は CDN 構築と同時にドメインが付与されていますので、TrafficManager 配下に各 CDN を紐づけてあげることで、DNS ベースでトラフィックが分散されます。

上図の構成だと

hogehoge.trafficmanager.net. CNAME hogehoge.fastly.net.
hogehoge.trafficmanager.net. CNAME hogehoge.cloudfront.net.

のような CNAME レコードが追加されます。

証明書を割り当てる

ここから HTTPS で通信するために証明書を割り当てます。TrafficManager 自体は HTTPS 終端しませんので、各 CDN に証明書を割り当てなければいけません。つまり、Fastly の場合だと hogehoge.asaih.co.jp の証明書を hogehoge.fastly.net (実際には *.fastly.net は使えません⚠️ ) に割り当てることになります。この時、検証の過程で hogehoge.fastly.net にもアクセスすることがあるため、hogehoge.fastly.net には hogehoge.fastly.net 用の証明書を割り当てたいです。hogehoge.fastly.net は一般ユーザからアクセスされることはないので Fastly が提供してくれる Certainly の証明書をありがたく使用します。

ここで、「hogehoge.asaih.co.jp 用の証明書はどこに割り当てればいいのか？ 🤔 」という疑問が生じました。「そうか、SAN (Subject Alternative Name) に書いてあげればいいのか 🧐 」と hogehoge.fastly.net 用の証明書の SAN に hogehoge.asaih.co.jp と書いてあげることで、TrafficManager 経由で Fastly CDN とも TLS 通信ができるようになりました。しかしこれは間違いでした 🙅‍♂️

証明書の管理には SNI が利用されている

CDN を介した TLS 通信では一般的に SNI (Server Name Indication) が利用されています。最近のブラウザはほとんどが SNI をサポートしていますので、Fastly でもデフォルトで SNI を利用するようになっています。恥ずかしながらこの基本的な仕組みを理解していなかったために、上記のような間違いに繋がりました。ドメインの数だけエッジサーバが用意されているわけないですよね 😅

Fastly の場合ですと、SNI 利用のため Managed 証明書 / Self-managed 証明書に関わらず、デフォルトでは t.sni.global.fastly.net に証明書が Activate されます。つまり、今回の正解は「 t.sni.global.fastly.net に hogehoge.asaih.co.jp 用の証明書を割り当てる」です。 SAN に hogehoge.asaih.co.jp を書いてあげただけだと、hogehoge.fastly.net 用の証明書で TLS 通信することになってしまいます。

Fastly の実際の設定に当てはめると、

resource "fastly_tls_private_key" "tls_private_key" {
  key_pem = "秘密鍵ファイルの中身"
  name    = "hogehoge.asaih.co.jp"
}

resource "fastly_tls_certificate" "tls_certificate" {
  certificate_body = "証明書ファイルの中身"
  name             = "hogehoge.asaih.co.jp"
  depends_on       = [fastly_tls_private_key.tls_private_key]
}

resource "fastly_tls_activation" "tls_activation" {
  certificate_id = fastly_tls_certificate.tls_certificate.id
  domain         = "hogehoge.asaih.co.jp"
}

で OK です。

この操作の後に DNS を見てみると

hogehoge.asahi.co.jp.	CNAME	hogehoge.trafficmanager.net.
hogehoge.trafficmanager.net. CNAME hogehoge.fastly.net.
hogehoge.fastly.net. CNAME t.sni.global.fastly.net.

のようにt.sni.global.fastly.net に到達しているのが確認できます。

明示的に hogehoge.asaih.co.jp と hogehoge.fastly.net を結びつける操作がないため「これで正しいのか？」と少し不安になります。CloudFront でもおそらく仕組みは同じなんでしょうが、CloudFront の場合は設定時に Self-managed 証明書をアタッチする操作が発生するので意識していませんでした。

おわりに

普段クラウドを利用していると、裏側の仕組みがわかっていなくてもなんとなくシステム構築できてしまうことが多々ありますが、今回はまさにそこに引っかかってしまいました。

実は、Fastly で Self-managed 証明書を扱う際にもう一点悩んだ点があります。それは更新の手順です。前述のfastly_tls_certificate リソースのドキュメントに

When updating both the fastly_tls_private_key and fastly_tls_certificate resources, they should be done in multiple plan/apply steps to avoid potential downtime. The new certificate and associated private key must first be created so they exist alongside the currently active resources. Once the new resources have been created, then the fastly_tls_activation can be updated to point to the new certificate. Finally, the original key/certificate resources can be deleted.

と注記されているとおり、秘密鍵も更新する場合には Activate 中の証明書を更新できません。一度 Deactivate して更新するか新規作成して差し替える必要があるとのことです。Terraform で管理しているとこれはなかなか面倒ですね 😇