ロードバランサーの背後でステートレスセッション再開キャッシュを有効にする方法は？
https://www.ssllabs.com/ssltest/ を使用してサーバーのSSL/TLS構成をスキャンしたところ、Session resumption (caching) No (IDs assigned but not accepted)が報告されました。
ラウンドロビンロードバランサーの背後でAzureWebロールの2つのインスタンスを使用しています。セッションIDが一方のサーバーにキャッシュされているが、もう一方のサーバーにはキャッシュされていないため、セッションの再開が壊れたと思います。
セッションIDに共有キャッシュ（できればRedis）を使用するようにIISを構成するにはどうすればよいですか？
更新：
セッションキャッシュを共有する方法はないようです。ただし、Windows Server 2012 R2はステートレス（チケットベース）セッションをサポートしているようです http://technet.Microsoft.com/en-us/library/hh831771.aspx#BKMK_Changes2012R2 。
http://technet.Microsoft.com/en-us/library/dn786418.aspx#BKMK_SchannelTR_IssuerCacheSize で説明されているように、HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\MaximumCacheSizeを0に設定して無効にしようとしましたセッションキャッシュですが、効果はありません。
New-TlsSessionTicketKeyおよびEnable-TlsSessionTicketKey（ http://technet.Microsoft.com/en-us/library/dn296629.aspx ）を使用してチケットベースのセッションを有効にしようとしましたが、効果もありません。
誰かがそれらの設定を機能させることができましたか？
更新2：
両方を設定することにより、セッションキャッシュを正常に無効にしました
- HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\MaximumCacheSizeを0に
- HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ServerCacheTime to 0
サーバーを再起動します
IIS AppPool\{app pool GUID}およびNetwork Serviceに対してEnable-TlsSessionTicketKeyコマンドを実行しても、チケットを機能させることができません。
最後に、win2k12r2およびwin2k16でTLSセッションチケットを有効にする方法を見つけました。次の手順に従う必要があります。
レジストリに値1のキー（
DWORD）を作成しますHKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\EnableSslSessionTicket次のPowerShellコマンドを使用して新しいTLSセッションチケットキーを作成します：
New-TlsSessionTicketKey -Password <password> -Path "C:\KeyConfig\TlsSessionTicketKey.config" -ServiceAccountName "System" https://technet.Microsoft.com/en-us/itpro/powershell/windows/tls/new-tlssessionticketkey次のPowerShellコマンドを使用してTLSセッションチケットキーを有効にします：
Enable-TlsSessionTicketKey -Password <password> -Path "C:\KeyConfig\TlsSessionTicketKey.config" -ServiceAccountName "System" https://technet.Microsoft.com/en-us/itpro/powershell/windows/tls/enable-tlssessionticketkeyサーバーを再起動して、TLSセッションチケットの生成を有効にします。レジストリエントリを有効にするには、再起動が必要です。
重要：負荷分散されたサーバー間で同じTLSセッションチケットを再利用するには、サーバーの1つで「C:\KeyConfig\TlsSessionTicketKey.config」コマンドを実行した後に生成された「New-TlsSessionTicketKey」ファイルをコピーしてから、の構成ファイルをコピーする必要があります。残りのすべてのサーバーで、各ファイルに対して「Enable-TlsSessionTicketKey」powershellコマンドを実行します。残念ながら、これはwin2k16でのみ機能しました。 win2k12r2では機能しませんでした。
どのセッションが関係しているかについて誤解があるかもしれません。
ほとんどのWebアプリケーションが、ショッピングカートのステレオタイプのコンテンツである複数のHTTPリクエスト間の永続性を作成するために使用するセッションがあります。 SSLLabsがテストしているものではありません。
関係なく：ロードバランサーを使用する場合は、通常、そのセッション状態を複製して、後続のHTTPリクエストが別のバックエンドウェブサーバーに配信されたときに訪問者が空のショッピングカートになってしまわないようにする必要があります。
SSLLabsがテストしているSSL/TLSセッションもあります。
つまり、SSL接続が確立されると、Webサーバーとブラウザーは最初は計算上比較的高価な公開鍵ハンドシェイク/ネゴシエーションを使用します（Diffie-Hellman）。そのネゴシエーションの一部は、その特定の接続に固有の対称鍵を確立することです。これは、その接続を介して送信されるデータの後続の暗号化/復号化に使用されます。対称暗号化は依然として安全ですが、計算量が比較的少ないため、WebサーバーとWebブラウザーの両方の負荷が軽減されます。プレーンHTTPとは異なり、WebブラウザーはWebサーバーへのHTTPS接続を開いたままにして、複数のHTTPS要求に使用しますが、アイドル時間の後も接続は閉じられます。
ここでSSLセッションキャッシュが機能します。有効にすると、新しい対称鍵をネゴシエートするのではなく、WebサーバーがWebブラウザーにその古い対称鍵を新しい接続で再利用できるようにする場合があります。利点は、おそらくセキュリティを犠牲にして、新しい接続がより迅速に確立されることです（これにより、TCP/IPのラウンドトリップが数回と大量の計算が節約されます）。
IIS（または他のWebサーバー）に、ロードブランされたクラスター内の他のノードにSSLセッションキャッシュを複製する機能があるかどうかはわかりません。どちらも必要ない場合があります。通常はいずれかのSSLロードバランサーで終了が行われるか、TCPスティッキーセッションを使用して、後続のHTTPS接続が同じWebサーバーによって処理されるようにし、WebサーバーがSSLセッションキャッシュを複製する必要をなくします。
それが適切でなく、WebサーバーがSSL再開のサポートをアドバタイズしているが、ロードバランサーが新しい接続を別のWebサーバーに分散している場合、不一致が作成されます。