トランスポート層セキュリティ (TLS) のレジストリ設定

適用対象: Server 2022、Windows Server 2019、Windows Server 2016、Windows 10、およびそれ以前のバージョン。

この記事では、Schannel セキュリティ サポート プロバイダー (SSP) を介したトランスポート層セキュリティ (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルの Windows 実装について、サポートされているレジストリ設定情報について説明します。 このトピックで取り上げるレジストリ サブキーとエントリは、Schannel SSP、特に TLS プロトコルと SSL プロトコルの管理とトラブルシューティングに役立ちます。

注意事項

この情報は、トラブルシューティングを行うとき、または必要な設定が適用されていることを確認するときに参照してください。 他の手段がない限り、レジストリは直接編集しないことをお勧めします。 レジストリに対する変更は、レジストリ エディターまたは Windows オペレーティング システムによる検証は行われずに適用されます。 このため、不適切な値が設定される場合があり、これにより回復不能なシステム エラーが発生することがあります。 可能な場合は、レジストリを直接編集するのではなく、グループ ポリシー、Microsoft 管理コンソール (MMC) などの他の Windows ツールを使用します。 レジストリを編集する必要がある場合は、細心の注意が必要です。

CertificateMappingMethods

既定では、このエントリはレジストリに存在しません。 既定値は以下に示す 4 つの証明書マッピング メソッドで、このメソッドすべてがサポートされています。

サーバー アプリケーションにクライアント認証が必要な場合、Schannel は、クライアント コンピューターによって指定された証明書をユーザー アカウントに自動的にマップしようとします。 クライアント証明書を使用してサインインするユーザーを認証するには、マッピングを作成します。これにより、証明書の情報が Windows ユーザー アカウントに関連付けられます。 証明書のマッピングを作成して有効にすると、そのユーザーは、クライアントがクライアント証明書を提示するたびに、サーバー アプリケーションによって適切な Windows ユーザー アカウントに自動的に関連付けられます。

ほとんどの場合、証明書は次の 2 つの方法のいずれかでユーザー アカウントにマップされます。

  • 1 つの証明書が 1 つのユーザー アカウントにマップされる (1 対 1 のマッピング)
  • 複数の証明書が 1 つのユーザー アカウントにマップされる (多対 1 のマッピング)

既定では、Schannel プロバイダーは、4 つの証明書マッピング メソッドを次の優先順位で使用します。

  1. Kerberos service-for-user (S4U) 証明書マッピング
  2. ユーザー プリンシパル名マッピング
  3. 1 対 1 のマッピング (サブジェクト/発行者マッピングとも呼ばれます)
  4. 多対 1 のマッピング

適用可能なバージョン: この記事の冒頭にある「適用対象」の一覧を参照。

レジストリ パス: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Ciphers

TLS/SSL 暗号は、暗号スイートの順序を構成して制御する必要があります。 詳細については、「TLS 暗号スイートの順序を構成する」を参照してください。

Schannel SSP によって使用される既定の暗号スイートの順序の詳細については、「TLS/SSL (Schannel SSP) の暗号スイート」を参照してください。

CipherSuites

TLS/SSL 暗号スイートの構成は、グループ ポリシー、MDM、または PowerShell を使用して行う必要があります。詳細については、「TLS 暗号スイートの順序を構成する」を参照してください。

Schannel SSP によって使用される既定の暗号スイートの順序の詳細については、「TLS/SSL (Schannel SSP) の暗号スイート」を参照してください。

ClientCacheTime

このエントリは、クライアント側のキャッシュ エントリの有効期限が切れるまでのオペレーティング システムの時間をミリ秒単位で制御します。 値 0 の場合、セキュリティで保護された接続のキャッシュが無効になります。 既定では、このエントリはレジストリに存在しません。

クライアントが初めて Schannel SSP 経由でサーバーに接続すると、フル TLS/SSL ハンドシェイクが実行されます。 これが完了すると、マスター シークレット、暗号スイート、および証明書は、クライアントおよびサーバーそれぞれのセッション キャッシュに格納されます。

Windows Server 2008 と Windows Vista 以降では、既定のクライアント キャッシュ時間は 10 時間です。

レジストリ パス: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

EnableOcspStaplingForSni

オンライン証明書状態プロトコル (OCSP) のホチキス止めでは、TLS ハンドシェイク中に、インターネット インフォメーションサービス (IIS) などの Web サーバーからクライアントにサーバー証明書を送信するときに、サーバー証明書の現在の失効状態を提供できます。 この機能により、Web サーバーはサーバー証明書の現在の OCSP の状態をキャッシュし、それを複数の Web クライアントに送信できるため、OCSP サーバーの負荷が軽減されます。 この機能がないと、各 Web クライアントは OCSP サーバーからサーバー証明書の現在の OCSP の状態を取得しようとします。 これにより、その OCSP サーバーに高い負荷が発生します。

http.sys 上の Web サービスでは、IIS に加えて、Active Directory フェデレーション サービス (AD FS) や Web アプリケーション プロキシ (WAP) など、この設定のメリットを受けることもできます。

既定では、OCSP のサポートは、セキュリティで保護された (SSL/TLS) シンプル バインディング使用する IIS Web サイトで有効になっています。 ただし、IIS Web サイトで次の種類の SSL/TLS バインディングのいずれかまたは両方を使用している場合、このサポートは既定では有効になりません。

  • Server Name Indication が必要
  • 集中証明書ストアを使用する

この場合、TLS ハンドシェイク中のサーバー hello 応答には、既定で OCSP ホチキス止めの状態は含まれません。 この動作によってパフォーマンスが向上します。Windows OCSP ホチキス止めの実装は、数百のサーバー証明書に拡張します。 SNI と CCS により、数千ものサーバー証明書が含まれる可能性のある数千の Web サイトに IIS を拡張できるため、この動作を既定で有効に設定すると、パフォーマンスの問題が発生する可能性があります。

適用可能なバージョン: Windows Server 2012 と Windows 8 以降のすべてのバージョン。

レジストリ パス: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

次のキーを追加します。

"EnableOcspStaplingForSni"=dword:00000001

無効にするには、DWORD 値を 0 に設定します。

"EnableOcspStaplingForSni"=dword:00000000

Note

このレジストリキーを有効にすると、パフォーマンスに影響する可能性があります。

FIPSAlgorithmPolicy

このエントリは、連邦情報処理規格 (FIPS) コンプライアンスを制御します。 既定値は 0 です。

適用可能なバージョン: Windows Server 2012 と Windows 8 以降のすべてのバージョン。

レジストリ パス: HKLM SYSTEM\CurrentControlSet\Control\LSA

Windows サーバー FIPS 暗号スイート: Schannel SSP でサポートされている暗号スイートとプロトコルに関するページを参照してください。

ハッシュ

TLS/SSL ハッシュ アルゴリズムは、暗号スイートの順序を構成して制御する必要があります。 詳細については、「TLS 暗号スイートの順序を構成する」を参照してください。

IssuerCacheSize

このエントリは、発行者のキャッシュのサイズを制御し、発行者のマッピングで使用されます。 Schannel SSP では、クライアント証明書の直接の発行者だけでなく、クライアントの証明書チェーンに含まれるすべての発行者をマップしようとします。 発行者がアカウントにマップされていない場合 (一般的なケース)、サーバーは同じ発行者名を繰り返しマップしようとすることがあり、その回数は 1 秒あたり数百回に及びます。

これを回避するために、サーバーにはネガティブ キャッシュが用意されており、発行者名がアカウントにマップされていないと、その発行者はキャッシュに追加されます。Schannel SSP は、キャッシュ エントリの有効期限が切れるまで、この発行者名をマップしません。 このレジストリ エントリは、キャッシュ サイズを指定します。 既定では、このエントリはレジストリに存在しません。 既定値は 100 です。

適用可能なバージョン: Windows Server 2008 と Windows Vista 以降のすべてのバージョン。

レジストリ パス: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

IssuerCacheTime

このエントリは、キャッシュ タイムアウト間隔をミリ秒単位で制御します。 Schannel SSP では、クライアント証明書の直接の発行者だけでなく、クライアントの証明書チェーンに含まれるすべての発行者をマップしようとします。 発行者がアカウントにマップされていない場合 (一般的なケース)、サーバーは同じ発行者名を繰り返しマップしようとすることがあり、その回数は 1 秒あたり数百回に及びます。

これを回避するために、サーバーにはネガティブ キャッシュが用意されており、発行者名がアカウントにマップされていないと、その発行者はキャッシュに追加されます。Schannel SSP は、キャッシュ エントリの有効期限が切れるまで、この発行者名をマップしません。 パフォーマンス上の理由から、このキャッシュは保持されるため、同じ発行者はマップされなくなります。 既定では、このエントリはレジストリに存在しません。 既定値は 10 分です。

適用可能なバージョン: Windows Server 2008 と Windows Vista 以降のすべてのバージョン。

レジストリ パス: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

KeyExchangeAlgorithm-クライアント RSA キーのサイズ

このエントリでは、クライアント RSA キーのサイズを制御します。

キー交換アルゴリズムの使用は、暗号スイートの順序を構成して制御する必要があります。

Windows 10、バージョン 1507 および Windows Server 2016 で追加されました。

レジストリ パス: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS

TLS クライアントでサポートされる RSA キーのビット長の最小範囲を指定するには、ClientMinKeyBitLength エントリを作成します。 既定では、このエントリはレジストリに存在しません。 エントリを作成した後、DWORD 値を任意のビット長に変更します。 構成されていない場合は、1024 ビットが最小値になります。

TLS クライアントでサポートされる RSA キー ビット長の最大範囲を指定するには ClientMaxKeyBitLength エントリを作成します。 既定では、このエントリはレジストリに存在しません。 エントリを作成した後、DWORD 値を任意のビット長に変更します。 構成されていない場合、最大値は適用されません。

KeyExchangeAlgorithm - Diffie-Hellman キー サイズ

このエントリは、Diffie-Hellman キー サイズを制御します。

キー交換アルゴリズムの使用は、暗号スイートの順序を構成して制御する必要があります。

Windows 10、バージョン 1507 および Windows Server 2016 で追加されました。

レジストリ パス: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman

TLS クライアントでサポートされる Diffie-Helman キーのビット長の最小範囲を指定するには、ClientMinKeyBitLength エントリを作成します。 既定では、このエントリはレジストリに存在しません。 エントリを作成した後、DWORD 値を任意のビット長に変更します。 構成されていない場合は、1024 ビットが最小値になります。

TLS クライアントでサポートされる Diffie-Helman キーのビット長の最大範囲を指定するには、ClientMaxKeyBitLength エントリを作成します。 既定では、このエントリはレジストリに存在しません。 エントリを作成した後、DWORD 値を任意のビット長に変更します。 構成されていない場合、最大値は適用されません。

TLS サーバーの既定の Diffie-Helman キーのビット長を指定するには、ClientMinKeyBitLength エントリを作成します。 既定では、このエントリはレジストリに存在しません。 エントリを作成した後、DWORD 値を任意のビット長に変更します。 構成されていない場合は、2048 ビットが既定値になります。

MaximumCacheSize

このエントリは、キャッシュ要素の最大数を制御します。 MaximumCacheSize を 0 に設定すると、サーバー側のセッション キャッシュが無効になり、再接続できなくなります。 前の MaximumCacheSize を増やすと、既定値によって Lsass.exe が消費するメモリ量が多くなります。 通常、各セッション キャッシュ要素には 2 KB から 4 KB のメモリが必要です。 既定では、このエントリはレジストリに存在しません。 既定値は 20,000 要素です。

適用可能なバージョン: Windows Server 2008 と Windows Vista 以降のすべてのバージョン。

レジストリ パス: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

メッセージング – フラグメント解析

このエントリでは、受け入れられる断片化された TLS ハンドシェイク メッセージの最大許容サイズを制御します。 許容サイズを超えるメッセージは受け入れられず、TLS ハンドシェイクが失敗します。 これらのエントリは、既定ではレジストリに存在しません。

値を 0x0 に設定すると、断片化されたメッセージは処理されず、TLS ハンドシェイクが失敗します。 これにより、現在のマシン上の TLS クライアントまたはサーバーが TLS RFC に非準拠になります。

最大許容サイズは、最大 2^24-1 バイトまで増やすことができます。 クライアントまたはサーバーがネットワークから大量の未確認データを読み取って格納できるようにすると、セキュリティ コンテキストごとに追加のメモリを消費するため、お勧めしません。

Windows 7 および Windows Server 2008 R2 で追加: 断片化された TLS/SSL ハンドシェイク メッセージを Windows XP、Windows Vista、または Windows Server 2008 の Internet Explorer で解析できる更新プログラムを使用できます。

レジストリ パス: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging

TLS クライアントが受け入れるフラグメント化された TLS ハンドシェイク メッセージの最大許容サイズを指定するには、MessageLimitClient エントリを作成します。 エントリを作成した後、DWORD 値を任意のビット長に変更します。 構成されていない場合、既定値は 0x8000 バイトになります。

クライアント認証がない場合に、TLS サーバーが受け入れるフラグメント化された TLS ハンドシェイク メッセージの最大許容サイズを指定するには、MessageLimitServer エントリを作成します。 エントリを作成した後、DWORD 値を任意のビット長に変更します。 構成されていない場合、既定値は 0x4000 バイトになります。

クライアント認証がある場合に、TLS サーバーが受け入れるフラグメント化された TLS ハンドシェイク メッセージの最大許容サイズを指定するには、MessageLimitServerClientAuth エントリを作成します。 エントリを作成した後、DWORD 値を任意のビット長に変更します。 構成されていない場合、既定値は 0x8000 バイトになります。

SendTrustedIssuerList

このエントリは、信頼された発行者一覧の送信時に使用されるフラグを制御します。 クライアント認証に対して数百の証明機関を信頼しているサーバーの場合、発行者が多すぎて、そのサーバーは、クライアント認証を要求するときに、発行者の一部をクライアント コンピューターに送信できません。 このレジストリ キーは、この状況で設定できます。これにより、Schannel SSP は部分的な一覧を送信するのではなく、まったく送信しなくなります。

信頼された発行者の一覧を送信しないと、クライアント証明書が要求されたときにクライアントが送信する内容に影響する可能性があります。 たとえば、Internet Explorer がクライアント認証要求を受信するときに表示されるのは、サーバーによって送信された証明機関のいずれかにチェーンでつながっているクライアント証明書のみです。 サーバーが一覧を送信しなかった場合、Internet Explorer には、クライアントにインストールされているすべてのクライアントの証明書が表示されます。

この動作が望ましいことがあります。 たとえば、PKI 環境にクロス証明書が含まれる場合、クライアント証明書とサーバーの証明書のルート CA は同じではありません。したがって、Internet Explorer は、サーバーの CA のいずれかにチェーンでつながっている証明書を選択できません。 信頼された発行者の一覧を送信しないようにサーバーを構成すると、Internet Explorer はその証明書すべてを送信します。

既定では、このエントリはレジストリに存在しません。

信頼された発行者の一覧を送信する既定の動作

Windows のバージョン 既定の動作
Windows 2012 と Windows Server 8 以降 FALSE
Windows Server 2008 R2 と Windows Server 7 以降 TRUE

適用可能なバージョン: Windows Server 2008 と Windows Vista 以降のすべてのバージョン。

レジストリ パス: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

ServerCacheTime

このエントリは、サーバー側のキャッシュ エントリの有効期限が切れるまでのオペレーティング システムの時間をミリ秒単位で制御します。 値を 0 に設定すると、サーバー側のセッション キャッシュが無効になり、再接続できなくなります。 前の ServerCacheTime を増やすと、既定値によって Lsass.exe が消費するメモリ量が多くなります。 通常、各セッション キャッシュ要素には 2 ~ 4 KB のメモリが必要です。 既定では、このエントリはレジストリに存在しません。

適用可能なバージョン: Windows Server 2008 と Windows Vista 以降のすべてのバージョン。

レジストリ パス: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

既定のサーバー キャッシュ時間: 10 時間

TLS、DTLS、SSL プロトコルのバージョン設定

Schannel SSP では、TLS、DTLS、および SSL プロトコルのバージョンを実装します。 Windows ごとに、異なる プロトコル バージョンがサポートされます。 システム全体で使用できる (D)TLS および SSL バージョンのセットは、AcquireCredentialsHandle 呼び出しで SCH_CREDENTIALS または SCHANNEL_CRED のいずれかの構造を指定して、SSPI 呼び出し元で制限できます (拡張はできません)。 SSPI 呼び出し元では、プロトコルのバージョンを制限するのではなく、システムの既定値を使用することをお勧めします。

サポートされている (D)TLS または SSL プロトコルのバージョンは、次のいずれかの状態で存在できます。

  • 有効: SSPI 呼び出し元が SCH_CREDENTIALS 構造を使用して、このプロトコル バージョンを明示的に無効にしない限り、Schannel SSP は、サポートするピアとこのプロトコル バージョンをネゴシエートする場合があります。
  • 既定で無効: SSPI 呼び出し元が非推奨の SCHANNEL_CRED 構造を使用して、このプロトコル バージョンを明示的に要求しない限り、Schannel SSP はこのプロトコル バージョンをネゴシエートしません。
  • 無効: SSPI 呼び出し元が指定できる設定に関係なく、Schannel SSP は、このプロトコル バージョンをネゴシエートしません。

システム管理者は、DWORD レジストリ値 "Enabled" と "DisabledByDefault" を作成して、既定の (D)TLS および SSL プロトコル バージョンの設定をオーバーライドできます。 これらのレジストリ値は、次の形式を使用して、名前付きのレジストリ サブキーの下のプロトコル クライアントロールとサーバー ロールに対して個別に構成されます。

<SSL/TLS/DTLS><メジャー バージョン番号>.<マイナー バージョン番号><クライアント\サーバー>

これらのバージョン固有のサブキーは、次のレジストリ パスの下に作成できます。

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

たとえば、バージョン固有のサブキーが含まれる有効なレジストリ パスを次に示します。

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\DTLS 1.2\Client

システムの既定値をオーバーライドし、サポートされている (D)TLS または SSL プロトコル バージョンを [有効] 状態に設定するには、対応するバージョン固有のサブキーの下に、0 以外の値の "Enabled" という名前の DWORD レジストリ値と、0 の値の "DisabledByDefault" という名前の DWORD レジストリ値を作成します。

次の例では、TLS 1.0 クライアントが [有効] 状態に設定されています。

Windows Server レジストリ設定の

システムの既定値をオーバーライドし、サポートされている (D)TLS または SSL プロトコル バージョンを [既定で無効] 状態に設定するには、対応するバージョン固有のサブキーの下に、0 以外の値の "DisabledByDefault" と "Enabled" という名前の DWORD レジストリ値を作成します。 次の例では、TLS 1.0 サーバーが [既定で無効] 状態に設定されています。

TLS 1.0 サーバー側の Windows Server レジストリ設定で既定で無効状態に設定されたオーバーライドのスクリーンショット。

システムの既定値をオーバーライドし、サポートされている (D)TLS または SSL プロトコル バージョンを [無効] 状態に設定するには、対応するバージョン固有のサブキーの下に、0 の値の "Enabled" という名前の DWORD レジストリ値を作成します。

次の例では、レジストリで DTLS 1.2 が無効になっています。

既定で無効に設定された DTLS 1.2 の Windows Server レジストリ設定のスクリーンショット。

(D)TLS または SSL プロトコル バージョンを [既定で無効] または [無効] 状態に切り替えると、AcquireCredentialsHandle 呼び出しが失敗する可能性があります。これは、システム全体で有効になっていると同時に、特定の SSPI 呼び出し元で許可されているプロトコル バージョンがないためです。 さらに、[有効] になっている (D)TLS および SSL バージョンのセットを減らすと、リモート ピアとの相互運用性が損なわれる可能性があります。

(D)TLS または SSL プロトコル バージョンの設定が変更されると、後続の AcquireCredentialsHandle 呼び出しによって開かれた資格情報ハンドルを使用して確立された接続で有効になります。 (D)TLS と SSL のクライアントおよびサーバー アプリケーションとサービスは、パフォーマンス上の理由から、複数の接続に対して資格情報ハンドルを再利用する傾向があります。 これらのアプリケーションが資格情報ハンドルを再取得するには、アプリケーションまたはサービスの再起動が必要になる場合があります。

これらのレジストリ設定は Schannel SSP にのみ適用されるため、システムにインストールされている可能性のあるサードパーティの (D)TLS と SSL の実装には影響しないことに注意してください。