次の方法で共有


IBackgroundCopyServerCertificateValidationCallback::ValidateServerCertificate メソッド (bits10_3.h)

HTTPS 接続が開かれたときに送信されたサーバー証明書を検証できるように呼び出される、実装するコールバック メソッド。

構文

HRESULT ValidateServerCertificate(
  IBackgroundCopyJob  *job,
  IBackgroundCopyFile *file,
  DWORD               certLength,
  const BYTE []       certData,
  DWORD               certEncodingType,
  DWORD               certStoreLength,
  const BYTE []       certStoreData
);

パラメーター

job

型: IBackgroundCopyJob*

ジョブ。

file

型: IBackgroundCopyFile*

転送されるファイル。

certLength

型: DWORD

証明書データの長さ (バイト単位)。

certData

型: const BYTE []

証明書データを格納しているバイトの配列。 バイト数は certLengthと一致する必要があります。

certEncodingType

型: DWORD

証明書のエンコードの種類。

certStoreLength

型: DWORD

証明書ストア データの長さ (バイト単位)。

certStoreData

型: const BYTE []

証明書ストア データを格納しているバイトの配列。 バイト数は certStoreLengthと一致する必要があります。

戻り値

証明書が許容可能であることを示す S_OK を返します。 それ以外の場合は、HRESULTエラー コード を返して、証明書が受け入れられないことを示します。

備考

証明書の検証は 2 つのフェーズで実行されます。 最初のフェーズは、OS が証明書に対して標準の検証チェックセットを実行するオペレーティング システム (OS) フェーズです。 その後、OS フェーズが証明書に合格すると、追加の検証を実行するためにコールバックが呼び出されます。

サーバー証明書に対して独自のチェックを実行する場合は、この検証メソッドを実装します。 独自のチェックは、通常の OS 証明書検証チェックに加えて行われます。

検証メソッドが証明書を拒否した場合、ジョブは BG_ERROR_CONTEXT_SERVER_CERTIFICATE_CALLBACK のジョブ エラー コンテキストで BG_JOB_STATE_TRANSIENT_ERROR に遷移し、HRESULT エラーがコールバックから されます。 コールバックを呼び出せなかった場合 (たとえば、プログラムの終了後に BITS がサーバー証明書を検証する必要があるため)、ジョブ エラー コードは BG_E_SERVER_CERT_VALIDATION_INTERFACE_REQUIRED。 アプリケーションが次に実行されるときに、検証コールバックをもう一度設定してジョブを再開することで、このエラーを修正できます。

BITS は、IBackgroundCopyServerCertificateValidationCallback インターフェイスを実装し、IBackgroundCopyJobHttpOptions3::SetServerCertificateValidationInterfaceに渡す場合にのみ、このコールバック メソッドを呼び出します。

アプリケーションが終了すると、検証インターフェイスが無効になります。BITS は検証インターフェイスのレコードを保持しません。 その結果、アプリケーションの初期化プロセスでは、証明書検証要求を受け取る既存のジョブ SetServerCertificateValidationInterface を呼び出す必要があります。

SetServerCertificateValidationInterface 複数のアプリケーションが呼び出してジョブの通知インターフェイスを設定する場合、最後に呼び出すアプリケーションが通知を受信します。 他のアプリケーションは通知を受け取りません。

証明書を検証する一般的な手順を次に示します。 これらの手順は単なる例であることに注意してください。 実際の検証は制御下にあります。 また、手順 5 から 7 は、OS 検証手順の間に OS が実行する操作とほとんど同じです。

  1. certEncodingTypecertData、および certLengthCertCreateCertificateContext を呼び出して、CERT_CONTEXTを取得します。

  2. certStoreLengthcertStoreDataを介して渡されたシリアル化されたメモリ BLOB を使用して、CRYPT_DATA_BLOB 構造体 (wincrypt.hで定義) を宣言して初期化します。

DATA_BLOB storeData{};
storeData.cbData = certStoreLength;
storeData.pbData = const_cast<PBYTE>(certStoreData);
  1. 手順 2 で CERT_STORE_PROV_SERIALIZED、0、nullptr、フラグ、および CRYPT_DATA_BLOB へのポインター CertOpenStore を呼び出して、証明書チェーンへのハンドルを取得します。
  2. CertGetCertificateChain を nullptr、、nullptr、手順 3 のハンドル、チェーン パラメーター、フラグ、および nullptr で呼び出して、証明書チェーン コンテキストへのポインターを取得します。
  3. 証明書検証ポリシーを作成します。
CERT_CHAIN_POLICY_PARA policyParams{};
policyParams.cbSize = sizeof(policyParams);
policyParams.dwFlags =
    CERT_CHAIN_POLICY_IGNORE_NOT_TIME_VALID_FLAG |
    CERT_CHAIN_POLICY_IGNORE_WRONG_USAGE_FLAG |
    CERT_CHAIN_POLICY_IGNORE_INVALID_NAME_FLAG |
    CERT_CHAIN_POLICY_ALLOW_UNKNOWN_CA_FLAG;
  1. ポリシー 種類、チェーン コンテキスト、ポリシー パラメーター、およびポリシーの状態を使用して CertVerifyCertificateChainPolicy を呼び出します。
  2. Win32 エラー (policyStatus.dwError) を HRESULT に変換し、返します。

BITS 検証キャッシュ動作の説明は次のとおりです。 BITS は、カスタム検証に合格した証明書のジョブごとのキャッシュを保持します。 これは、ジョブの有効期間にわたって冗長でコストの高い再検証を回避するためです。 キャッシュは、サーバー エンドポイント、証明書ハッシュ タプルで構成されます。ここで、エンドポイント は、サーバー名:ポート定義されます。 ジョブで特定のエンドポイントからの特定の証明書が既に許可されている場合、コールバックは再び呼び出されません。

もちろん、証明書は、すべての接続試行で OS 検証ロジックを通過する必要があります (IBackgroundCopyJobHttpOptions::SetSecurityFlagsを 呼び出して OS 検証ロジックをカスタマイズできます)。これは、証明書が非常に最近有効であった場合 (秒単位) など、時間の影響を受けやすいコーナー ケースに対処しますが、現在期限切れになっています。

BITS は、アプリによって提供される検証コールバックによって無効と見なされる証明書をキャッシュしません。 アプリ レベルで悪意のあるデプロイを検出できるように、失敗したすべての接続試行を認識することが重要です。 たとえば、1 回限りの無効な証明書は、同じサーバーからの何千もの無効な証明書よりもはるかに重要ではありません。

SetServerCertificateValidationInterface呼び出すたびに、ジョブの証明書キャッシュがクリアされます。これは、アプリのサーバー証明書検証ロジックが変更されたことを示しているためです。

必要条件

要件 価値
サポートされる最小クライアント Windows 10 バージョン 1809 [デスクトップ アプリのみ]
サポートされる最小サーバー Windows Server 2016 [デスクトップ アプリのみ]
ヘッダー bits10_3.h (Bits.h を含む)
ライブラリ Bits.lib
DLL Bits.dll

関連項目

IBackgroundCopyJobHttpOptions3::SetServerCertificateValidationInterface