開発目的で使用するsubdomain.example.com
があります。私のWebアプリケーションソリューションには、外部システムから呼び出す必要があるWeb APIなどが含まれているため、localhostを使用していません。
SSLをテストし、subdomain.example.com
開発ドメイン名の証明書が必要になりました。
http://technet.Microsoft.com/en-us/library/cc753127(v = ws.10).aspx に記載されているように、自己署名証明書を作成しようとしましたが、この証明書のみローカルホストで動作します。この証明書は私の目的に使用できますか、または開発サブドメイン用に自己署名を作成する必要がありますか?開発サブドメインの自己署名証明書を作成する必要がある場合、これにはどのユーティリティまたはオンラインサービス(無料)を使用できますか?
この情報を追加しているのは、受け入れられた答えが質問に完全に対処していないようであるか、少なくとも私にとって問題を解決しなかったためです。
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
次に、Tom Hallの投稿で説明されているように、証明書がIIS Managerに表示されてサイトにバインドされます。
http://www.mikeobrien.net/blog/creating-self-signed-wildcard での彼の優れたブログ投稿について、Mike O'Brienに対するこのソリューションのすべての称賛
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 Managerを使用
www.domain.com
またはsubdomain.domain.com
特定のドメインの新しい証明書を作成するには:
Powershell ISEを管理者として開き、次のコマンドを実行します。
New-SelfSignedCertificate -DnsName *.mydomain.com, localhost -CertStoreLocation cert:\LocalMachine\My
新しい証明書を信頼するには:
証明書をサイトにバインドするには:
与えられた回答とその他のリソースからの断片を組み合わせて、Windowsで自己署名証明書を処理する方法に困惑しました。これが私自身の(そしてできれば完了した)ウォークスルーです。私自身の痛みを伴う学習曲線の一部をあなたが免れることを願っています。また、独自の証明書を作成すると、遅かれ早かれポップアップ表示される関連トピックに関する情報も含まれています。
Makecert.exeを使用しないでください。 Microsoftによって非推奨になりました。
最新の方法では、Powershellコマンドを使用します。
Windows 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
上記のコマンドは両方とも、ドメインlocalhost
および*.dev.local
の証明書を作成します。
Win10バージョンには、さらに15年の有効期間と「Dev Cert * .dev.local、dev.local、localhost」の読み取り可能な表示名があります。
更新:パラメータ-DnsName
で複数のホスト名エントリを提供する場合(上記を参照)、これらのエントリの最初がドメインのサブジェクト(通称)になります。すべてのホスト名エントリの完全なリストは、証明書のサブジェクトの別名(SAN)フィールドに保存されます。 (指摘してくれた@BenSewardsに感謝します。)
作成後、証明書はIISのHTTPSバインディングですぐに利用可能になります(以下の手順)。
新しい証明書は信頼チェーンの一部ではないため、どのブラウザーからも信頼できるとは見なされません。これを変更するには、マシン上の信頼されたルートCAの証明書ストアに証明書をコピーします。
Mmc.exeを開き、ファイル→スナップインの追加と削除→左の列の「証明書」を選択→追加→「コンピューターアカウント」を選択→次へ→「ローカルコンピューター...」→完了→OK
個人ストアから証明書をエクスポートします
左側の列で「証明書(ローカルコンピューター)/個人/証明書」を選択します。
新しく作成された証明書を見つけます(Win 10では、「フレンドリ名」列が役立ちます)。
この証明書を右クリック→すべてのタスク→エクスポート...→次へ→「いいえ、秘密鍵をエクスポートしない」を選択→次へ→「DER encoded ...」を選択→次へ→ファイル名を入力して保存する。
ヒント:意図的にPFXファイル形式をエクスポートに使用しません。それはあなたの秘密鍵をエクスポートファイルに含みます、そして、通常あなたはあなたの秘密鍵をどこにも行きたくないでしょう!
証明書を信頼されたルートCAストアにインポートします
左側の列で「証明書(ローカルコンピューター)/信頼されたルートCA /証明書」→すべてのタスク→インポート...→次へ→エクスポートしたファイルを選択→次へ→「すべての証明書を次のストアに配置」:信頼されたルートCA」→次へ→完了。
ISSで使用
IIS Managerに移動し、ローカルWebサイトのバインディングを選択→追加→https→myname.dev.local
(証明書は*.dev.local
に対してのみ有効)のホスト名を入力し、新しい証明書を選択→OK 。
ホストに追加
また、ホスト名をC:\ Windows\System32\drivers\etc\hostsに追加します。
127.0.0.1 myname.dev.local
幸せ
これで、ChromeおよびIEは証明書を信頼できるものとして扱い、https://myname.dev.local
を開くときにWebサイトをロードする必要があります。
Firefoxは独自の証明書ストアを保持しています。ここに証明書を追加するには、FFでWebサイトを開き、FFが証明書について警告するときに例外に追加する必要があります。
Edgeブラウザーの場合、さらにアクションが必要になる場合があります(さらに下を参照)。
証明書をテストするには、Firefoxが最適です。 (信じてください、私はChromeファンの少年ですが、この場合はFFの方が優れています。)
その理由は次のとおりです。
証明書は自己署名されているため、信頼されていません。
この警告は正しいです!上記のように、FirefoxはWindows証明書ストアを使用せず、例外を追加した場合にのみこの証明書を信頼します。これを行うボタンは、警告のすぐ下にあります。
証明書は名前に対して無効です...
この警告は、あなたが何か間違ったことをしたことを示しています。証明書の(ワイルドカード)ドメインがWebサイトのドメインと一致しません。この問題は、Webサイトの(サブ)ドメインを変更するか、一致する新しい証明書を発行することで解決する必要があります。実際、証明書が一致しない場合でもFFに例外を追加できますが、そのような組み合わせではChromeに緑色の南京錠記号が表示されることはありません。
Firefoxは、この場所で、期限切れの証明書、古い署名アルゴリズムを使用した証明書など、他の多くのわかりやすい証明書警告を表示できます。問題を特定するためのフィードバックレベルを提供してくれる他のブラウザは見つかりませんでした。
上記のNew-SelfSignedCertificateコマンドでは、ワイルドカードドメイン*.dev.local
を使用しました。
あなたは思うかもしれません:なぜ*.local
を使用しないのですか?
単純な理由:ワイルドカードドメインとしては違法です。
ワイルドカード証明書には少なくとも2番目のレベルのドメイン名が含まれている必要があります。
したがって、*.local
という形式のドメインは、HTTP 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レベルの部分に入れます。この方法で、すべての開発サイトの単一の証明書を取得できます。これは実際には自己署名証明書に関するものではありませんが、プロセス全体に関連しています。
上記の手順を実行した後、myname.dev.local
を開くと、Edgeはanyコンテンツを表示しない場合があります。
理由は、「ネットワーク分離」と呼ばれるWindows 10 for Modern Appsのネットワーク管理の特徴的な機能です。
この問題を解決するには、管理者権限でコマンドプロンプトを開き、次のコマンドを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を有効にしたいときに、この同じ問題に遭遇しました。最後に使用したツールは、makecertコマンドと何日も闘った後の OpenSSL でした。証明書はDebianで生成されますが、IIS 7および8にシームレスにインポートできます。
OSと互換性のある OpenSSL および this 構成ファイルをダウンロードします。構成ファイルをOpenSSLのデフォルト構成として設定します。
まず、認証局(CA)の秘密鍵と証明書を生成します。この証明書は、証明書リクエスト(CSR)に署名するためのものです。
このプロセスで必要なすべてのフィールドに入力する必要があります。
openssl req -new -x509 -days 3650 -extensions v3_ca -keyout root-cakey.pem -out root-cacert.pem -newkey rsa:4096
次のようなデフォルト設定で構成ファイルを作成できます。ここで、証明書リクエストを生成します。これは、認証局に送信されるファイルです。
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がインポートされる証明書を信頼できるため、CA証明書を信頼されたルート証明機関にインポートする必要があります。 IISにインポートされる証明書は、CAの証明書で署名されていることに注意してください。
この手順により、IISは証明書の信頼性を信頼します。
最後の手順では、証明書をIISにインポートし、バインドサイトを追加します。
IIS Managerのサイトに移動し、Bindings ...およびAdd新しいバインディングを選択します。
バインディングのタイプとしてhttpsを選択すると、インポートされた証明書が表示されるはずです。
別のオプションは、Webサイトごとにドメイン名を指定できる自己署名証明書を作成することです。これは、多くのドメイン名で使用できることを意味します。
IIS Manager
次に、IISのWebサイトで...
自己署名証明書を生成するもう1つの簡単な方法は、Jexus Managerを使用することです。
https://www.jexusmanager.com/en/latest/tutorials/self-signed.html