Category: cloud

https://docs.aws.amazon.com/ja_jp/lightsail/latest/userguide/amazon-lightsail-using-lets-encrypt-certificates-with-wordpress.html#request-a-lets-encrypt-certificate-wordpress こちらの手順に則ってサーバーのSSL証明書を取得したはいいが、肝心の証明書更新が90日に1回必要になるということだった。気づいた時にはすでに遅し、元のGCPサーバーも停止させたので今更戻れるかというところまで来てしまった・・・。 軽く調べた感じだと同様の課題を抱えてる人はいたが、公式の手順に則るとすると自動更新は難しいのではないか？とのこと。 https://community.letsencrypt.org/t/aws-lightsail-certbot-auto-renewal/188248 まぁそれはそれとして、それではそもそもこれまで別サーバーで行ってきたcertbotの自動更新とはなんだったのだろうか。それと今回のLightsailとの差異はどこにあったのかを整理していく。 これまでとの違い – HTTP/DNSチャレンジ まず証明書の取得に当たっては任意のドメインの所有者が誰であるかを検証するために「チャレンジ」というプロセスが組み込まれている。 https://letsencrypt.org/docs/challenge-types さらにそのチャレンジの中でもHTTP/DNS/TLSという3つの種類が存在している。今回Lightsailではワイルドカード証明書（あるドメインとその直下のすべてのサブドメインを一枚の証明書でまとめて保護できるやつ）の利用を前提とした手順が公式で提示されている。 それに対し、既存サーバーでのSSL証明書は単一のドメイン or サブドメインのみに対して発行されていたため簡易なHTTPチャレンジが使われていた、という整理ができる。 そしてDNSチャレンジではチャレンジに使われる任意の値をTXTレコードとしてDNSサーバーに追加する必要がある。その手順が入ることで、自動化のレベルが上がる（route53のAPIを使うなど）ため公式では自動更新の手順に関する言及がなく自動更新を実現できていない、という整理ができるのではなかろうか。 前提を疑う – ワイルドカード証明書の必要性 先ほどの調査からすると、ワイルドカード証明というのは自身が保有するドメインとそのサブドメイン全てに対して有効な証明書が発行されるというのが利点である。 しかしながら、今回の用途でそこまでが必要なのかを精査する必要がある。そもそも前例として、これまでの既存サーバーではワイルドカード証明を使っておらず、無意識にhttpチャレンジを使っていたのが事実である。その結果としてSSL証明書の自動更新という恩恵を預かっていた。 ということは、公式で述べられているワイルドカード証明書の取得手順を見直し、HTTPチャレンジを用いたSSL証明書の取得を手順に組み込むことができれば、もしかしてAmazon LightsailのWordpressサーバーでもSSL証明書の自動更新が実現できるのではないか？と思った次第でした。