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 のジョブ エラー コンテキストとコールバックからのエラー HRESULT を使用してBG_JOB_STATE_TRANSIENT_ERRORに移行します。 コールバックを呼び出せなかった場合 (たとえば、プログラムが終了した後に BITS でサーバー証明書を検証する必要が生じていました)、ジョブ エラー コードが BG_E_SERVER_CERT_VALIDATION_INTERFACE_REQUIREDされます。 アプリケーションを次に実行するときに、検証コールバックをもう一度設定してジョブを再開することで、このエラーを修正できます。
BITS は、 IBackgroundCopyServerCertificateValidationCallback インターフェイスを実装し、 IBackgroundCopyJobHttpOptions3::SetServerCertificateValidationInterface に渡す場合にのみ、このコールバック メソッドを呼び出します。
アプリケーションが終了すると、検証インターフェイスが無効になります。BITS では、検証インターフェイスのレコードは保持されません。 その結果、アプリケーションの初期化プロセスでは、証明書検証要求を受信する既存のジョブで SetServerCertificateValidationInterface を呼び出す必要があります。
複数のアプリケーションが SetServerCertificateValidationInterface を呼び出してジョブの通知インターフェイスを設定する場合、それを呼び出す最後のアプリケーションは通知を受信するアプリケーションです。 他のアプリケーションは通知を受け取りません。
証明書を検証する一般的な手順を次に示します。 これらの手順は単なる例であることに注意してください。 実際の検証は制御下にあります。 また、手順 5 から 7 は、OS 検証手順の間に OS が実行する操作とほとんど同じです。
を使用して CertCreateCertificateContext
certEncodingType
certData
を呼び出してcertLength
、CERT_CONTEXTを取得します。と を介して渡されたシリアル化されたメモリ BLOB を使用して
certStoreLength
、CRYPT_DATA_BLOB構造体 (でwincrypt.h
定義) を宣言してcertStoreData
初期化します。
DATA_BLOB storeData{};
storeData.cbData = certStoreLength;
storeData.pbData = const_cast<PBYTE>(certStoreData);
- 手順 2 のCERT_STORE_PROV_SERIALIZED、0、nullptr、フラグ、およびCRYPT_DATA_BLOBへのポインターを使用して CertOpenStore を呼び出して、証明書チェーンへのハンドルを取得します。
- 手順 3 のハンドルである nullptr、チェーン パラメーター、フラグ、
certContext
および nullptr を使用して CertGetCertificateChain を呼び出して、証明書チェーン コンテキストへのポインターを取得します。 - 証明書検証ポリシーを作成します。
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;
- ポリシーの種類、チェーン コンテキスト、ポリシー パラメーター、およびポリシーの状態を使用して CertVerifyCertificateChainPolicy を呼び出します。
- Win32 エラー (
policyStatus.dwError
) を HRESULT に変換し、返します。
BITS 検証キャッシュ動作の説明は、次のとおりです。 BITS では、カスタム検証に合格した証明書のジョブごとのキャッシュが保持されます。 これは、ジョブの有効期間にわたって冗長でコストの高い再検証を回避するためです。 キャッシュは、サーバー エンドポイントの <証明書ハッシュ> タプルで構成されます。 エンドポイント は サーバー名:ポートとして定義されます。 ジョブで特定のエンドポイントからの特定の証明書が既に許可されている場合、コールバックは再び呼び出されません。
もちろん、証明書は、すべての接続試行で OS 検証ロジックを通過する必要があります ( IBackgroundCopyJobHttpOptions::SetSecurityFlags の呼び出しを使用して OS 検証ロジックをカスタマイズできます)。これは、証明書が非常に最近有効だった場合 (秒単位) など、時間の影響を受けやすいコーナーケースに対応しますが、有効期限が切れています。
BITS では、アプリ指定の検証コールバックによって無効と見なされる証明書はキャッシュされません。 アプリ レベルで悪意のあるデプロイを検出できるように、失敗したすべての接続試行を認識しておくことが重要です。 たとえば、1 回限りの無効な証明書は、同じサーバーからの何千もの不正な証明書よりもはるかに少なくなります。
ジョブの証明書キャッシュは、アプリのサーバー証明書検証ロジックが変更されたことを示しているため、 SetServerCertificateValidationInterface の呼び出しごとにクリアされます。
要件
要件 | 値 |
---|---|
サポートされている最小のクライアント | Windows 10 Version 1809 [デスクトップ アプリのみ] |
サポートされている最小のサーバー | Windows Server 2016 [デスクトップ アプリのみ] |
Header | bits10_3.h (Bits.h を含む) |
Library | Bits.lib |
[DLL] | Bits.dll |
こちらもご覧ください
IBackgroundCopyJobHttpOptions3::SetServerCertificateValidationInterface
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示