最終更新日: | すべてのドキュメントを見る
ローカル開発で使用したり、Webアプリケーションと通信する必要があるネイティブアプリケーションに配布したりするために、「localhost」というホスト名の証明書を取得したい場合があります。Let's Encryptは「localhost」の証明書を提供できません。なぜなら、誰もそれを一意に所有しておらず、「.com」や「.net」のようなトップレベルドメインに根ざしていないからです。DNSチャレンジを使用して、127.0.0.1に解決されるドメイン名を独自に設定し、その証明書を取得することは可能です。ただし、これは一般的に悪い考えであり、より良い選択肢があります。
ローカル開発の場合
Webアプリを開発する場合、ApacheやNginxのようなローカルWebサーバーを実行し、Webブラウザーでhttp://localhost:8000/を介してアクセスするのが便利です。ただし、WebブラウザーはHTTPページとHTTPSページで微妙に異なる動作をします。主な違いは、HTTPSページでは、HTTP URLからJavaScriptを読み込むためのリクエストがブロックされることです。したがって、ローカルでHTTPを使用して開発している場合、開発マシンでは正常に動作するスクリプトタグを追加する可能性がありますが、HTTPS本番サイトにデプロイすると壊れます。この種の問題をキャッチするには、ローカルWebサーバーでHTTPSをセットアップすると便利です。ただし、常に証明書の警告が表示されるのは望ましくありません。ローカルで緑色の鍵マークを取得するにはどうすればよいでしょうか。
最良の選択肢：自己署名証明書またはローカルルートによって署名された証明書を生成し、オペレーティングシステムのトラストストアで信頼します。次に、その証明書をローカルWebサーバーで使用します。詳細については、以下を参照してください。
Webアプリと通信するネイティブアプリの場合
開発者が、追加機能を提供するためにWebサイトと並行して使用できるダウンロード可能なネイティブアプリを提供したい場合があります。たとえば、DropboxやSpotifyのデスクトップアプリは、Webアプリでは許可されない、マシン全体からファイルをスキャンします。一般的なアプローチの1つは、これらのネイティブアプリがlocalhostでWebサービスを提供し、WebアプリがXMLHTTPRequest（XHR）またはWebSocketを介してリクエストを送信することです。Webアプリはほぼ常にHTTPSを使用するため、ブラウザーは非セキュアURLへのXHRまたはWebSocketリクエストを禁止します。これは混合コンテンツブロッキングと呼ばれます。Webアプリと通信するには、ネイティブアプリはセキュアなWebサービスを提供する必要があります。
幸いなことに、最新のブラウザーは、http://127.0.0.1:8000/をループバックアドレスを参照するため、「潜在的に信頼できる」URLとみなします。127.0.0.1に送信されたトラフィックは、マシンから出ないことが保証されているため、ネットワーク傍受に対して自動的に安全であるとみなされます。つまり、WebアプリがHTTPSであり、127.0.0.1でネイティブアプリのWebサービスを提供する場合、2つはXHRを介して正常に通信できます。残念ながら、localhostはまだ同じ扱いを受けていません。また、WebSocketもどちらの名前でもこの扱いを受けません。
グローバルDNSで127.0.0.1に解決されるドメイン名（たとえば、localhost.example.com）を設定し、そのドメイン名の証明書を取得し、その証明書と対応する秘密鍵をネイティブアプリに同梱し、Webアプリにhttp://127.0.0.1:8000/の代わりにhttps://localhost.example.com:8000/と通信するように指示することで、これらの制限を回避しようとするかもしれません。これはしないでください。ユーザーを危険にさらす可能性があり、証明書が取り消される可能性があります。
IPアドレスの代わりにドメイン名を導入することで、攻撃者がDNSルックアップを中間者攻撃（MitM）し、別のIPアドレスを指す応答を注入することが可能になります。攻撃者はローカルアプリになりすまし、Webアプリに偽の応答を送信できます。これにより、Webアプリ側の設計によっては、Webアプリのアカウントが侵害される可能性があります。
この状況でのMitMの成功は、機能させるために、ネイティブアプリに証明書の秘密鍵を同梱する必要があったために可能です。つまり、ネイティブアプリをダウンロードした人は誰でも、攻撃者を含めて秘密鍵のコピーを入手できます。これは秘密鍵の侵害とみなされ、認証局（CA）は秘密鍵に気づいた場合、証明書を取り消す必要があります。多くのネイティブアプリは、証明書が秘密鍵を同梱したことで取り消されています。
残念ながら、これにより、ネイティブアプリは対応するWebサイトと通信するための優れた安全なオプションをあまり持たなくなります。また、ブラウザーがWebからのlocalhostへのアクセスをさらに強化すると、状況はさらに複雑になる可能性があります。
また、特権付きのネイティブAPIを提供するWebサービスをエクスポートすると、許可するつもりのなかったWebサイトがそれらにアクセスする可能性があるため、本質的に危険であることに注意してください。このルートに進む場合は、クロスオリジンリソース共有を読み、Access-Control-Allow-Originを使用し、メモリセーフなHTTPパーサーを使用してください。アクセスを許可しないオリジンでさえプリフライトリクエストを送信でき、パーサーのバグを悪用する可能性があるためです。
独自の証明書を作成して信頼する
誰でもCAの助けなしに独自の証明書を作成できます。唯一の違いは、自分で作成した証明書は他の誰にも信頼されないということです。ローカル開発では、これで問題ありません。
localhostの秘密鍵と自己署名証明書を生成する最も簡単な方法は、次のopensslコマンドを使用することです。
openssl req -x509 -out localhost.crt -keyout localhost.key \
-newkey rsa:2048 -nodes -sha256 \
-subj '/CN=localhost' -extensions EXT -config <( \
printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")
その後、ローカルWebサーバーをlocalhost.crtとlocalhost.keyで構成し、localhost.crtをローカルで信頼されたルートのリストにインストールできます。
開発証明書でもう少し現実感を持たせたい場合は、minicaを使用して独自のローカルルート証明書を生成し、それによって署名されたエンドエンティティ（別名リーフ）証明書を発行できます。この場合、自己署名のエンドエンティティ証明書ではなく、ルート証明書をインポートします。
127.0.0.1のエイリアスとして/etc/hostsに追加することで、www.localhostのようにドットを含むドメインを使用することもできます。これにより、ブラウザーがCookieストレージを処理する方法が微妙に変わります。