ウェブサイトのSSL対応

注意: この記事は1年以上前に掲載されたものです。情報が古い場合がありますのでお気を付け下さい。

最近、Googleなどの企業を中心にサイト全体をSSL対応にしてしまう、いわゆる「常時SSL(Always on SSL)」の動きがあり、TwitterやFacebookなどのグローバルでメジャーなSNSサービスなどを中心に常時SSLの動きが活発となっており、当方もリダイレクトを駆使してドメイン認証ながら常時SSL対応へと移行した。さて、ここでは私が行ったSSL認証と手こずったことなどを述べてみたい。

当方の環境

当方では以下の環境からSSL環境を行った。

  • OS: Debian GNU/Linux 8 (Jessie)
  • HTTP Server: Apache 2.4.x (VirtualHost使用中)
  • SSL: OpenSSL OpenSSL 1.0.1k 8 Jan 2015

環境構築手順

SSLの鍵及び証明書を生成する

まず、RSA形式の秘密鍵を生成する。

$ cd /etc/ssl/certs/
$ sudo openssl genrsa -aes256 -out server.key 2048

ここでは比較的セキュリティー性を高める為、AES256形式で鍵の長さを2048bitとした。今日ではセキュリティーを考えると鍵長は2018bit以上が安全だろう。

この際、パスフレーズが求められるので、任意のパスフレーズを入れる。その後、パスフレーズを削除する。

$ sudo openssl rsa -in server.key -out server.key

ここでパスフレーズが求められるので鍵の生成の際に使用したパスフレーズを使用する。

その後、証明書要求ファイルの作成を行う。

$ sudo openssl req -new -days 3650 -key server.key -out server.csr

ここでは国・地域・都市・組織名・組織の部門名などを入力し、重要となるCommon Nameを入力する。Common Nameは基本的には主に使用するウェブサイトのドメイン(例えばwww.example.netなど)。

これで証明書発行要求ファイルが完成した。その後は各認証局に証明書を発行しなければならないが、自分で証明書を発行することも可能である ((いわゆる「オレオレ証明書」で、外部の認証局から認証された証明書よりも信頼性が低い)) 。ここでは、独自の証明書を作成する場合を想定して、以下のコマンドを入力する。

$ sudo openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 3650

server.crtが生成されたら、改竄防止のために、以下のコマンドを入れる。

$ sudo chmod 400 server.key
$ sudo chmod 400 server.csr
$ sudo chmod 400 server.crt

秘密鍵を隠蔽させるため、以下のコマンドを入れる。

$ sudo mv server.key ../private/

ApacheにOpenSSLを使用するように設定する

以下のコマンドを入れて、SSLモジュールを有効にする。

$ sudo a2enmod ssl

その後、/etc/apache2/sites-available/default-ssl.confに修正を加える。

$ sudo vi /etc/apache2/sites-available/default-ssl.conf

その後、ServerName、SSLCertificateFile、SSLCertificateKeyFileを検索して、以下のように修正する(ここではドメイン名をwww.example.netを指定した場合を想定)。

(略)
ServerName www.example.net
(略)
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
(略)

なお、この設定については、独自にサイト構成を変更している場合などではそれぞれに応じて適切な設定をする必要があるので要注意である。

その後、以下のコマンドを入力する。

$ sudo a2ensite default-ssl.conf
$ sudo service apache2 reload

ファイアウォールの設定

通常のHTTPプロトコルではポート番号80を使用するが、HTTPSでは443を使用する。もしポート番号443を開いていない場合は、iptablesなどの設定を変更してポートを開かなければならない。

ページ確認

これで、ブラウザを使って指定したページ(例えばhttps://www.example.net/など)を開くと、警告が表示される。これは証明書が信頼されたものでないことによるものである。なお、無視して続行すればページが表示されるはずである。

外部の認証機関の証明書を使用する場合

外部の証明書を使用する場合は、証明書要求ファイルを認証局にアップロードあるいは送信などのそれぞれの指定された手続きを経て、証明書が発行される。その後は証明書を保存するが、ルート証明書や中間証明書が必要になることが多い。これについては適切なものをダウンロードし、Apacheの/etc/apache2/sites-available/default-ssl.confなどに設定をする必要がある。

これについては各認証局によってまちまちになるため、割愛させてもらう。なお、外部の信頼された認証局で生成された証明書を使用、なおかつそれが適切なドメインで使われた場合は、通常警告が表示されずに正常にページが表示されるようになる ((サブドメインが違う場合は警告が表示されるが、ワイルドカード証明書はサブドメイン問わず問題なく使える)) 。

当方の場合

当方の場合、複数のサブドメインを使っていた関係上、上記の方法が使えなかった。また、ワイルドカード証明書を使っているわけではないことから、SSLを使うサブドメインは一つに抑えなければならない関係上、apacheの設定ファイルを弄り回した。

基本的には非SSL用とSSL用のVirtualHostは別々にしたほうが良いらしく、そうすることで冗長で片方を変更したらもう片方にも変更しなければならず面倒ながらも修正を加えることができた。

なお、非SSLでサイトを運営していた場合、SSLに移行する際で、特にWordPressを使用している場合は要注意である。私の場合は、テーマの設定がおかしくなってしまい、データをバックアップした上で一旦サイトの全データを削除、データベースも削除した上で再構築、バックアップしたデータをインポートして復旧する羽目になった。

当然ながら画像やプラグインなども消えてしまったが、それらのファイルの大半は原本を持っていたのでそれを使用してある程度は復活させることはできたのだが・・・。

リダイレクトもかなり難航した、自分が意図するリダイレクトをなかなかしてもらえず、しかも表示して欲しくないところで表示されてしまうという問題に直面し、なおかつダミー用のVirtualHostを設定したら今度は表示を想定したサイトが表示されなくなるという問題が発生したり。

現在では想定していた動作に戻ったので、ひとまずは問題なく運営できそうである。

最後に

まだ完全には普及しているとはいえないが、ウェブサイト全体をSSLで保護してしまうという動きがあるほか、検索エンジンでもHTTPSサイトが優先されるようになる傾向にシフトされるようになると言われているので、可能であればウェブサイト全体をSSLで保護してしまうのもありと考える。

個人サイトあるいは中小・零細企業で常時SSLは費用がかさむが、近年では年額でも1000〜2000円前後で導入できる格安、あるいは無償で利用できるものもあるため、それを利用するというのもありだろう。

ウェブサイトをSSL対応に移行させる際は困難に直面する可能性がたかいが、今後のサイト運営を考えたときに特に企業ではぜひ検討に入れたほうが良いだろう。

タイトルとURLをコピーしました