railsアプリケーションをhttpsでアクセスできるようにするまでのこと。

概要

もともと存在していたアプリケーションをhttpsでアクセスできるようにすることとなりました。
それまでにやったことと思ったことをつらつら書いていこうと思います。

最初からhttpsでアクセスする前提で作っていると楽なんでしょうけど、
世の中がみんなそうだったらきっと世の中は平和ですよね。
さぁ頑張りましょう。

目次

• まず環境
• rails自体の変更
• AWSの設定
• heroku周りの変更
• 余談:わけあってwordpressの変更
• データベースの変更
• デプロイなど

環境

• Rails 4系
• Ruby 2.2系
• サーバ: heroku
• データ置き場: AWS CloudFront/S3
• データ連携にWordpress

Railsの設定

アクセスを強制的にhttpsにする

すべてのアクセス？をhttpsに流す設定はconfigで設定が可能です。

config/environments/production.rb

config.force_ssl = true

これだけでhttpsでアクセスしてくれます、よかったですねー、かんたんですねー。

ソースコードのhttp

そうです、それだけで終わればなんの苦労もなかったんです。
確かにhttpsでアクセスはしてくれるんですが、httpリソースがのこっているとアドレスバーが緑色にならないのです。
歴史があるコードにはいたるところにhttp直書きが眠っています。
コードを書いた人が悪いのではありません。その時はきっとそうするしかなかったんです。
なので、歴史を感じながらhttpで書かなくて良いように変更していきましょう。

• railsのimage_urlで書けそうなところはそれに
• http://直書きのところは、http/httpsでアクセスできるように // からはじまる記述に変更
• http://から書く必要がある場所はhttps:// に

などしました。

cookieのsecure属性

同僚に教えてもらいました

これも対応しましょう。これもrailsで簡単に設定できます。

参考:
「Railsエンジニアが安心して新年を迎える方法」
http://qiita.com/masarakki/items/e498d257a2105d055281
ありがたい記事。

AWS

AWSはS3とcloudfrontにファイルを置いていました。
両サービスともawsが s3/cloudfront のアドレスでwildcardのsslが入っているのでそのアドレスであれば特に設定は入りません。
s3は問題なかったんですが、cloudfrontは 持っているドメインのサブドメインで設定していたのでそのアドレスの https通信が必要でした。

cloudfrontにACMを使う

cloudfrontを使用している場合は AWS Certificate Manager でSNI用のSSLが無料で設定できます。
これは記事がたくさんあるのでそちらが詳細でわかりやすいと思います。

参考:
「AWS Certificate Manager 無料のサーバ証明書でCloudFrontをHTTPS化してみた」
http://dev.classmethod.jp/cloud/aws/acm-cloudfront-ssl/

heroku周り

ここがやることが一杯ある感じです。そしてこれもheroku sslでググるとたくさん記事が出てくるのでそちらを参照されたし。
英語ですが結局公式のものが一番分かりやすかったです。

参考:
「heroku dev center」
https://devcenter.heroku.com/articles/ssl-endpoint

今回は、wildcardだったのと設定の連携が簡単そうだったので、SSLは推奨されているdnsimpleのものを使用するようにしました。
手順はほぼほぼ参考のサイトのままでアプリケーションの都合でちょっと他の作業を混ぜてという感じでした。

わけあってwordpress

わけあってwordpressの記事データでhttpで書かれているものをhttpsで書き直しました。
サーバはsakuraをつかっていて、さくらのアドレス *.sakura.ne.jp も案の定SSLが効いているので

• httpsに記述の変更
• worpressのサイトURLをhttpsから始まるものに変更
  • これをやるとwpでライブラリから記事に画像追加した時に変更をしたhttpsからはじまる画像リンクに変わる

データベースの変更

データベースのテーブルの中も当然のように画像などhttpから始まる文字列が大量にあったので、
洗い出しながら間違ったものを書き換えないようにsqlで文字列を変更していきました。

これは、思いもかけないテーブルからhttpリソースが見つかったりするので、
ステージ環境でmixed contentを探しては修正して、本番用のデータベース変更リストに追加して...を繰り返しました。

デプロイなど

上記が綺麗になって、ステージで問題なくなったところで

• herokuなどインフラの設定を変更
  • 厳密には上記の作業の中ですでにSSLの設置やDNSの変更やサーバにsslを有効にする設定など殆ど終わっているのでここの作業はなかった。
• 本番のデータベースを書き換え
  • すでに引っ張ってくるデータたちはhttpsが使えるようになっていたため
• デプロイ
• 確認

という形ですすめました。
大きな問題もなくなんとか無事終えることができました。
上記の順番はアプリの構成とかで順番は前後すると思うので一番影響範囲が少ない方法でという感じだと思います。

最後に

あくまで自分の作業メモですので、実際にされる際はあ、そんな作業もあるのねーとか参考リンクとかを参考にしてもらえればと思います。

ざっと書き出したらあまりやったことなかったなーと思ったんですが、
自分の体感としては、「あーここにもhttpがかくれてたー」の連続で結構苦闘した感じあります。
ファイルの更新や書き換え箇所もけっこうあり
コミットをまとまりで分割して確認し安くしたり、まとめてマージしてステージング前にほぼ緑のSSLマークになるのを確認できるようにしたりとかしてました。

先人の苦労を肌で感じながら歴史に思いをはせこの記事を終わります。