LCL Engineers' Blog

バス比較なび・格安移動・バスとりっぷを運営する LCLの開発者ブログ

自社サービスの常時SSL(サイト全体HTTPS)対応でやったこと

インフラ

Webエンジニアの森脇です。

弊社では先日「格安移動」という自社サービスの常時SSL化(サイト全体HTTPS化)へ対応しました。 この記事では、常時SSL対応のためにやったことを紹介したいと思います。

idou.me

なぜHTTPS化したか

GoogleやApple等のHTTPS化への積極的な姿勢を考慮すると、今後HTTPS化対応は避けられないと判断し、早い段階で対応しておいたほうが影響範囲が少ないと考えて対応に踏み切りました。

環境

サイトは以下の環境で構成されています。

  • AWS
  • ALB
  • Varnish
  • Nginx
  • Unicorn(Rails)

ALBまでをHTTPSで通信し、ALBから後ろはHTTPで通信させています。 サイト全体HTTPS化以前も、お問い合わせフォーム等の一部のページはHTTPS通信をしていました。

--- (HTTPS) ---> ALB --- (HTTP) --> Varnish --> Nginx

移行前の事前対応

できるだけ切り替え当日の作業量・影響範囲が少なくなるように、先行して対応できることは対応しておく方針にしました。

サードパーティタグが、HTTPS対応しているかの調査・修正

重要なサードパーティのタグがHTTPSへ対応できていない場合は、サイト全体のHTTPS対応を延期せざるを得ないため、最初に確認をしました。 全て問題ないことが確認できたので、現在httpで指定されているものは、プロトコル省略の形へ書き換えました。

http://
↓
//・・・

内部リンクを絶対から相対へ書き換え

サイトの内部リンクの指定が絶対URLの箇所が存在したため、こちらも事前に相対URLへ変更しました。

http://xxx.xxx.xx/yyy/zzz
↓
/yyy/zzz

キャッシュをHTTPSとHTTPで分ける

格安移動は、Varnishを利用しページをキャッシュしていますが、HTTPS/HTTPでキャッシュが別れておらず、HTTPSでアクセスした場合も、HTTPのキャッシュが返されてしまうという状態でした。そのため、HTTPS/HTTPのアクセスに応じて、キャッシュを別管理にする対応を実施しました。

なお、ALB→Varnishの通信はHTTPSではなくHTTPのため、大元のリクエストがHTTPSであることを判定するにはHTTPヘッダの「X-Forwarded-Proto」を利用して行いました。

sub vcl_hash {

  hash_data(req.url);

  # httpsとhttpでキャッシュを分ける
  if (req.http.X-Forwarded-Proto) {
    hash_data(req.http.X-Forwarded-Proto);
  }

  return (lookup);
}

移行に向けた準備

SSL証明書の導入

先行して一部のページでHTTPS対応を行っていたため、SSL証明書は既に導入済みであり、HTTPS化にともなって特に対応はしていません。

中間証明書の設定が漏れていると、一部のAndroid端末で警告が表示されてしまうため、証明書が正しく設定できているかどうかは、以下のサイトなどで事前チェックしおくことをおすすめします。

https://cryptoreport.geotrust.com/checker/

HTTP→HTTPSへのリダイレクト設定

nginxで301リダイレクトするようにしています。 Varnish→NginxへはHTTPリクエストとなるため、Varnishでの制御同様「http_x_forwarded_proto」で判断をしています。

if ($http_x_forwarded_proto != 'https') {
    return 301 https://$host$request_uri$is_args$args;
}

sitemap.xmlの出力URL変更

googleに送信するための、sitemap.xmlの出力URLをhttp→httpsに変更します。 robots.txtに、sitemap.xmlの配置URLを定義しているため、そちらもhttpsへ変更します。

Sitemap: https://idou.me/sitemap/sitemap.xml.gz
↓
Sitemap: http://idou.me/sitemap/sitemap.xml.gz

Cookieへのsecure属性付与

HTTPSのみCookieを送信するように、secure属性を付与しました。

HSTS対応

HSTSについては、トラブル時の切り戻しを考慮し、まずは対応を見送りましたが、今後対応予定です。

※ HSTSの説明については、下記をご参照ください。

HSTS (HTTP Strict Transport Security) の導入

移行作業

移行は部分的ではなく、一括で行いました。まだまだサイトの規模も小さいため、一括で行ってもそれほどリスクは大きくないと考えました。

大きく以下の流れで移行しています。

HTTP→HTTPSへのリダイレクト設定

設定後に、問題なくリダイレクトされることを確認します。 Google等のクローラーも問題なくHTTPSサイトへアクセスできていることをログで確認します。

Google Search Consoleの設定

HTTPS用に、新規にGoogle Search Consoleへサイトを追加する必要があるため、新たにサイトを追加します。

sitemap.xmlの再作成・送信

sitemap.xmlをHTTPS用のURLで再作成し、Google Search Consoleから送信します。

サイト外のURLの変更

外部のサイトから自サイトへリンクしているものは、自分たちで変更可能なものはHTTP→HTTPSへ変更しました。

  • 各種広告のURL
  • Twitter,Facebook等のURL
  • コーポレートサイトなどの外部サイト
  • 名刺等の紙媒体

移行後のチェック

Googleの順位に変動がないかどうか、HTTPSのサイトが正しくインデックスされるかどうかを重点的にチェックしています。今のところ順位変動はなく、徐々にHTTPSサイトも徐々にインデックスされています。

まとめ

HTTPS化対応は、かなり大変だと考えてましたが、意外と影響範囲は少なく、実質2,3日で対応完了しました。サイトの規模が大きくなるにつれて、対応工数・リスクは当然膨らんでいきますので、できるだけ早めの対応をおすすめいたします。