サーバーで HTTPS を有効にする

Chris Palmer
Chris Palmer

この記事で取り上げる手順

  1. 2,048 ビットの RSA 公開鍵/秘密鍵のペアを作成します。
  2. 公開鍵を埋め込んだ証明書署名リクエスト(CSR)を生成します。
  3. CSR を認証局(CA)と共有して、最終的な証明書または証明書チェーンを受け取ります。
  4. 最終的な証明書を、/etc/ssl(Linux および Unix)などウェブにアクセスできない場所や、IIS が必要とする場所(Windows)にインストールします。

鍵と証明書署名リクエストの生成

このセクションでは、ほとんどの Linux、BSD、Mac OS X システムに付属している openssl コマンドライン プログラムを使用して、秘密鍵/公開鍵と CSR を生成します。

公開鍵/秘密鍵のペアを生成する

まず、2,048 ビットの RSA 鍵ペアを生成します。1,024 ビットなどの小さい鍵では、ブルート フォース推測攻撃に対する耐性が不十分です。4,096 ビットなど、大きな鍵は過剰です。時間の経過とともに、コンピュータ処理のコストが下がるにつれて鍵のサイズは増加します。現在は 2,048 がスイート スポットです。

RSA 鍵ペアを生成するコマンドは次のとおりです。

openssl genrsa -out www.example.com.key 2048

これにより、次の出力が得られます。

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

証明書署名リクエストを生成する

このステップでは、公開鍵と、組織とウェブサイトに関する情報を証明書署名リクエスト(CSR)に埋め込みます。openssl コマンドは、必要なメタデータをインタラクティブに要求します。

次のコマンドを実行します。

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

次のように出力されます。

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

CSR の有効性を確認するには、次のコマンドを実行します。

openssl req -text -in www.example.com.csr -noout

レスポンスは次のようになります。

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

CSR を認証局に送信する

CSR を送信する方法は、認証局(CA)によって異なります。その方法には、ウェブサイトでフォームを使用する、メールで CSR を送信する、などがあります。一部の CA(またはその販売パートナー)は、プロセスの一部またはすべて(場合によっては鍵ペアや CSR の生成を含む)を自動化することもできます。

CSR を CA に送信し、その指示に従って最終的な証明書または証明書チェーンを受け取ります。

公開鍵のバウチャー サービスの料金は、CA によって異なります。

鍵を複数の DNS 名にマッピングするオプションもあります。たとえば、複数の異なる名前(example.com、www.example.com、example.net、www.example.net のすべて)や、*.example.com などの「ワイルドカード」名を使用できます。

たとえば、あるカナダでは現在、次の価格を提供しています。

  • 標準: 年間 16 米ドル、example.com と www.example.com で有効。
  • ワイルドカード: 年間 $150、example.com と *.example.com で有効。

上記の価格では、9 個を超えるサブドメインがある場合はワイルドカード証明書が経済的です。それ以外の場合は、1 つ以上の単一名の証明書を購入するだけで済みます。(たとえば、5 つを超えるサブドメインがある場合に、サーバーで HTTPS を有効にする場合は、ワイルドカード証明書を使用したほうが便利です)。

すべてのフロントエンド サーバーに、/etc/ssl(Linux、Unix)などのウェブアクセスが不可能な場所や、IIS(Windows)で必要な場所に証明書をコピーします。

サーバーで HTTPS を有効にする

サーバーで HTTPS を有効にすることは、ウェブページのセキュリティを確保するための重要なステップです。

  • Mozilla のサーバー設定ツールを使用して、HTTPS をサポートするようにサーバーを設定します。
  • Qualys の便利な SSL Server Test でサイトを定期的にテストし、少なくとも A または A+ を取得してください。

この時点で、運用に関する重要な決定を下す必要があります。次のいずれかを選択します。

  • ウェブサーバーがコンテンツを提供する各ホスト名に、個別の IP アドレスを割り当てます。
  • 名前ベースの仮想ホストを使用する。

ホスト名ごとに個別の IP アドレスを使用している場合は、すべてのクライアントで HTTP と HTTPS の両方を簡単にサポートできます。

ただし、ほとんどのサイト事業者は、名前ベースの仮想ホスティングを使用して IP アドレスを節約します。また、一般にその方が便利であるためです。Windows XP と Android 2.3 より前の IE の問題は、HTTPS 名ベースの仮想ホスティングに不可欠な Server Name Indication(SNI)を理解できないことです。

