STEERSのSSL/TLS証明書をACMのDNS Validationで発行したものに差し替えました
こんにちは。アドレスバーが緑色になっていると嬉しいうなすけです。
Symantec発行の証明書がChrome 70以降で信頼されなくなる
Webサービス開発者の皆さんは、開発者ツールを使ってWebサービスの挙動を詳しく見ることは日常的に行なっていることと思います。僕もそうです。 ある日、開発者ツールのconsoleにこのような警告が出ていることに気づきました。
(記事公開時点で、TMIXではまだ同様の警告が確認できます)
リンク先を詳しく読むと、Symantecにより発行されたSSL/TLS証明書がChrome70以降では信頼されなくなるということになっているようです。
これを回避するためには、Symantecによって2017年12月1日以降に発行されたSSL/TLS証明書を新たに取得するか、もしくはDigiCertなどの別の業者の発行するSSL/TLS証明書を取得するしかありません。
今回、STEERSは証明書の更新のタイミングが迫っていることもあり、SSL/TLS証明書発行業者を変えることにしました。
候補としてはDigiCertやGlobalSignなどいくつかあったのですが、元々の証明書がDV証明書であったこと、STEERSをAWSで運用していることからACM発行のものに切り替えることにしました。
ACMのDNS Validation
さて、ACMでSSL/TLS証明書を発行する際に行なわなければいけないドメインの所有確認ですが、これまではそれっぽいメールアドレスに送信されるURLに訪問して所有確認をする方式しか存在しませんでした。しかしつい先日、DNSにあるレコードを追加する形で所有確認する方式が追加されたので、それを使ってACMによるSSL/TLS証明書発行を行ないました。1
AWS Certificate Manager: Easier Certificate Validation Using DNS
us-east-1とap-northeast-1で証明書を発行する
STEERSでは、静的ファイルの配信にCloudFrontを使用しています。CloudFrontでACMにより発行されたSSL/TLS証明書を使用するには、ACMのregionがus-east-1である必要があります。また、STEERSのELBはap-northeast-1に所属しているので、STEERS全体のHTTPS化のためにはus-east-1とap-northeast-1の2つのregionのACMでSSL/TLS証明書を発行しなければなりません。
なので、まずはus-east-1のACMで証明書のリクエストをします。するとCNAMEに登録するサブドメインが指定されるので、それをRoute53に追加します。弊社ではroadworkerを使っているので、以下のような行を追加してapplyすることで作業は完了します。
rrset "hogehogefugafuga_domainkey.steers.jp", "CNAME" do ttl 3600 resource_records "hogehogefugafuga.dkim.amazonses.com" end
さて、同様にap-northeast-1でもACMから証明書のリクエストを行なうと……なんと、指定されるCNAMEはus-east-1で指定されるものとまったく同じものでした。なので、regionごとにCNAME recordを追加する必要はなく、そのままシュッと証明書が発行されました。便利！
発行したSSL/TLS証明書を使用する
あとはaws management consoleでポチポチやっていけば、CloudFrontとELBでACM発行のSSL/TLS証明書を使用するようになり、警告の出ない状態にすることができます。
https://www.ssllabs.com/ssltest/analyze.html?d=steers.jp&latest
まとめ
今回はSTEERSのSSL/TLS証明書を差し替えましたが、TMIXのSSL/TLS証明書の期限も迫ってきているので、同様にTMIXもACMによるSSL/TLS証明書を使用するようにするつもりです。
皆さんも自分の使っているSSL/TLS証明書が大丈夫なものか確認してみてはいかがでしょうか。
追記
17:04:25 誤字修正しました
