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

Chris Palmer
Chris Palmer

このページでは、次の手順を含む、サーバーで HTTPS を設定するガイダンスについて説明します。

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

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

このセクションでは、ほとんどの Linux、BSD、Mac OS X システムに含まれる openssl コマンドライン プログラムを使用して、秘密鍵と公開鍵、および CSR を生成する方法を説明します。

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

まず、2,048 ビットの RSA 鍵ペアを生成します。短い鍵はブルート フォース攻撃で破られる可能性がありますが、長い鍵は不要なリソースを使用します。

次のコマンドを使用して 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 の送信

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

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

公開鍵の証票のサービスにかかる費用は、CA によって異なります。

複数の DNS 名に鍵をマッピングするためのオプションもあります。複数の別名（example.com、www.example.com、example.net、www.example.net など）、または *.example.com などの「ワイルドカード」の名前が利用可能です。

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

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

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

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

この時点で、運用について重要な意思決定を行う必要があります。次のいずれかを選択します。

  • ご使用のウェブサーバーのコンテンツ提供元である各ホスト名に、個別の IP アドレスを付与します。
  • 名前ベースの仮想ホストを使用します。

ホスト名ごとに個別の IP アドレスを使用している場合は、すべてのクライアントに対して HTTP と HTTPS の両方をサポートできます。しかし、ほとんどのサイト運営者は、名前ベースの仮想ホストを使って IP アドレスを節約します。また一般に、その方が便利だからでもあります。

ご使用のサーバーで HTTPS サービスが利用可能になっていない場合は、すぐに利用可能にしてください（HTTP から HTTPS にリダイレクトせずに。詳しくは、HTTP を HTTPS にリダイレクトするをご覧ください）。購入してインストールした証明書を使用するようにウェブサーバーを構成します。Mozilla の構成ジェネレーターが役立ちます。

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

サイトのライフタイムにわたって、Qualys の SSL Server Test を使用して HTTPS の設定を定期的に確認してください。サイトは A または A+ のスコアを取得する必要があります。それ以下のスコアの場合、原因となるものをバグとして扱ってください。アルゴリズムとプロトコルに対する新しい攻撃は常に開発されているため、常に注意を払ってください。

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

これで、HTTP と HTTPS の両方でサイトにコンテンツを提供できるようになりましたが、プロトコルにかかわらず、できるだけスムーズに動作させる必要があります。このために重要なのは、イントラサイト リンクに相対 URL を使用することです。

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

HTTPS を使用して HTTP リソースを含むページを配信すると、問題が発生する可能性があります。ブラウザが、安全でないリソースを使用している安全なページを見つけると、ページが完全に安全ではないことをユーザーに警告します。一部のブラウザでは、HTTP リソースの読み込みまたは実行が拒否され、ページが破損します。ただし、HTTP ページに HTTPS リソースを安全に含めることができます。これらの問題の解決に関する詳細なガイダンスについては、混合コンテンツの修正をご覧ください。

サイト内の他のページへの HTTP ベースのリンクをたどると、ユーザー エクスペリエンスが HTTPS から HTTP にダウングレードされることもあります。この問題を解決するには、イントラサイト 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>
可能であれば、他のサイトへのリンクに HTTPS URL を使用してください。

誤りを避けるため、手動ではなくスクリプトを使用してリンクを更新してください。サイトのコンテンツがデータベースにある場合は、データベースの開発コピーでスクリプトをテストします。サイトのコンテンツが単純なファイルのみで構成されている場合は、ファイルの開発コピーでスクリプトをテストしてください。通常どおり、変更は QA に合格した場合にのみ、実稼働環境にプッシュしてください。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://…"/> タグを使用して各ページの先頭にcanonical リンクを配置します。

ストリクト トランスポート セキュリティとセキュア Cookie を有効にする

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

  • HTTP ストリクト トランスポート セキュリティ（HSTS）を使用して、301 リダイレクトのコストを回避する必要があります。
  • Cookie には常に secure フラグを設定します。

まず、ストリクト トランスポート セキュリティを使用して、http:// リファレンスをたどる場合であっても、常に HTTPS 経由でサーバーに接続する必要があることをクライアントに伝えます。これにより、SSL ストリッピングなどの攻撃から守られ、HTTP から HTTPS へのリダイレクトで有効化した 301 redirect のラウンドトリップ コストを回避できます。

HSTS を有効にするには、Strict-Transport-Security ヘッダーを設定します。さまざまなサーバー ソフトウェアについては、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 Cookbook および Bulletproof SSL And TLS をご覧ください。

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

リファラー ヘッダー

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

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

広告収益

広告を表示することによって自分のサイトの収益化を図る運営者は、HTTPS に移行することで広告の表示回数が減少しないことを確認したいと考えます。ただし、混合コンテンツのセキュリティの問題により、HTTP <iframe> は HTTPS ページでは動作しません。広告主が HTTPS で公開するまで、サイト運営者は広告収入を損失することなく HTTPS に移行することはできません。しかし、サイト運営者が HTTPS に移行するまで、広告主は HTTPS を公開する動機があまりありません。

この行き詰まりを打開するには、HTTPS で広告サービスを提供している広告主を活用し、HTTPS をまったく配信していない広告主には、少なくともオプションとして設定するよう依頼します。十分な数の広告主と適切に相互運用できるようになるまで、イントラサイト URL を相対 URL にするの実施は遅らせることをおすすめします。