いつか(うまくいけばすぐに)、SNI をサポートしていないクライアントは最新のソフトウェアに置き換えられます。リクエストログのユーザー エージェント文字列をモニタリングして、十分な数のユーザーが最新のソフトウェアに移行したことを把握します。(しきい値は 5% 未満、または 1% 未満など、自由に設定できます)。

サーバーで HTTPS サービスを使用できない場合は、今すぐ有効にします(HTTP から HTTPS にリダイレクトしないでください。以下を参照)。購入してインストールした証明書を使用するようにウェブサーバーを構成します。Mozilla の便利な設定生成ツールをご活用ください。

ホスト名やサブドメインが複数ある場合は、それぞれ適切な証明書を使用する必要があります。

Qualys の便利な SSL Server Test で HTTPS 構成をチェックしましょう。サイトは A または A+ のスコアを獲得し、それより低い評価の原因となるものはすべてバグとして扱います。(アルゴリズムとプロトコルに対する攻撃は常に進化しているため、今日の A は明日の B になります)。

イントラサイト URL を相対 URL にする

HTTP と HTTPS の両方でサイトを提供しているので、プロトコルに関係なく、できるだけスムーズに処理を行う必要があります。重要なのは、イントラサイト リンクに相対 URL を使用することです。

イントラサイト URL と外部 URL がプロトコルに依存しないようにします。つまり、相対パスを使用するか、//example.com/something.js などのプロトコルを除外します。

混合コンテンツと呼ばれる HTTP リソースを含むページを HTTPS 経由で提供すると、問題が発生します。HTTPS の強度が完全に失われると、ブラウザはユーザーに警告します。実際、アクティブな混合コンテンツ(スクリプト、プラグイン、CSS、iframe)の場合、ブラウザは多くの場合、コンテンツをまったく読み込まないか実行せず、その結果としてページが破損します。なお、HTTP ページに HTTPS リソースを含めてもまったく問題ありません。

また、サイトの他のページにリンクすると、ユーザーが HTTPS から HTTP にダウングレードされる可能性があります。

これらの問題は、http:// スキームを使用する完全修飾のイントラサイト URL がページに含まれている場合に発生します。

すべきでないこと
<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
完全修飾のイントラサイト URL は使用しないでください。

