Chrome 66に備えるHTTPSは証明書の発行日と更新後の接続を確認する

HTTPSで公開していても、証明書が有効だから安心とは限らない。Chrome 66では、2016年6月1日より前にSymantecの認証局から発行されたTLS certificateを信頼しなくなる予定である。該当するsiteは、画面の鍵の印だけを見ず、実際に使っている証明書の発行日と発行者を確かめ、置き換えた後に読者が通常どおり開けるかまで確認する。

Chrome Security Teamは2017年9月、Chrome 66でSymantec発行の古い証明書への信頼を外す予定を案内した。案内では、2016年6月1日より前に発行された証明書が対象とされ、Chrome 66は3月15日ごろにBeta、4月17日ごろにStableへ出る予定である。証明書の名前にSymantecと書かれているだけで、すべて同じ影響を受けるわけではない。発行時期と、現在の接続で提示している証明書を分けて確かめる。

鍵の印と証明書の状態は同じではない

browserのaddress barに鍵の印が出ていると、HTTPSの設定は終わったように見える。しかし、その印は今使っているbrowserが接続を受け入れた結果であり、次のversionでも同じように開けることまで示すものではない。証明書の期限が残っていても、browser側の信頼の扱いが変われば、読者は警告画面を見ることになる。

今回確認するのは、site全体のURLをHTTPからHTTPSへ替える作業ではない。既にHTTPSで公開しているsiteについて、serverがどのTLS certificateを返しているかを確かめる作業である。URLの移転、内部link、検索結果の扱いは別の仕事になる。証明書の置換と一緒にURL構成まで替えると、接続の問題と移転の問題を分けられなくなる。

最初に、PCのbrowserでsiteを開き、鍵の印から接続情報を表示する。表示される証明書について、発行者、有効期間、発行日を控える。www付きとwwwなしで行き先を分けている場合、またはmail用、管理画面用、予約用に別のhost名を使っている場合は、一つのtop pageだけで終わらせない。読者が実際に開くhost名ごとに、どの証明書が出ているかを確認する。

たとえば、会社案内は https://www.example.jp/、問い合わせformは https://form.example.jp/ に置かれているとする。会社案内だけを開いて問題がなくても、form用のserverが古い証明書を返していれば、読者は問い合わせの直前で止まる。証明書の更新はdomain単位の作業に見えるが、接続先のhost名とserverの設定によって確認する場所が変わる。

発行者の名前だけで更新対象を決めない

Chromeの案内は、Symantecの古いPKIから発行された証明書を段階的に信頼しなくする計画である。Chrome 66で問題になる条件は、単に「Symantecを使っているか」ではなく、対象の証明書が2016年6月1日より前に発行されているかである。古い控えの請求書や、以前の契約先の名前だけから決めない。

serverを管理している会社へ依頼するときも、「SSLを更新してください」だけでは確認不足になりやすい。対象のdomain名とhost名、現在提示している証明書の発行者と発行日、置換する証明書、作業日時、作業後に確認するURLを一緒に渡す。依頼する側は何を更新するかを決め、作業する側はどのserverへ入れたかを返す。この二つを分けて残しておけば、後から別の担当者が見ても確認の範囲が分かる。

もしserverの契約先、証明書の発行元、siteを更新する人が別々なら、先に名義と管理権限を確認する。証明書を発行するaccountへ入れない場合、作業を急いでも新しい証明書を取得できない。外部の制作者やhosting会社が管理しているなら、誰が発行を申請し、誰がserverへ設定し、誰が公開画面を確認するかを決める。作業を任せても、domainと証明書の管理場所が分からなくなる状態は残さない。

更新後は一つの画面だけで完了にしない

新しい証明書を入れた後は、管理会社から「更新しました」と連絡を受けただけで終わらせない。まず、通常のbrowserでtop page、問い合わせpage、login pageなど、読者や運用者が使うURLを開く。次に、httpからhttpsへ送る設定があるなら、httpのURLを開いて意図したhttpsのURLへ進むかを見る。最後に、formや予約画面があるsiteでは、入力から送信完了までを一度通して確認する。

証明書の警告が出ないことと、siteの用件が済むことは別である。更新の作業中にserver設定を替えたことで、画像、外部script、mail送信、管理画面へのloginに影響が出ることがある。問い合わせformなら、画面が開くだけでなく、送信した内容が受信側へ届き、返信に使うaddressが残るかを見る。予約pageなら、日時を選んだ後の受付まで確認する。公開画面を一度も通さずに終えると、接続の警告は消えても、仕事の入口が止まっていることに気付きにくい。

確認した内容は、短く残せばよい。対象のhost名、作業日、置換前後の証明書の情報、確認したURL、確認者、問題があった場合の戻し方を書く。証明書の有効期限だけをcalendarへ入れても、次回に誰が更新するかが分からなければ、同じ不安が残る。期限の前に確認する人と、更新を依頼する人を決めておく。

影響しない場合も記録を残す

確認した結果、対象外の証明書だったとしても、何も残さないより、確認日と根拠を残す方がよい。Chrome 66の予定に合わせて発行日と発行者を見たことを記録すれば、次のbrowser更新や証明書更新のときに、どこから確かめればよいかが分かる。

逆に、対象かどうかを自分で判断できない場合は、推測で証明書を削除したり、URLの設定をまとめて替えたりしない。接続情報を記録して、serverの管理会社または証明書の発行元へ確認する。そこでは、Chrome 66で影響を受ける証明書か、新しい証明書をどのhost名へ設定するか、作業中に停止する機能があるかを聞く。答えを受けたら、公開画面で確かめるところまでを一つの作業にする。

HTTPSは、証明書を取得して終わるものではない。browserの信頼の扱いが変わるときは、発行日と発行者を調べ、管理する人を決め、更新後の読者の画面を確認する。この順序で進めれば、警告画面が出てから慌てて直すより、影響の範囲を小さくできる。