私はsubdomain.example.com開発目的で使用しています。私の Web アプリケーション ソリューションには、外部システムから呼び出す必要がある Web API などが含まれているため、localhost を使用していません。
SSL をテストする必要があり、subdomain.example.com開発ドメイン名の証明書が必要です。
http://technet.microsoft.com/en-us/library/cc753127(v=ws.10).aspxで概説されているように、自己署名証明書を作成しようとしましたが、この証明書はローカルホストに対してのみ機能します。この証明書は自分の目的に使用できますか? それとも、開発サブドメイン用に自己署名を作成する必要がありますか? 開発サブドメインの自己署名証明書を作成する必要がある場合、どのユーティリティまたはオンライン サービス (無料) を使用できますか?
PowerShell の使用
New-SelfSignedCertificateWindows 8.1 および Windows Server 2012 R2 (Windows PowerShell 4.0) 以降では、新しいコマンドレットを使用して自己署名証明書を作成できます。
例:
New-SelfSignedCertificate -DnsName www.mydomain.com -CertStoreLocation cert:\LocalMachine\My
New-SelfSignedCertificate -DnsName subdomain.mydomain.com -CertStoreLocation cert:\LocalMachine\My
New-SelfSignedCertificate -DnsName *.mydomain.com -CertStoreLocation cert:\LocalMachine\My
IIS マネージャーの使用
www.domain.comまたはsubdomain.domain.comIIS の自己署名証明書機能では、証明書の共通名 (CN) を設定できないため、選択したサブドメインにバインドされた証明書を作成できません。
この問題を回避する 1 つの方法は、.Net 2.0 SDK にバンドルされている makecert.exe を使用することです。私のサーバーでは、次の場所にあります。
C:\Program Files\Microsoft.Net\SDK\v2.0 64bit\Bin\makecert.exe
次のように、署名機関を作成して LocalMachine 証明書リポジトリに保存できます (これらのコマンドは、管理者アカウントから、または昇格したコマンド プロンプト内で実行する必要があります)。
makecert.exe -n "CN=My Company Development Root CA,O=My Company,
OU=Development,L=Wallkill,S=NY,C=US" -pe -ss Root -sr LocalMachine
-sky exchange -m 120 -a sha1 -len 2048 -r
次に、サブドメインにバインドされ、新しい機関によって署名された証明書を作成できます。
(-in パラメーターの値は、上記の権限を生成するために使用された CN 値と同じでなければならないことに注意してください。)
makecert.exe -n "CN=subdomain.example.com" -pe -ss My -sr LocalMachine
-sky exchange -m 120 -in "My Company Development Root CA" -is Root
-ir LocalMachine -a sha1 -eku 1.3.6.1.5.5.7.3.1
Tom Hall の投稿で説明されているように、証明書は IIS マネージャーに表示され、サイトにバインドされます。
http://www.mikeobrien.net/blog/creating-self-signed-wildcardでの彼の優れたブログ投稿に対して、Mike O'Brien へのこのソリューションに対するすべての称賛
与えられた回答とその他のリソースからの断片を組み合わせて、Windows 上の自己署名証明書を解読する必要がありました。これが私自身の（そしてできれば完全な）ウォークスルーです。それが私自身の苦痛な学習曲線の一部をあなたに惜しまないことを願っています. また、独自の証明書を作成するときに遅かれ早かれポップアップする関連トピックに関する情報も含まれています。
makecert.exe を使用しないでください。Microsoft によって廃止されました。
最新の方法では、Powershell コマンドを使用します。
ウィンドウズ10：
管理者権限で Powershell を開きます。
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My -FriendlyName "Dev Cert *.dev.local, dev.local, localhost" -NotAfter (Get-Date).AddYears(15)
Windows 8、Windows Server 2012 R2:
これらのシステムの Powershell では、パラメータ -FriendlyName と -NotAfter は存在しません。上記のコマンドラインからそれらを削除するだけです。
管理者権限で Powershell を開きます。
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My
別の方法は、以下の古い Windows バージョンの方法を使用することです。これにより、証明書の作成に Win 10 のすべての機能を使用できます...
古い Windows バージョン:
古いバージョンの Windows に対する私の推奨事項は、Win 10 マシンで証明書を作成し、mmc インスタンスを使用して .PFX ファイルにエクスポートし (以下の「証明書を信頼する」を参照)、ターゲット マシンの証明書ストアにインポートすることです。古い Windows OS。証明書をインポートするには、右クリックしないでください。コンテキスト メニューに [証明書のインポート] 項目がありますが、Win Server 2008 で使用するためのすべての試行に失敗しました。代わりに、ターゲット マシンで別の mmc インスタンスを開き、[証明書 (ローカル コンピューター) / 個人 / 証明書] に移動します。 、中央のペインを右クリックして、[すべてのタスク] → [インポート] を選択します。
上記のコマンドは両方とも、ドメインlocalhostおよびの証明書を作成します*.dev.local。
さらに、Win10 バージョンの有効期間は 15 年で、読み取り可能な表示名は「Dev Cert *.dev.local, dev.local, localhost」です。
更新:パラメータに複数のホスト名エントリを指定すると-DnsName(上記のように)、これらのエントリの最初のエントリがドメインのサブジェクト (AKA Common Name) になります。すべてのホスト名エントリの完全なリストは、証明書のサブジェクト代替名 (SAN) フィールドに保存されます。（指摘してくれた@BenSewardsに感謝します。）
作成後、証明書は IIS の HTTPS バインディングですぐに利用できるようになります (以下の手順)。
新しい証明書は信頼チェーンの一部ではないため、どのブラウザからも信頼できるとは見なされません。これを変更するには、マシン上の信頼されたルート CA の証明書ストアに証明書をコピーします。
mmc.exe を開き、ファイル → スナップインの追加と削除 → 左側の列で「証明書」を選択 → 追加 → 「コンピューター アカウント」を選択 → 次へ → 「ローカル コンピューター...」 → 完了 → OK
左の列で、「証明書 (ローカル コンピューター) / 個人 / 証明書」を選択します。
新しく作成された証明書を見つけます (Win 10 では、「フレンドリ名」列が役立つ場合があります)。
この証明書を選択し、Ctrl-C を押してクリップボードにコピーします。
左側の列で、[証明書 (ローカル コンピューター) / 信頼されたルート CA / 証明書] を選択します。
Ctrl-V を押して、証明書をこのストアに貼り付けます。
証明書は信頼されたルート認証局のリストに表示され、信頼できると見なされます。
IISマネージャーに移動し、ローカルWebサイトのバインディングを選択→追加→https→フォームのホスト名を入力し myname.dev.local（証明書はのみ有効です*.dev.local）、新しい証明書を選択→OK.
ホストに追加
また、ホスト名を C:\Windows\System32\drivers\etc\hosts に追加します。
127.0.0.1 myname.dev.local
幸せ
これで、Chrome と IE は証明書を信頼できるものとして扱い、開いたときに Web サイトをロードする必要がありますhttps://myname.dev.local。
Firefox は独自の証明書ストアを保持しています。ここに証明書を追加するには、FF で Web サイトを開き、FF が証明書について警告したときにそれを例外に追加する必要があります。
Edge ブラウザーの場合は、さらにアクションが必要になる場合があります (以下を参照)。
証明書をテストするには、Firefox が最適です。（信じてください、私は自分自身 Chrome のファンですが、この場合は FF の方が優れています。）
理由は次のとおりです。
証明書は自己署名であるため、信頼されていません。
この警告は正しいです。上記のように、Firefox は Windows 証明書ストアを使用せず、Firefox 内で例外を追加した場合、この証明書のみを信頼します。これを行うためのボタンは、警告のすぐ下にあります。
証明書は名前に対して有効ではありません...
この警告は、何か間違ったことをしたことを示しています。証明書の (ワイルドカード) ドメインが Web サイトのドメインと一致しません。この問題は、Web サイトの (サブ) ドメインを変更するか、一致する新しい証明書を発行して解決する必要があります。実際、証明書が一致しない場合でも FF に例外を追加できますが、そのような組み合わせでは Chrome で緑色の南京錠の記号が表示されることはありません。
Firefox は、期限切れの証明書、古い署名アルゴリズムを使用した証明書など、この場所で他の多くの適切でわかりやすい証明書の警告を表示できます。問題を特定するためのこのレベルのフィードバックを提供してくれるブラウザーは他にありませんでした。
上記の New-SelfSignedCertificate コマンドでは、ワイルドカード domain を使用しました*.dev.local。
あなたは思うかもしれません：なぜ使わないの*.localですか？
単純な理由: ワイルドカード ドメインとしては違法です。
ワイルドカード証明書には、少なくともリテラルの第 2 レベル ドメイン名が含まれている必要があります。アスタリスク (*) は、3 番目のレベルから上にのみ使用できます。
したがって、xyz.localHTTP で開発し、証明書を必要としない場合、この形式のドメインは問題ありません。ただし、HTTPS でそのドメイン パターンを使用すると、開始する新しいプロジェクトごとに新しい一致する証明書を発行する必要があります。の形式のドメインxyz.dev.localと単一のワイルドカード証明書を使用することをお勧めし*.dev.localます。
重要な補足事項:
motör_head.dev.localをワイルドカード パターンに一致させることを頑固に拒否すると、苦労することがあります*.dev.local。に切り替えると準拠しますmotoer-head.dev.local。*.dev.local 一致し ますが、一致myname.dev.local しませんother.myname.dev.local!*.*.dev.local) は、証明書では使用できません。したがってother.myname.dev.local、フォームのワイルドカードでのみカバーできます*.myname.dev.local。したがって、第 4 レベルのドメイン部分は使用しないことをお勧めします。すべてのバリエーションを第 3 レベルのパートに入れます。このようにして、すべての開発サイトに対して単一の証明書を使用できます。これは実際には自己署名証明書に関するものではありませんが、プロセス全体に関連しています。
上記の手順を実行した後、Edgeを開いたときにコンテンツが表示されないmyname.dev.local場合があります。
その理由は、「ネットワークの分離」と呼ばれる最新のアプリ向け Windows 10 のネットワーク管理の特徴的な機能です。
この問題を解決するには、管理者権限でコマンド プロンプトを開き、次のコマンドを 1 回入力します。
CheckNetIsolation LoopbackExempt -a -n=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
エッジとネットワーク分離の詳細については、 https ://blogs.msdn.microsoft.com/msgulfcommunity/2015/07/01/how-to-debug-localhost-on-microsoft-edge/ を参照してください。
IIS 8 でホストされているプロジェクトに対して SSL を有効にしたいときに、この同じ問題に遭遇しました。詳細な記事をブログに投稿していますが、リンクの回答は提供したくありません。最後に使用したツールはOpenSSLで、何日もmakecertコマンドと戦った後です。証明書は Debian で生成されますが、IIS 7 および 8 にシームレスにインポートできました。
お使いの OS と互換性のあるOpenSSLとこの構成ファイルをダウンロードします。構成ファイルを OpenSSL のデフォルト構成として設定します。
まず、認証局 (CA) の秘密鍵と証明書を生成します。この証明書は、証明書要求 (CSR) に署名するためのものです。
このプロセスで必要なすべてのフィールドに入力する必要があります。
openssl req -new -x509 -days 3650 -extensions v3_ca -keyout root-cakey.pem -out root-cacert.pem -newkey rsa:4096次のようなデフォルト設定で構成ファイルを作成できます。 次に、認証局に送信されるファイルである証明書要求を生成します。
Common Name は、サイトのドメイン ( public.organization.comなど) に設定する必要があります。
openssl req -new -nodes -out server-csr.pem -keyout server-key.pem -newkey rsa:4096これで、生成された CA 証明書を使用して証明書要求が署名されました。
openssl x509 -req -days 365 -CA root-cacert.pem -CAkey root-cakey.pem -CAcreateserial -in server-csr.pem -out server-cert.pem生成された証明書は、IIS にインポートできる .pfx ファイルにエクスポートする必要があります。
openssl pkcs12 -export -out server-cert.pfx -inkey server-key.pem -in server-cert.pem -certfile root-cacert.pem -name "Self Signed Server Certificate"このステップでは、証明書 CA をインポートします。
この手順により、IIS は証明書の信頼性を信頼します。
[ OK]をクリックします。
次に、IIS マネージャーでサイトに移動し、[バインディング...]を選択して、[新しいバインディングを追加] を選択します。
バインディングのタイプとして https を選択すると、インポートされた証明書が表示されるはずです。
[ OK]をクリックすると、すべて完了です。
自己署名証明書を生成するもう 1 つの簡単な方法は、Jexus Manager を使用することです。
