Harada's Diary

このブログのサーバ証明書をECDSA証明書にした

タイトルの通り、このブログのサーバ証明書をRSA証明書からECDSA証明書に置換しました。
今更...って感じですが、意外と対応状況は半々って感じでした。

なんで更新した?

基本は以下記事を読了してもらえたらと思います。100%思いつきです。
ぶっちゃけ零細個人ブログなんて対応してなくて全然いいですが、まぁ面白そうなので試してみました

更新方法について

このブログはCloudfrontでデプロイしており、証明書の管理はACMを利用しています。
ACMで発行できるキーアルゴリズムは以下の3つですが、Cloudfront側で対応しているのはAmazon ECDSA 256 M3Amazon ECDSA 256 M3のみです。
※最初何も考えずAmazon ECDSA 256 M3で発行したら使えなく詰みました

Amazon ECDSA 256 M3

Amazon CloudFront

↓ACMのリクエストでは、必ずAmazon ECDSA 256 M3を選択します

正常に発行できました

あとはCloudfrontのディストリビューションからSSLの証明書を差し替えてデプロイするだけです

更新前後の変化を確認しよう

一般名(CN)がAmazon ECDSA 256 M3からAmazon ECDSA 256 M3に変わってますね
※詳細タブからキーアルゴリズム見たほうが確実だったけどキャプチャとり忘れた

  • 更新前
  • 更新後

古いブラウザとかの互換性とか大丈夫なん?

最初に貼った参考記事の中で

RSAからECDSAに変更するとブラウザの互換性が懸念されますが、これは気にしなくてもよいでしょう。というのも、高セキュリティ型はTLS1.3を、推奨セキュリティ型はTLS1.2を必須としています。ECDSAはTLS1.2よりも実は歴史が長く、TLS1.2を要件としている以上それより歴史が長いECDSAに未対応のクライアントも想定しづらいです。
WikipediaやGlobalSignのサポートページに対応状況が記載されていますが、TLS1.2対応かつECDSA未対応のブラウザはNitendo 3DSやWindowsXP上のChrome48以下など古いものだけなので、ほとんどのケースにおいて問題にはならないでしょう。TLS1.3ならなおさらです。

ですって。
ELBとかnginxだと複数の証明書当てられるけど、Cloudfrontは残念ながら1つの証明書しか当てられないので、もしどうしても古いブラウザ・OSにも対応させたい場合は利用難しいですね、、

おまけ

メジャーなサイトの証明書のアルゴリズム何使ってるのか気になったので調べてみました(2025/05/01 原田しらべ)

Sites

certificate algorithm

yahoo.co.jp

PKCS #1 SHA-256 with RSA 暗号化

amazon.co.jp

PKCS #1 SHA-256 with RSA 暗号化

instagram.com

PKCS #1 SHA-256 with RSA 暗号化

google.com

X9.62 ECDSA 署名(SHA-256)

netflix.com

X9.62 ECDSA 署名(SHA-256)

x.com

X9.62 ECDSA 署名(SHA-256)

意外と対応状況的には半々?ってところですかね?
ECサイトとかCustomer向けのサービスはRSA多め?そんなことないか、謎基準やね