つまり、イントラサイト URL は可能な限り相対 URL にします。プロトコル連動(//example.com で始まるプロトコルなし)か、ホスト相対(/jquery.js などのパスのみで始まる)のいずれかにします。

推奨事項
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24/">new post on cats!</a></p>
相対イントラサイト URL を使用する。
推奨事項
<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
または、プロトコル連動のイントラサイト URL を使用します。
推奨事項
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
サイト間 URL には HTTPS URL を使用する(可能な場合)。

この操作は、手動でではなく、スクリプトを使用して行います。サイトのコンテンツがデータベースにある場合は、データベースの開発用コピーでスクリプトをテストします。サイトのコンテンツがシンプルなファイルで構成されている場合は、ファイルの開発コピーでスクリプトをテストします。通常どおり、変更が QA に合格した後にのみ、変更を本番環境に push します。Bram van Damme のスクリプトなどを使用して、サイト内の混合コンテンツを検出できます。

他のサイトにリンクする場合(サイトのリソースを含めるのではなく)、プロトコルを変更しないでください。これらのサイトの動作を制御することはできません。

大規模なサイトで移行をスムーズに行うには、プロトコル連動 URL をおすすめします。HTTPS を完全にデプロイできるかどうか不明な場合は、すべてのサブリソースで HTTPS を使用せざるを得ないと、バックファイアが発生する可能性があります。HTTPS には不慣れな時期が来るかもしれませんが、HTTP サイトもこれまでと同じように機能する必要があります。時間が経つと、移行を完了して HTTPS でロックされます(次の 2 つのセクションを参照)。

サイトが CDN や jquery.com などのサードパーティから提供されるスクリプト、画像、その他のリソースに依存している場合は、次の 2 つの方法があります。

  • これらのリソースにはプロトコル連動 URL を使用します。サードパーティが HTTPS サービスを提供していない場合は、各社に依頼してください。jquery.com を含め、ほとんどの企業がすでに活用しています。
  • HTTP と HTTPS の両方を提供する、管理しているサーバーからリソースを提供します。この方法は、サイトの外観、パフォーマンス、セキュリティをより適切に管理できるため、いずれにしても良い方法です。さらに、サードパーティを信頼する必要はありません。これは常に良いことです。

HTTP を HTTPS にリダイレクトする

HTTPS がサイトへのアクセスに最適であることを検索エンジンに伝えるには、ページの先頭に正規リンクを配置する必要があります。

ページに <link rel="canonical" href="https://…"/> タグを設定します。これにより、検索エンジンがサイトへのアクセスに最適な方法を判断できるようになります。

Strict Transport Security と安全な Cookie をオンにする

これで、HTTPS の使用を「ロックイン」する準備が整いました。

  • HTTP Strict Transport Security(HSTS)を使用して、301 リダイレクトのコストを回避する。
  • Cookie には必ず Secure フラグを設定します。

まず、Strict Transport Security を使用して、http:// 参照に従う場合でも、常に HTTPS 経由でサーバーに接続する必要があることをクライアントに伝えます。これにより、SSL ストリッピングなどの攻撃が回避され、HTTP から HTTPS へのリダイレクトで有効にした 301 redirect のラウンドトリップ コストも回避されます。

Strict-Transport-Security ヘッダーを設定して、HTTP Strict Transport Security(HSTS)を有効にします。OWASP の HSTS ページに、さまざまなサーバー ソフトウェアの手順へのリンクがあります。

ほとんどのウェブサーバーには、カスタム ヘッダーを追加する同様の機能が備わっています。

また、クライアントが HTTP 経由で Cookie (認証やサイトの設定など)を送信しないようにすることも重要です。たとえば、ユーザーの認証 Cookie が書式なしテキストで公開されると、他のすべてを適切に行っても、セッション全体のセキュリティが保証されなくなります。

そのため、ウェブ アプリケーションを変更して、Cookie によって常に Secure フラグが設定されるようにしてください。この OWASP ページでは、いくつかのアプリケーション フレームワークで Secure フラグを設定する方法について説明します。どのアプリケーション フレームワークにも、フラグを設定する方法があります。

ほとんどのウェブサーバーには、単純なリダイレクト機能が備わっています。301 (Moved Permanently) を使用して、検索エンジンとブラウザに HTTPS バージョンが正規であることを通知し、HTTP からサイトの HTTPS バージョンにユーザーをリダイレクトします。

検索結果での掲載順位

Google は HTTPS を正の検索品質の指標として使用しています。Google は、検索ランクを維持しながらサイトを転送、移転、移行する方法に関するガイドも公開しています。Bing はウェブマスター向けのガイドラインも公開しています。

パフォーマンス

コンテンツ レイヤとアプリケーション レイヤが適切に調整されている場合(有用なアドバイスについては Steve Souders の書籍を参照)、残りの TLS パフォーマンスの懸念は、アプリケーションの全体的なコストと比較して一般的に小さくなります。また、これらの費用を削減し、償却することもできます。(TLS の最適化に関する優れたアドバイスと一般的な情報については、Ilya Grigorik による High Performance Browser Networking をご覧ください)。Ivan Ristic の OpenSSL CookbookBulletproof SSL And TLS もご覧ください。

場合によっては、主に HTTP/2 を可能にした結果として、TLS によってパフォーマンスが向上することがあります。Chris Palmer が Chrome Dev Summit 2014 で HTTPS と HTTP/2 のパフォーマンスについて講演しました。

リファラー ヘッダー

ユーザーが HTTPS サイトから他の HTTP サイトへのリンクをたどる場合、ユーザー エージェントはリファラー ヘッダーを送信しません。これが問題となる場合は、解決する方法がいくつかあります。

  • 他のサイトは HTTPS に移行する必要があります。参照先サイトがこのガイドのサーバーで HTTPS を有効にする手順を完了できる場合は、自分のサイトへのリンクを http:// から https:// に変更するか、プロトコル相対リンクを使用できます。
  • 新しいリファラー ポリシー標準を使用すると、リファラー ヘッダーに関するさまざまな問題を回避できます。

検索エンジンは HTTPS に移行するため、今後 HTTPS に移行すると、表示されるリファラー ヘッダーが多くなる可能性があります。

広告収入

広告を表示してサイトを収益化している運営者は、HTTPS への移行によって広告のインプレッションが減らないようにしたいと考えています。ただし、混合コンテンツのセキュリティ問題により、HTTP <iframe> は HTTPS ページでは機能しません。ここで、厄介な集団アクションの問題があります。広告主が HTTPS で公開するまで、サイト事業者は広告収入を失うことなく HTTPS に移行できないが、HTTPS に移行するまで、広告主が HTTPS を公開する動機はほとんどない。

広告主は、少なくとも HTTPS 経由で広告サービスを提供する必要があります(このページの「サーバーで HTTPS を有効にする」を完了するなど)。HTTPS をまったく提供していない広告主には、少なくとも提供を開始するよう依頼する必要があります。十分な数の広告主が適切に相互運用できるようになるまで、イントラサイト URL を相対 URL にするの手順は延期することをおすすめします。