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

適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows 10

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

注意事項

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

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 ハンドシェイクが実行されます。 これが完了すると、マスター シークレット、暗号スイート、および証明書は、クライアントおよびサーバーそれぞれのセッション キャッシュに格納されます。

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

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

EnableOcspStaplingForSni

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

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

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

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

この場合、TLS ハンドシェイク中のサーバーの hello 応答には、既定で OCSP のステープル状態は含めされません。 この動作により、パフォーマンスが向上します。OCSP のWindows実装は、数百のサーバー証明書にスケーリングされます。 SNI と CCS を使用すると、IIS は何千ものサーバー証明書を持つ可能性のある数千の Web サイトにスケーリングできます。この動作を既定で有効にすると、パフォーマンスの問題が発生する可能性があります。

該当するバージョン: Windows Server 2012 および Windows 8 で始まるすべてのWindows 8。

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

次のキーを追加します。

"EnableOcspStaplingForSni"=dword:00000001

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

"EnableOcspStaplingForSni"=dword:00000000

注意

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

FIPSAlgorithmPolicy

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

該当するバージョン: Windows Server 2012 および Windows 8 で始まるすべての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 キーのサイズを制御します。

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

バージョン 1507 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 キービット長を指定するには、 Serverminkeybitlength エントリを作成します。 既定では、このエントリはレジストリに存在しません。 エントリを作成した後、DWORD 値を目的のビット長に変更します。 構成されていない場合、2048ビットが既定値になります。

MaximumCacheSize

このエントリは、キャッシュ要素の最大数を制御します。 MaximumCacheSize を 0 に設定すると、サーバー側のセッション キャッシュが無効になり、再接続できなくなります。 前の MaximumCacheSize を増やすと、既定値によって Lsass.exe が消費するメモリ量が多くなります。 通常、各セッション キャッシュ要素には 2 ~ 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 で追加されました。 Windows XP、Windows Vista、または Windows Server 2008 で Internet Explorer を有効にする更新プログラムは、フラグメント化された TLS/SSL ハンドシェイクメッセージを解析するために使用できます。

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

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

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

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

SendTrustedIssuerList

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

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

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

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

既定の信頼された発行者リストの動作

Windows のバージョン 既定の動作
Windows Server 2012 と Windows 8 以降 FALSE
WindowsServer 2008 R2 および Windows 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> <major version number> を <します。<minor version number><Client\Server>

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

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

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

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0 \ クライアント

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2 \ サーバー

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\DTLS 1.2 \ クライアント

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

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

TLS 1.0 クライアントが有効

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

TLS 1.0 サーバーは既定で無効になっています

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

レジストリで DTLS 1.2 が無効になっている例を次に示します。

DTLS 1.2 が無効

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

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

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