<経過観察中>RapidSSLで認証したSSLサーバ証明書を使っているサーバにChromeでアクセスすると警告がでる件

f:id:boost-up:20171211234910j:plain

既に数か月前から騒がれている話ですが、GoogleがSymantec系のサーバ証明書に対する信頼を落としており、Thawte、VeriSign、Equifax、GeoTrust、RapidSSLといったSymantec系のサーバ証明書を使っているサーバは証明書の再発行、再署名といった対応が求められる可能性が高い状況です。 forest.watch.impress.co.jp

SCDB JAPANはRapidSSLを使っており、今日現在ChromeでアクセスするとConsoleに以下のような警告が表示される状況です。 (この情報は、モダンブラウザを数クリックすれば誰でも確認できるので隠す程のことではありません。)

f:id:boost-up:20171211230802p:plain

RapidSSLのWebサイトの情報

www.rapid-ssl.jp

RapidSSLのサイトによるとサーバ証明書の「発行日」と「有効期限」の組み合わせによって、必要な対応が変わってくるそうです。

対象・対応と日程:

1.2016年6月1日より前に発行された証明書(Google Chrome66よりSSLサーバ証明書が無効化されます)
① 有効期限が2018年3月14日以前:対応不要
② 有効期限が2018年3月15日以降:2018年1月~3月までに再発行

2.2016年6月1日より後且つ2017年12月より前に発行された証明書(Google Chrome70よりSSLサーバ証明書が無効化されます)
① 有効期限が2018年9月12日以前:対応不要
② 有効期限が2018年9月13日以降:2018年1月~9月までに再発行

scdb.jpのサーバ証明書は次の通り、発行日が2017/2/25、有効期限が2020/2/26ですので、上記の2-②のパターンに該当します。

f:id:boost-up:20171211232305p:plain

来年まで悠長なことを言わずに今すぐ再発行できないのかと考え、契約したRapidSSLの販売代理店に問い合わせたところ「来年2月頃に再発行をご案内します」との回答。

仕方がないのでとりあえず忘れないようにここに備忘を残し、時が来るのを待つことにしたいと思います。

余談

SSL化の目的は主に、通信経路を暗号化することと、運営者に対する第三者証明の2つがあります(それ以外にも、SEOの観点でも加点要素と言われています)。 後者については、ドメイン認証、企業認証、EV認証という三段階の認証基準があり、どれを採用するかでコストも認証の難易度もかなり変わってくるのですが、実は暗号化レベルは基本的に一緒です。

私は今のところはドメイン認証ができれば十分なので、コスト的に最もお手軽なRapidSSLを使っているのですが、それでもこれまでは少なからず対価を支払う必要がありました。

ところが最近は、3ヵ月毎の更新が必要ではあるものの、Let's Encryptという無料サービスが普及してきています。 私が管理する別のサーバでも使っていますが、インターネット側のサーバもイントラネット内のサーバも問題もなく動作しています。

通信経路の暗号化を目的にドメイン認証が出来れば良いというのであれば、Let's Encryptでも十分なのかも知れません。