このページでは、サーバーで 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 を認証局に送信する
CSR を送信する方法は認証局(CA)によって異なります。たとえば、ウェブサイトでフォームを使用する、CSR をメールで送信するなどです。一部の CA またはその販売パートナーは、場合によっては、鍵ペアや CSR の生成など、プロセスの一部またはすべてを自動化することもあります。
CSR を CA に送信し、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
などのパスのみで始まる)にして、可能な限り相対 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>
<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>
<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>
ミスを防ぐため、手動でではなくスクリプトを使用してリンクを更新してください。サイトのコンテンツがデータベースにある場合は、データベースの開発コピーでスクリプトをテストします。サイトのコンテンツがシンプルなファイルのみで構成されている場合は、ファイルの開発コピーでスクリプトをテストします。通常どおり、変更が 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 の使用を「ロックイン」する準備が整いました。
- 301 リダイレクトのコストを回避するには、HTTP Strict Transport Security(HSTS)を使用します。
- Cookie には必ず Secure フラグを設定します。
まず、Strict Transport Security を使用して、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 での Chris Palmer による HTTPS と HTTP/2 のパフォーマンスに関する講演をご覧ください。
リファラー ヘッダー
ユーザーが HTTPS サイトから他の HTTP サイトへのリンクをたどる場合、ユーザー エージェントはリファラー ヘッダーを送信しません。これが問題となる場合は、解決する方法がいくつかあります。
- 他のサイトは HTTPS に移行する必要があります。参照先サイトがこのガイドのサーバーで HTTPS を有効にする手順を完了したら、自分のサイトへのリンクを
http://
からhttps://
に変更するか、プロトコル相対リンクを使用できます。 - 新しいリファラー ポリシー標準を使用すると、リファラー ヘッダーに関するさまざまな問題を回避できます。
広告収入
広告を表示してサイトを収益化している運営者は、HTTPS に移行することで広告のインプレッションが減少しないようにしたいと考えています。ただし、混合コンテンツのセキュリティに関する懸念から、HTTP <iframe>
は HTTPS ページでは機能しません。HTTPS でサイトを公開するまでは、HTTPS に移行しても広告収益が失われることはありませんが、HTTPS に移行するまでは、広告主が HTTPS を公開する動機はほとんどありません。
HTTPS で広告サービスを提供する広告主を利用し、HTTPS をまったく提供していない広告主に少なくとも選択肢として提供するよう依頼することで、この停滞を解消するプロセスを開始できます。十分な数の広告主と正しく相互運用できるまで、[イントラサイト URL を相対 URL にする] の手順は延期しなければならない場合があります。