in GCP, Server, SRE

SendgridのトラッキングURLを独自ドメインでかつhttpsで使う


タイトルのままです。使いたかったんです。

結論からいうと、使えない。でもひねって頑張ったら、使える。

使えない理由はトラッキングURLはあくまで自分のドメインのCNAMEであり、その向き先はsendgrid.netだからだ。sendgrid.netは自分のドメインの証明書なんてもってないので、http通信になる。

ところが最近のブラウザはhttpをhttpsにする挙動をするときとしない時がある。するとどうなるかというと同じブラウザでも環境によっては「http://トラッキングURL」をsendgrid.netに転送せずその場で強制的にhttpsにしてからsendgridにあててるサブドメインにアクセスするみたいな挙動をする。つまりsendgridにつけているURLはhttpsじゃないのに「https://トラッキングURL」にアクセスしてしまい、ブラウザがとまるということが起こるときがあるらしい。(手元で再現はしなかった)

手元で再現しなくても、「再現する人が存在する」という事実がある。

これはまずい。

やったこと

答えとしてはCDNを挟めばいける。ただ証明書をつくらないと当然「無効な証明書」とか言われてブラウザで怒られるので、AWSやGCPの証明を作ってくれる何かを使う必要がある。

(文字が赤くなってるのは気にすんな)

ここ一年GCPしか触ってない系SREなのでGCPで書いたけど、これAWSでも似たようなことできるはず。CloudFrontでhttpsとか独自ドメインとかできた。

CloudLoadBalancerは外部のサーバをエンドポイントにできる。極端な例でいうと、リクエストはGCPでうけるけど、プロキシ先はAWSのEC2やさくらのVPSとかできるわけ。そこでsendgrid.netを指定する。CDNオプションってのがロードバランサーを作成するステップのなかにあるので有効にする。するとロードバランサーが作成されるとCDNが有効になっている。

ただこれだとアクセスはこない。ただsendgrid.netにプロキシしてくれるだけの構成だ。

sendgrid.netは実はnginxがフロントにいる。しかるべきパラメータを与えてアクセスしないとnginxの404ページが表示される。

(自分でつくっててこれでると残念な気持ちになるやつ)

sendgridって最初やる作業として「使いたいドメインがCNAMEがsengrid.netに向いているか」を確認する必要がある。トラッキングURLを設定するときにやる。そしてこの作業は必須である。

ただこのままだと↑の「mail.srockstyle.com」はCloudLoadBalancerのIPアドレスに飛んで欲しいのに、sendgrid.netに直接飛んだ状態になってしまう。それではhttpsにならない。

なのでやることは以下だ。

  1. mail.srockstyle.comをsendgrid.netにCNAMEで登録 -> Sendgrid側の認証を通す
  2. 上で登録したmail.srockstyle.comをsendgrid.netへのCNAMEを削除
  3. mail.srockstyle.comを設定したロードバランサーのAレコードで登録
  4. ロードバランサーがmail.srockstyle.comを認知してくれたら証明書を作成してもらう

GCPはその場で作ってくれるし、AWSでも同様のことができるはずだ。

これでトラッキングURLをhttps://mail.srockstyle.com/nantarakantaraみたいなのになったとしても通常通りの動きをしてくれる。

これはSendgridのドキュメントにしれっと書いてあって、正直初見殺しといっていいやつ。

ここまで頑張ったはいいけど、独自ドメインのトラッキングURLはhttpで送られてくる。当然上でやった人たちには今度はGCPなりAWSなりの404 not foundが返るようになる。意味ないな。

あとはSendgrid社もしくはその間にいる仲介業者にメールで依頼して「トラッキングURL、httpsにしてくれんかのう」というお伺いを立てることになる。

まとめ

ブラウザ環境によって再現しない問題は滅んで欲しい。