私はsubdomain.example.com開発目的で使用しています。私のWebアプリケーションソリューションには、外部システムから呼び出す必要があるWeb APIなどが含まれているため、localhostを使用していません。
SSLをテストする必要があり、subdomain.example.com開発ドメイン名の証明書が必要です。
http://technet.microsoft.com/en-us/library/cc753127(v=ws.10).aspxに概要が示されている自己署名証明書を作成しようとしましたが、この証明書はlocalhostでのみ機能します。この証明書を目的に使用できますか、それとも開発サブドメイン用の自己署名を作成する必要がありますか？開発サブドメインの自己署名証明書を作成する必要がある場合、どのユーティリティまたはオンラインサービス（無料）を使用できますか？
回答:
IISの自己署名証明書機能では、証明書に共通名（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
トムホールの投稿で説明されているように、証明書はIISマネージャーに表示され、サイトにバインドされます。
http://www.mikeobrien.net/blog/creating-self-signed-wildcardの優れたブログ投稿に対するMike O'Brienのこのソリューションに対するすべての称賛
sha1。置き換えて、2番目の呼び出しに-a sha512追加-len 2048することを検討してmakecertください。すべて順調です。
PowerShellの使用
Windows 8.1およびWindows Server 2012 R2（Windows PowerShell 4.0）以降では、新しいNew-SelfSignedCertificateコマンドレットを使用して自己署名証明書を作成できます。
例：
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.comNew-SelfSignedCertificate -FriendlyName *.mydomain.local -DnsName *.mydomain.local, localhost -CertStoreLocation Cert:\LocalMachine\Myこれが私が使用したコマンドです。これにより、個人ストアに証明書が作成されます。次に、最初に証明書をファイルにエクスポートしてから、IISマネージャーを介してIISに再インポートし（httpsバインディングに使用するため）、MMCを介して信頼されたルートCAに再インポートしました（ブラウザーの警告を回避するため）。
-NotAfterオプションは、有効期限を指定するのにも便利です（有効期限がない場合、デフォルトは1年だけです）。使用した例New-SelfSignedCertificate -DnsName *.mydomain.com -FriendlyName *.mydomain.com -NotAfter (Get-Date).AddYears(15) -CertStoreLocation cert:\LocalMachine\My
特定のドメインの新しい証明書を作成するには：
管理者としてPowershell ISEを開き、次のコマンドを実行します。
New-SelfSignedCertificate -DnsName *.mydomain.com, localhost -CertStoreLocation cert:\LocalMachine\My
新しい証明書を信頼するには：
証明書をサイトにバインドするには：
私は、与えられた回答やその他のリソースからのビットと断片を組み合わせることによって、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上記のように）パラメータに複数のホスト名エントリを指定すると、これらのエントリの最初のものがドメインのサブジェクト（通称）になります。すべてのホスト名エントリの完全なリストは、証明書のサブジェクト代替名（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証明書ストアを使用せず、例外を追加した場合にのみこの証明書を信頼します。これを行うためのボタンは警告のすぐ下にあります。
証明書は名前に対して無効です...
この警告は、あなたが何か間違ったことをしたことを示しています。証明書の（ワイルドカード）ドメインがWebサイトのドメインと一致しません。この問題は、Webサイトの（サブ）ドメインを変更するか、一致する新しい証明書を発行することによって解決する必要があります。実際、証明書が一致していなくてもFFに例外を追加できますが、そのような組み合わせではChromeに緑色の南京錠の記号が表示されることはありません。
Firefoxは、有効期限が切れた証明書、古い署名アルゴリズムを使用した証明書など、この場所で他の多くの優れたわかりやすい証明書警告を表示できます。問題を特定するためにそのレベルのフィードバックを提供してくれる他のブラウザーは見つかりませんでした。
上記のNew-SelfSignedCertificateコマンドでは、ワイルドカードドメインを使用しました*.dev.local。
あなたは考えるかもしれません：なぜ使用しないの*.localですか？
単純な理由：ワイルドカードドメインとしては違法です。
ワイルドカード証明書には、少なくとも第2レベルのドメイン名が含まれている必要があります。
したがって、フォームのドメインは*.localHTTP Webサイトを開発するのに適しています。ただし、HTTPSの場合はそれほどではありません。開始する新しいプロジェクトごとに新しい一致する証明書を発行する必要があるためです。
重要な補足事項：
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。
その理由は、「ネットワーク分離」と呼ばれる、Modern Apps用の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/を参照してください。
appname.dev has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can’t add an exception to visit this site.され、それは述べて、あなたはクライアントの例外、あなたの命令に反しを追加することはできません。これは、SSL設定、SSLが必要、およびクライアント証明書オプションに関して、IIS自体の悪い構成ですか？
*.mydomain.comはの有効な証明書になることができますが、の証明書でme.mydomain.comはありませんme.at.mydomain.com。
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をインポートします。
サーバーでは、CA証明書を信頼されたルート証明機関にインポートする必要があります。これは、IISがインポートされる証明書を信頼できるためです。IISにインポートされる証明書は、CAの証明書で署名されていることに注意してください。
この手順では、IISは証明書の信頼性を信頼します。
最後のステップでは、証明書をIISにインポートし、バインディングサイトを追加します。
次に、IISマネージャーのサイトに移動し、[ バインディング...]を選択して追加します、新しいバインディングします。
バインディングのタイプとしてhttpsを選択すると、インポートされた証明書が表示されます。
別のオプションは、Webサイトごとにドメイン名を指定できる自己署名証明書を作成することです。つまり、多くのドメイン名で使用できます。
IISマネージャー
IISのWebサイトで...
自己署名証明書を生成するもう1つの簡単な方法は、Jexus Managerを使用することです。
https://www.jexusmanager.com/en/latest/tutorials/self-signed.html
makecert.exeパスに含めるには、Visual Studio 2010コマンドプロンプトを使用する必要がありました。証明書については、もっと安全で使いやすいと思いました-a SHA512 -len 8192-生成するのに永遠にかかりました。そして、私はそれを疑ったように、IISが使用した暗号化のレベルに影響を与えませんでした。デフォルトでは、IISは128ビットを使用します。これを変更するには、グループポリシーなどを実行する必要があります。さらに他の読者に注意してください：の後-ekuにマジックナンバーを変更しないでください、それらは必須です。