このページでは、次の手順を含む、サーバーで 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 の手順に沿って最終的な証明書または証明書チェーンを受け取ります。
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 サーバー テストを使用して HTTPS 構成を定期的に確認します。サイトのスコアは A または A+ にする必要があります。スコアが低い場合はバグとして扱い、常に注意を払ってください。アルゴリズムやプロトコルに対する新しい攻撃は常に開発されています。
サイト内の URL を相対 URL にする
サイトが HTTP と HTTPS の両方で配信されるようになったので、プロトコルに関係なく、できるだけスムーズに動作する必要があります。重要な要素の 1 つは、サイト内リンクに相対 URL を使用することです。
サイト内 URL と外部 URL が特定のプロトコルに依存していないことを確認します。相対パスを使用するか、//example.com/something.js のようにプロトコルを省略します。
HTTPS を使用して HTTP リソースを含むページを提供すると、問題が発生する可能性があります。ブラウザが安全でないリソースを使用している安全なページを見つけると、ページが完全に安全ではないことをユーザーに警告します。一部のブラウザでは、HTTP リソースの読み込みまたは実行が拒否され、ページが破損します。ただし、HTTP ページに HTTPS リソースを安全に含めることができます。これらの問題の解決に関する詳細なガイダンスについては、混合コンテンツの修正をご覧ください。
サイト内の他のページへの HTTP ベースのリンクをたどると、ユーザー エクスペリエンスが HTTPS から HTTP にダウングレードされることもあります。これを解決するには、プロトコル相対（プロトコルが指定されていない、//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 に合格した後にのみ、通常どおり本番環境に変更をプッシュします。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 フラグを設定します。
まず、厳格な転送セキュリティを使用して、http:// 参照をたどる場合でも、常に HTTPS を使用してサーバーに接続するようにクライアントに指示します。これにより、SSL ストリッピングなどの攻撃を防ぎ、HTTP を HTTPS にリダイレクトするで有効にした 301 redirect のラウンドトリップ コストを回避できます。
HSTS を有効にするには、Strict-Transport-Security ヘッダーを設定します。さまざまな種類のサーバー ソフトウェアの手順については、OWASP の HSTS ページをご覧ください。
ほとんどのウェブサーバーは、カスタム ヘッダーを追加する同様の機能を備えています。
また、クライアントが HTTP 経由で Cookie（認証やサイトの設定など）を送信しないようにすることも重要です。たとえば、ユーザーの認証 Cookie がプレーンテキストで公開された場合、他のすべてが正しく行われていたとしても、セッション全体のセキュリティ保証が破棄されます。
これを回避するには、設定する Cookie に Secure フラグを常に設定するようにウェブアプリを変更します。複数のアプリ フレームワークでSecure フラグを設定する方法については、こちらの OWASP のページをご覧ください。すべてのアプリ フレームワークには、フラグを設定する方法があります。
ほとんどのウェブサーバーは、シンプルなリダイレクト機能を備えています。301 (Moved Permanently) を使用して、HTTPS バージョンが正規であることを検索エンジンとブラウザに示し、HTTP から HTTPS バージョンのサイトにユーザーをリダイレクトします。
検索結果での掲載順位
Google は HTTPS を検索品質のプラス要因として使用しています。また、検索ランキングを維持しながらサイトを移行、移動、移転する方法に関するガイドも公開されています。Bing は、ウェブマスター向けのガイドラインも公開しています。
パフォーマンス
コンテンツ レイヤとアプリケーション レイヤが適切に調整されている場合（アドバイスについては Steve Souders の本を参照）、残りの TLS パフォーマンスに関する懸念は、通常、アプリケーションの全体的なコストに比べて小さくなります。これらの費用を削減して償却することもできます。TLS の最適化に関するアドバイスについては、Ilya Grigorik の High Performance Browser Networking、Ivan Ristic の OpenSSL Cookbook、Bulletproof SSL And TLS をご覧ください。
場合によっては、TLS によってパフォーマンスが向上することがあります。これは主に、HTTP/2 を可能にすることで発生します。詳細については、Chrome Dev Summit 2014 での HTTPS と HTTP/2 のパフォーマンスに関する Chris Palmer の講演をご覧ください。
リファラー ヘッダー
ユーザーが HTTPS サイトから他の HTTP サイトにリンクをたどると、ユーザー エージェントは Referer ヘッダーを送信しません。この問題を解決するには、いくつかの方法があります。
- 他のサイトは HTTPS に移行する必要があります。参照サイトがこのガイドのサーバーで HTTPS を有効にするセクションを完了している場合は、サイト内のリンクを
http://からhttps://に変更するか、プロトコル連動リンクを使用できます。 - Referrer ヘッダーに関するさまざまな問題を回避するには、新しいReferrer Policy 標準を使用してください。
広告収益
広告の表示によってサイトを収益化しているサイト運営者は、HTTPS への移行によって広告インプレッションが減少しないようにする必要があります。ただし、コンテンツの混在によるセキュリティ上の懸念があるため、HTTP <iframe> は HTTPS ページでは機能しません。広告主様が HTTPS 経由で広告を配信するまで、サイト運営者は広告収入を失うことなく HTTPS に移行できません。しかし、サイト運営者が HTTPS に移行するまで、広告主様は HTTPS で広告を配信する動機がほとんどありません。
この行き詰まりを打開するには、HTTPS 経由で広告サービスを提供している広告主を活用し、HTTPS をまったく配信していない広告主には、少なくともオプションとして設定するよう依頼します。十分な数の広告主様が適切に相互運用できるようになるまで、サイト内の URL を相対 URL にするを完了しないようにする必要があります。