Schannel SSP の技術概要

公開日: 2016年8月

対象: Windows Vista、Windows Server 2008、Windows 7、Windows 8.1、Windows Server 2008 R2、Windows Server 2012 R2、Windows Server 2012、Windows 8

この IT プロフェッショナル向けのリファレンス トピックでは、Secure Channel (Schannel) セキュリティ サポート プロバイダー (SSP) の機能と、SSP がトランスポート層セキュリティ (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルを使用して提供する認証サービスについて説明します。

このトピックには、次のセクションが含まれています。

• TLS、SSL、Schannel の機能

• 一般的な TLS と SSL のシナリオ

• Schannel SSP Technical Overview

• TLS と SSL の依存関係

TLS、SSL、Schannel の機能

ネットワークを管理する際に対応する問題の 1 つとして、アプリケーション間で信頼できないネットワークを経由して送信されるデータのセキュリティを確保することが挙げられます。 TLS/SSL を使えば、サーバーとクライアント コンピューターを認証できるだけでなく、認証される当事者間のメッセージを暗号化できます。

TLS プロトコル、SSL プロトコル、DTLS プロトコル、および Private Communications Transport (PCT) プロトコルは、公開キーの暗号化に基づいています。 Schannel 認証プロトコル スイートは、これらのプロトコルを備えています。 すべての Schannel プロトコルでは、クライアント/サーバー モデルが使用されています。 サポートされているプロトコルの一覧については、「サポートされる暗号スイートおよび Schannel SSP のプロトコル」を参照してください。

認証プロセスでは、TLS/SSL クライアント コンピューターが TLS/SSL サーバーにメッセージを送信すると、サーバーが応答してそのサーバー自体を認証するための適切な情報を返します。 クライアントとサーバーは、さらにセッション キーの交換を実行し、認証のやり取りが終了します。 認証が完了すると、サーバーとクライアントの間で SSL 通信を開始できるようになります。その際、認証プロセス中に確立されている対称暗号化キーが使用されます。

サーバーがクライアントに対して認証される場合、TLS/SSL はドメイン コントローラーや、Active Directory ドメイン サービスなどのデータベース内にサーバーのキーを格納する必要はありません。 クライアントが、信頼されたルート証明機関 (CA) 証明書を使用してサーバーの資格情報が有効かどうかを確認します。この証明書は、Windows Server オペレーティング システムをインストールするときに読み込まれます。 そのため、サーバーによるユーザー認証が不要な場合、ユーザーは、サーバーとのセキュリティで保護された接続を作成するためにアカウントを確立する必要はありません。

TLS と SSL の歴史と標準化

SSL は、World Wide Web 経由でのトランザクションをセキュリティで保護する目的で、1994 年に Netscape Communications Corporation によって開発されました。 その後間もなく、インターネット技術標準化委員会 (IETF) が、同じ機能を提供する標準のプロトコルの開発に着手します。 この委員会が開発の基礎として使用したのは SSL 3.0 で、これが TLS プロトコルへと進化しました。 Windows Server 2003 から開始された TLS プロトコルの実装は、IETF RFC データベースに登録されている以下の仕様で定義された仕様に厳密に従っています。

• RFC 2246 - TLS プロトコル バージョン 1.0

• RFC 4346 - トランスポート層セキュリティ (TLS) プロトコル バージョン 1.1

• RFC 5246 - トランスポート層セキュリティ (TLS) プロトコル バージョン 1.2

TLS と SSL は、Web ブラウザーと Web サーバーの間でのインターネット トランザクションにセキュリティで保護された HTTP (HTTPS) を提供するプロトコルとして、最も広く認められています。 TLS/SSL は、ファイル転送プロトコル (FTP)、ライトウェイト ディレクトリ アクセス プロトコル (LDAP)、簡易メール転送プロトコル (SMTP) など、その他のアプリケーション レベルのプロトコルでも使用できます。 TLS/SSL では、World Wide Web などのネットワーク上で、サーバー認証、クライアント認証、データの暗号化、およびデータの整合性確保を実現します。

TLS と SSL との違い

SSL 3.0 と各バージョンの TLS との間には、わずかな違いはありますが、このリファレンス ガイドでは、このプロトコルを TLS/SSL と呼びます。

SSL は増大するセキュリティへの攻撃に対して脆弱であったため、IETF は、インターネット標準となる安全性の高いプロトコルを開発しました。それが、TLS です。 次の一覧では、TLS の機能強化について説明します。この機能強化は、信頼されていないネットワークでの通信をセキュリティで保護する SSL の機能を高めています。

• SSL メッセージ認証コード (MAC) アルゴリズムに代わってキー付きハッシュ メッセージ認証コード (HMAC) アルゴリズムを採用しています。

• TLS は標準化され、インターネット標準になっています。一方 SSL にはさまざまなバリエーションがあります。

• TLS には、追加の警告メッセージが備わっています。

• SSL にはルート CA によって発行された (またはルート CA にチェーンされた) 証明書が必要です。 TLS を使用する場合は、必ずしもルート CA にチェーンされた証明書を含める必要はありません。 中間証明機関を使用できます。

• Fortezza アルゴリズムは、パブリック レビューの対象になっていないため、TLS の RFC には含まれません。

TLS と SSL の利点

TLS/SSL は、他のクライアントとサーバーの認証方法に比べて、数多くの利点があります。 以下の表では、その利点について説明します。

TLS と SSL の制限事項

次の表で説明するように、TLS/SSL の使用には 2 つの制限があります。

一般的な TLS と SSL のシナリオ

一般的には、TLS/SSL はインターネットをより安全に閲覧するために Web ブラウザーで使用するプロトコルであると考えられています。 その一方で TLS/SSL は、認証とデータの保護が必要なあらゆる場面に使用できる汎用プロトコルでもあります。 実際に、セキュリティ サービス プロバイダー インターフェイス (SSPI) を使用してこのプロトコルにアクセスできるため、ほぼすべてのアプリケーションで使用できます。 TLS/SSL の機能を活用できるよう変更が進められているアプリケーションは、数多くあります。 次の表では、TLS/SSL の使用方法の例を示します。

Schannel SSP のアーキテクチャ

Windows Server オペレーティング システムでは、Schannel 認証プロトコル スイートに TLS が含まれています。 次の図は、これらおよびその他のテクノロジのどの部分に Schannel SSP が適合するのかを示しています。 クライアント アプリケーションまたはサーバー アプリケーションは、Secur32.dll を使用し、SSPI 呼び出しを介してローカル セキュリティ機関サブシステム サービス (LSASS) と通信します。

Schannel SSP のアーキテクチャ

次の表では、TLS/SSL に関与する要素の説明を一覧で示します。

TLS と SSL の認証で使用されるセキュリティ サブシステムの要素

この認証プロトコル スイートは、Schannel SSP によって実現しています。その Schannel SSP は、Windows Server オペレーティング システムにセキュリティ サービスを提供する SSPI アプリケーション プログラミング インターフェイス (API) によって支えられています。

Microsoft セキュリティ サポート プロバイダー インターフェイス (SSPI) は、Windows オペレーティング システムにおける認証の基盤です。 つまり、認証を必要とするアプリケーション サービスとインフラストラクチャ サービスは、SSPI を使用して認証を提供します。 クライアントとサーバー間の通信の安全性を高めるために、クライアントとサーバーを認証する必要がある場合は、現在使用中のネットワーク プロトコルに関係なく、認証の要求が SSPI にルーティングされ、SSPI が認証処理を完了します。 SSPI は、Generic Security Service API (GSSAPI) の実装です。 GSSAPI の詳細については、IETF RFC データベースの次の RFC を参照してください。

• RFC 2743

• RFC 2744

すべての SSP 向けの SSPI のアーキテクチャと、Kerberos プロバイダーがこのアーキテクチャに適合するしくみについては、「Security Support Provider Interface Architecture」を参照してください。

電子メールや Web ページで提供されている個人情報などの Web 対応サービスにアクセスするために、Schannel SSP を使用できます。 Schannel SSP では、公開キー証明書を使用して利用者を認証します。 Schannel SSP は、スイートとして 4 つの認証プロトコルを備えています。 利用者を認証するときに、Schannel SSP は、次の優先順位に従って 4 つのプロトコルから 1 つを選択します。

1. TLS バージョン 1.2

2. TLS バージョン 1.1

3. TLS バージョン 1.0

4. SSL バージョン 3.0

Schannel SSP は、クライアントとサーバーがサポートできる最も優先順位の高い認証プロトコルを選択します。 たとえば、サーバーが 4 つの Schannel プロトコルをすべてサポートしていて、クライアント コンピューターが SSL 3.0 しかサポートしていない場合は、Schannel プロバイダーは認証に SSL 3.0 を使用します。

クライアント認証のための信頼された発行者の管理

Windows Server 2012 および Windows 8 以前では、Schannel SSP (HTTP.sys と IIS を含む) を使用するアプリケーションまたはプロセスは、クライアント認証のためにサポートしている信頼された発行者の一覧を提供することができました。 この情報は、証明書信頼リスト (CTL) を介して提供されました。

SSL または TLS を使用したクライアント コンピューターの認証が必要な場合は、信頼された証明書の発行者の一覧を送信するようにサーバーを構成できます。 この一覧には、サーバーが信頼する証明書発行者のセットが含まれます。これが、複数の証明書が存在する場合にクライアント コンピューターがどのクライアント証明書を選択するかについてのヒントとなります。 さらに、構成されている信頼された発行者の一覧に対して、クライアント コンピューターがサーバーに送信する証明書チェーンを検証する必要があります。

Windows Server 2012 および Windows 8 では、基になる認証プロセスに変更が加えられ、次のようになりました。

1. CTL ベースの信頼された発行者の一覧の管理はサポートされなくなりました。

2. 信頼された発行者の一覧を送信する動作は既定でオフに設定されます。 SendTrustedIssuerList レジストリ キーの既定値は、1 ではなく 0 です (既定でオフ)。

3. 以前のバージョンの Windows オペレーティング システムとの互換性は維持されます。

これにより、Windows PowerShell プロバイダーの既存の証明書管理コマンドレットや certutil.exe などのコマンドライン ツールを使用して、管理がしやすくなりました。 Schannel SSP でサポートされる信頼された証明機関の一覧の最大サイズ (16 KB) は Windows Server 2008 R2 の場合と同じですが、Windows Server 2012 ではクライアント認証の発行者のための新しい専用の証明書ストアが用意されるため、関係のない証明書はクライアント/サーバー メッセージに含まれません。

しくみ

信頼された発行者の一覧は証明書ストアを使用して構成されます。その 1 つは既定のグローバル コンピューターの証明書ストア、もう 1 つはサイトごとにオプションの証明書ストアです。 一覧のソースは、次のように決定されます。

• サイトに対して特定の資格情報ストアが構成されている場合は、それがソースとして使用されます。

• アプリケーションで定義されたストアに証明書が存在しない場合、Schannel により、ローカル コンピューター上のクライアント認証の発行者ストアが調べられます。 証明書が存在する場合は、Schannel はソースとしてそのストアを使用します。

• グローバル ストアとローカル ストアのどちらにも証明書が含まれていない場合、Schannel SSP は、信頼されたルート証明書機関ストアを信頼された発行者の一覧のソースとして使用します (これは、Windows Server 2008 R2 でも同じ動作です)。

可能性の高い証明書の発行者名の一覧を構築して、証明書を選択する際のヒントをエンド ユーザーに提供できます。 この一覧は、グループ ポリシーを使って構成できます。

信頼されたルート証明書機関ストアにルート (自己署名) と証明機関 (CA) の両方の発行者証明書が含まれている場合、既定で CA 発行者証明書のみがサーバーに送信されます。

信頼された発行者の証明書ストアを使用するように Schannel を構成する方法

Schannel SSP では、前に説明したように、既定でストアを使用して、信頼された発行者の一覧を管理します。 引き続き Windows PowerShell プロバイダーの既存の証明書管理コマンドレットや certutil.exe などのコマンドライン ツールを使用して、証明書を管理できます。

Windows PowerShell プロバイダーを使用して証明書を管理する方法の詳細については、Windows での AD CS 管理コマンドレットに関するページを参照してください。

証明書ユーティリティを使用して証明書を管理する方法の詳細については、certutil.exe に関するページを参照してください。

Schannel の資格情報について定義されるデータ (アプリケーションによって定義されるストアを含む) の詳細については、SCHANNEL_CRED 構造 (Windows) に関するページを参照してください。

クライアント認証の発行者ストアを使用するためのアプリケーションまたは機能の構成

一部のテクノロジは、既定では、クライアント認証の発行者ストアを使用しません。 このような場合に、ストアを使用するようテクノロジを構成する必要があります。

たとえば、Web サーバーの場合、Windows HTTP サーバー スタックを実装する HTTP.sys は、既定ではクライアント認証の発行者のストアを使用するよう構成されていません。

クライアント認証の発行者のストアを使用するよう HTTP.sys を構成するには、次のコマンドを使用できます。

netsh http add sslcert ipport=0.0.0.0:443 certhash=GUID hash value appid={GUID application identifier}  sslctlstorename=ClientAuthIssuer

サーバー上の certhash と appid の値を検索するには、次のコマンドを使用できます。

netsh http show sslcert

信頼モードの既定値

Schannel SSP では、3 種類のクライアント認証信頼モードがサポートされます。 信頼モードは、クライアントの証明書チェーンの検証を実行する方法を制御します。 信頼モードは、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel の下にある REG_DWORD "ClientAuthTrustMode" によって制御されるシステム全体の設定です。

信頼された発行者の一覧の構成の問題が原因で発生する認証エラーの詳細については、Microsoft サポート技術情報の記事 280256 を参照してください。

TLS と SSL の依存関係

TLS と SSL は、適切に機能するために、いくつかの関連するテクノロジとリソースを使用します。 次の表では、これらのテクノロジおよびリソースについて説明し、どのように TLS/SSL 認証と関連するかについて要約しています。

関連項目

Schannel セキュリティ サポート プロバイダーのテクニカル リファレンス