ChromeおよびブラウザコミュニティによるSymantecの証明書の順次警告、無効化問題だそうで、該当する証明書(うちで該当するのはもちろん格安なDV RapidSSL)持ってるからさっさと更新せい、というメールが証明書屋さんから何度も来ました。TLSAの更新が必要なのでそれなりにめんどかったですが、本サイトも含めて2サイトの証明書を更新いたしました。皆さんどうしているのか見ようとしたところ…
いきなり見つかった記事 デジタル証明書ニュース:ChromeがSymantec発行証明書についての行動計画を発表 によれば
Chrome70では、現在のシマンテックのインフラストラクチャから発行されたTLS証明書を信頼しません。
Chrome70は、2018年9月13日にベータ版、2018年10月23日に安定版を予定しています。
となっており、あんぐりとなってしまいました。原文を当たると確かに「Symantecは2017年12月1日にnew Managed Partner Infrastructureを稼動させると言ってるんで、old Symantec-rooted Infrastructureの信頼はChrome 70で取っ払ってしまおう」という提案になっています。
2018年06月14日現在、旧Symantecが2016年6月1日以降に発行した証明書に対してChromeはコンソールに「The SSL certificate used to load resources from https://hoge.example.com will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information.」と警告を表示しています。M70って星雲?what is M70というところですが、Chromeのreleaseのmilestone 70の意味です。対象の証明書やスケジュールについては、表示されたhttps://g.co/chrome/symantecpkicertsや、SymantecのPKI関連を引き継いだDigiCertの記事を見るとよくわかると思います。ただし後者について、Chrome側は66と70は警告ではなくてdistrustと言っているので、コンソールの中では警告でしょうが、2016年6月1日より前発行の証明書はすでに、また2016年6月1日以降発行の証明書では”M70″で、NET::ERR_CERT_SYMANTEC_LEGACYの証明書エラーで、「これをウェブサイトのセキュリティや暗号通信機能は従来通り機能しますが、Google Chromeを利用するサイト訪問者に対しては警告が表示されます。」と書いてしまうと、まさかとは思いますがNET::ERR_CERT_SYMANTEC_LEGACYの表示は警告だから詳細表示をクリックしてあーたらこうたら指示する人が現れてしまうかもしれません。「この接続ではプライバシーが保護されません」の中からNET:ERR_CERT_SYMANTEC_LEGACYだけは警告というのは無理があるので、ずばり「Chromeではエラーになるので決して続行しないこと、続行させるような指示もしないこと」、技術者向けには「証明書を失効させるわけではないので他のブラウザでは当面エラーにはならないこと」を書き、機能はしているけどという方向での話にはしない方が良いかと思いました。MyEtherWalletのフィッシング事件はそれこそ偽物の証明書のエラーを無視して続行したためだそうで。
2018年9月13日にベータ版、2018年10月16日23日に安定版の予定のChrome 70は、canaryと呼ばれているunstable版のCrome 70は2018年07月20日頃出てくるそうなので、有効期間では失効せずに再発行の必要がある方は放置して試せばChromeの世界の証明書検証においては発行者不明の証明書と大差なくなったことが確認できると思います。翻訳記事SSL証明書の有効期限は2年に短縮される（2018年3月1日施行）にあるとおりすでに最長の証明書は825日までになっているので、なんか逆説的ですが早く対処すると損をする人がいらっしゃるかと思います。
言われるがままにあわててSymantecの証明書を再発行した自分や皆様におかれましては、2017年12月1日以降のnew Managed Partner Infrastructure稼動、それに合わせた証明書屋さんの対応がもし必要となればさらにその後からChrome 70(2018年9月13日頃beta,2018年10月16日23日頃安定版リリース)までの間にもう一度再発行しなければならないことが見込まれます。これにはSymantecでも2016年6月1日以降の発行だから大丈夫だもん、という方々も含まれます。Chrome 70対応期間はまたそれなりに流動的になるのでしょうが、こういうのが頻繁にあるとせっかくのHPKPやらTLSAやらCAAも担当者や部署が違ってめんどいからやめちゃおうという人も現れるでしょうからうれしくないですものの、通常の更新以外に2回も再発行を余儀なくされることを失効手順の確認もできるしこれからどんどん短くなっていくであろう証明書有効期間の準備になるととらえるのも良いです。そしたらド古いスマホやガラケーとか切り捨ててLet’s Encryptでいいやとなるのか、とか言ってるうちにDVだと鍵マーク出なくなるようになってもう何年も買ってないOVにすることになるのか。
Chromeの2017年7月27日の提案によれば2016年6月1日より前にSymantecより発行された証明書について、Chrome 62(2017年10月24日頃安定版リリース)で警告するようになり、Chrome 66(2018年3月15日頃beta,2018年4月17日頃安定版リリース)で信頼されなくなるとのことで、2017年8月8日という日付ではなくなったもののChrome62以降で警告もされないためには2017年12/1前後2回の再発行が必要になりそうです。NSSの動きにも注目です。サイト管理者の方はしばらくはbeta(やCanary)が出た時点で前もって動作確認しておいた方が安心かもしれません。
あとはこの
|
1 |
/usr/local/bin/openssl s_client -connect www.google.co.jp:443 -showcerts >google-cert.$(/bin/date '+%Y%m%d-%H%M%S') |
注) 2018年5月10日(無数のノードがあるでしょうから多少のずれはあると思います)に変化がありました。Equifaxのクロスルートではなくなって旧Symantec傘下のものは消滅し、GMOグループとなっているGlobalSignのCAがルートになっています。Maps APIについての記述ですがもともとそうなることが決まっていたようで、そのうちGoogleのCAになるのでしょう。
新
|
1 2 3 4 5 |
Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=google.com i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3 i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign |
旧
|
1 2 3 4 5 6 7 |
Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority |
証明書屋さんのスマホなんちゃら%対応の数字の変遷を見るのも楽しそうです。
注) 一応旧SymantecのPKIを引きついだDigiCertの状況だけリンク貼っておきます。Symantecは新しいmanaged infrastructureのCAの署名による証明書の発行しかできなくなってどうなるのかというところでしたが、末記のとおりDigiCertが引き継ぎ、DigiCert(と関連)CA証明書が搭載されていればよいという状況になったので特に楽しくないです。
注) そしてクロスルートとして使われていたIssuer C=US, O=Equifax, OU=Equifax Secure Certificate Authority のGeoTrust Global CA は Aug 21 04:00:00 2018 GMT をもって期限切れとなりました。サーバから送っている場合は問題の原因にしかならないのでさっさと削除するのが良いです。というかそもそもDigiCertで再発行でしょうか。
SHA-2対応版SSLサーバ証明書 プラットフォーム、携帯電話等機器対応状況
2017年12月以降に発行されたSSLサーバ証明書 (マネージドCA対応後のSSLサーバ証明書) クライアント対応状況
他にはCRLのサイズの変遷とかでしょうか。網羅するの大変そうですが、自分の旧証明書のCDPだけでも取っておきます。
|
1 2 |
fetch -q -o gv.crl.$(/bin/date '+%Y%m%d-%H%M%S') 'http://gv.symcb.com/gv.crl' >/dev/null 2>&1 fetch -q -o secureca.crl.$(/bin/date '+%Y%m%d-%H%M%S') 'http://crl.geotrust.com/crls/secureca.crl' >/dev/null 2>&1 |
どういう流れだったのか知りませんがGoogleのCAじゃなくて良かったとか胸をなでおろしているCAがあったりするんでしょうか…
とか書いていたらなんとみんなもう聞いたと思うけど、Symantec、PKI関連をDigiCertに売るってよ、だそうで、もう混沌でございます(NSS)。PKIが落ち着かないというのは良いことではないですが、スケジュール含めてどうなっていくでしょう。緊密にやっていくぜということなので注目です。