Windows Server 2008 R2-SHA2ベースの暗号スイート
現在、管理しているさまざまなWebサイトのSSL証明書を、SHA1互換の証明書からSHA2互換の証明書にアップグレードしています。
これまでは、SSL証明書のキー交換メカニズムとして常に「RSA」を使用してきたため、交換用証明書の証明書署名要求を生成するときに、これを継続することにしました。
私の開発環境では、いくつかの証明書を置き換え、Webサーバー上のSHA256（SHA-2）ベースの暗号スイートを優先しました。
私はGoogle Chrome 42とFirefox 37.0.2がまだSHA1ベースの暗号スイートTLS_RSA_WITH_AES_256_CBC_SHAを選択していることに気付きました（まだInternet Explorerを適切にテストしていません）。
どの暗号スイートChrome 42およびFirefox 37.0.2のサポート）を判別するために、ネットワークトレースを実行し、TLSCipherSuitesをClientHello内に配置しました。
Chrome 42：
TLSCipherSuites: Unknown Cipher
TLSCipherSuites: Unknown Cipher
TLSCipherSuites: Unknown Cipher
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2B }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2F }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 { 0x00, 0x9E }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA { 0xC0,0x0A }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x39 }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA { 0xC0,0x09 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x33 }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA { 0xC0,0x07 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_RC4_128_SHA { 0xC0,0x11 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_GCM_SHA256 { 0x00, 0x9C }
TLSCipherSuites: TLS_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x35 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }
TLSCipherSuites: TLS_RSA_WITH_RC4_128_SHA { 0x00,0x05 }
TLSCipherSuites: TLS_RSA_WITH_RC4_128_MD5 { 0x00,0x04 }
TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }
TLSCipherSuites: Unknown Cipher
Firefox 37.0.2：
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2B }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2F }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA { 0xC0,0x0A }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA { 0xC0,0x09 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x33 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x39 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }
TLSCipherSuites: TLS_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x35 }
TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }
ウェブサーバー
私のWebサーバーはWindows Server 2008 R2を実行しており、次の暗号スイートをサポートしています（注-これはデフォルトの優先順位です。SHA256ベースのすべてのスイートに優先順位を付けています。
TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,SSL_CK_RC4_128_WITH_MD5,
SSL_CK_DES_192_EDE3_CBC_WITH_MD5,TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA
Chrome 42およびFirefox 37.0.2でサポートされているWindows Server 2008 R2に存在する唯一のSHA256暗号スイートはTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256です（Server 2008 R2では_P256が追加されていますただし、このスイートをサポートするには、鍵交換メカニズムをRSAからECDSA（楕円曲線デジタル署名アルゴリズム）に変更して証明書を再発行する必要があります。実際、これを試してみましたが、正常に機能しますが、多くの古いブラウザは楕円曲線暗号をサポートしていないため、これは実行可能なソリューションではありません。
- それで、FirefoxとChrome=古いブラウザとの互換性を壊さないWindows Server 2008 R2 Webサーバー上のSHA256暗号スイートを選択する方法はありますか？
- OSに暗号スイートを追加できますか？
2015年4月28日更新：
鍵交換アルゴリズムと署名アルゴリズムに関する追加の明確性について回答してくださった方々に感謝します。
できるブラウザが欲しい sHA256暗号スイートの使用 SHA2を使用してメッセージ認証を実行します。
しかし、問題はWindows Server 2008 R2内で利用可能なSHA256暗号スイートの問題のままです。ChromeとFirefoxの両方でサポートされているのはTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256だけです。そしてこの暗号を使用するためにスイートでは、ECDSA署名付き証明書が必要です。
私が理解しているように、Elliptic Curve Cryptographyは、一部の古いブラウザー/オペレーティングシステムのサポートを欠いています。私の質問で述べたように（用語を間違えましたが）、ECDSA署名付き証明書を作成しました。広範なテストは行っていませんが、これまでのところ、WindowsでIE7とIE8が実行されていることを確認しましたXP SP3は（HTTPS経由で）サイトをロードできず、「Internet ExplorerはWebページを表示できません」というメッセージを表示するだけです。
確かに、Windows XPは廃止されたOSですが、「古い」がまだ「サポートされている」ブラウザ/オペレーティングシステムが同じように失敗する可能性があるので心配です。したがって、 RSA署名付き証明書を使用して解決策を見つける際に-しかし、それは不可能のように思われます。
Ciphersuiteリストに表示されるSHA256参照は証明書用ではありません。むしろ、それらはTLS疑似ランダム関数とメッセージの整合性に関連しています。
証明書のサポートは、TLS暗号スイートから独立しています。
FirefoxのすべてのバージョンとChrome（および最近のバージョンのIE）は、オペレーティングシステムがそれらをサポートしている場合、SHA256証明書をサポートします。クライアントWindowsの場合、これはXP SP3およびサーバー2008 R2はSHA256証明書を完全にサポートしています。
暗号スイートの他の部分よりもSHA256 MACアルゴリズムを優先する必要はありません。最も重要ではない部分です。 IIS 7.5サーバーの今日の優先リストの最上位にあるはずの暗号スイートは、次のとおりです。
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521
探すべき重要な部分は次のとおりです。
- 鍵交換暗号（ECDHEは速度に最適な楕円曲線、前方秘匿性はEphemeral Diffie-Hellmanです）
- 証明書署名アルゴリズムとしてのRSA-ご存じのとおり、新しいECDSA証明書には古いクライアントとの互換性の問題があります
- 対称暗号。 AES GCM 128ビットが最適ですが、これを使用することはできず、現在WindowsでECDHE/RSAを維持できます。次善のものはAES CBC（128または256ビット）です。
IIS Crypto（ https://www.nartac.com/Products/IISCrypto/ ）を使用して、ベストプラクティスオプションを選択する必要があります。これにより、 IISで現在達成できる暗号スイートの順序。
この質問に対する私の答えも参照してください：
Windows Server 2008 R2は、IIS暗号のベストプラクティスを適用した後に暗号を有効にしました：
サーバー側のリストを取得するには、通常、ここで「サポートされている暗号スイートのリスト」にあるコンパイルされたバージョンのコードを使用します。
https://msdn.Microsoft.com/en-us/library/windows/desktop/bb870930（v = vs.85）.aspx
私がコンパイルしたバージョンをDropboxにアップロードしたのは、それを使用したい場合です（自己責任で私は責任を負いませんが、安全です！）
https://www.dropbox.com/s/mvajmebtyilgics/listciphers.exe?dl=
「Richie Frame」の答えが出ました。暗号スイート文字列が参照するのは、署名内のSHA256ではありません。しかし、リッチーの答えに加えて、追加のヒントがあります：
しかし、このスイートをサポートするには、鍵交換メカニズムを「RSA」から「ECDSA」（楕円曲線デジタル署名アルゴリズム）に変更する証明書を再発行する必要があります。
これはできません。セッションキー交換メカニズムは、証明書自体の内部でエンコードされていません。
鍵交換アルゴリズムと署名アルゴリズムを混同しています。 RSAはキー交換と署名の両方を実行できるため、混乱が生じます。
これはおおよそ次のように分解されます。
古い標準インストールの場合、RSA署名付き証明書があり、RSAを介してセッションキー交換も行います。
新しいタイプのインストールの場合、RSA署名付き証明書があり、Diffie-Hellmanセッションキー交換を行います。そして、証明書のRSAキーを使用して、その匿名キー交換を認証します。
今日の最先端のインストールでは、ECDSA署名付き証明書があり、Elliptic-Curve-Diffie-Hellman（ECDH）セッションキー交換を行います。そして、証明書のECDSAキーを使用して、その匿名キー交換を認証します。
2015年4月29日更新：sha256rsa certを使用
したがって、私はRSA署名付き証明書を使用してソリューションを見つけることに興味がありますが、それは不可能のようです。私はこれについて正しいですか？
いいえ。幸いにもあなたは間違っています。同じ証明書で両方を使用できます。一方向ハッシュ関数としてのSHA256および署名アルゴリズムとしてのRSA。 （この特定の組み合わせのコードネームは「sha256WithRSAEncryption」ですが、他にもたくさんあります。）（- https://www.ietf.org/ をご覧ください。彼らは現在、その正確な組み合わせを使用しています。 ）
互換性のために、IvanRistićのブログを読むことをお勧めします。
IvanRistić、 SHA1の廃止：知っておくべきこと （アーカイブ ここ 。）
そのブログのリンクの1つは、GlobalSign SHA-256互換性テーブルへのリンクです。それはあなたにとって特に興味深いかもしれません。
2015年4月29日更新：「RSA_WITH」で何かが欲しい
RSA証明書を取得している場合は、RSA暗号化を使用しています。暗号スイート記述子文字列の暗号化ビットは、「[〜＃〜] with [〜＃〜]」の直前のビットです。
したがって、あなたの場合、あなたは真ん中に「RSA_WITH」がある何かが欲しいです。上記で作成したFirefoxリストからこれらを取得しました。
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2F }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x33 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x39 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }
また、各文字列の末尾にある「SHA」または「SHA256」について心配する必要はありません。これは、証明書の内容をではなく参照します。同じアルゴリズムを参照しますが、証明書内のアプリケーションは参照しません。