TIdSSLIOHandlerSocketOpenSSL コンポーネントの OnVerifyPeer イベントのイベント ハンドラーを実装する必要があります。
IdSSLOpenSSL.pas から:
常に OnVerifyPeer を実装する必要があることに注意してください。そうしないと、接続先のピアの証明書が有効であることを確認するためにチェックされません。
ライブラリが有効と見なすのと同じ証明書を有効と見なしたい場合は、次のように実装するだけです。
function TForm1.IdSSLIOHandlerSocketOpenSSL1VerifyPeer(Certificate: TIdX509;
AOk: Boolean; ADepth, AError: Integer): Boolean;
begin
Result := AOk;
end;
Indy は最初に証明書の有効性をチェックし、それが OK かどうかを AOK パラメータに渡します。最後の単語はコードにあります。古いものなど、いくつかの種類のマイナーな検証エラーを通過させたり、エラーが発生した場合に証明書が受け入れられたかどうかをユーザーに尋ねたりすることもできます (マイナーかどうか)。 .
このように動作する理由を理解するには、IdSSLOpenSSL.pas ファイルの上部にあるすべてのコメントを読むこともできます。
{
OnVerifyPeer に関する重要な情報: 2005 年 2 月の Rev 1.39 は、(明らかに?) SSL ネゴシエーションの一部としてそのコールバックを実装したプログラムにのみ影響する OnVerifyPeer インターフェイスを故意に破壊しました。常に OnVerifyPeer を実装する必要があることに注意してください。そうしないと、接続先のピアの証明書が有効であることを確認するためにチェックされません。
これ以前は、SSL ライブラリが証明書の問題を検出した場合、または深さが不十分であった場合 (つまり、VerifyCallback の「Ok」パラメーターが 0 / FALSE である場合)、OnVerifyPeer が True または False を返したかどうかに関係なく、SSL 接続は意図的に失敗しました。
これにより、チェーン内の証明書の 1 つに非常に小さな問題 (OnVerifyPeer が証明書チェーン内の証明書ごとに 1 回呼び出される) があったとしても、ユーザーが喜んで受け入れる可能性があるという問題が生じました。失敗します。ただし、ユーザーが OnVerifyPeer に対して True を返したときに SSL 接続を許可するようにコードを変更すると、無効な証明書の自動拒否に依存する既存のコードが無効な証明書を受け入れることになり、これは容認できないセキュリティ変更でした。
その結果、OnVerifyPeer は、AOk パラメーターを追加することで既存のコードを故意に壊すように変更されました。以前の機能を保持するには、OnVerifyPeer イベントで "Result := AOk;" を実行する必要があります。SSL ライブラリが無効と見なした証明書を受け入れることを検討したい場合は、OnVerifyPeer で、証明書が本当に有効であることを確認してから、Result を True に設定してください。実際には、AOk の確認に加えて、(少なくとも自分の観点から) 有効な証明書のみを受け入れるようにするコードを常に実装する必要があります。
キアラン・コステロ、 ccostelloe[_a_t_]flogas.ie
}
{
RLebeau 2011 年 1 月 12 日: OnVerifyPeer イベントを再度中断します。今回は AError パラメータを追加します ("jvlad" の厚意によるパッチ、dmda@yandex.ru)。これは、ユーザー コードが自己署名証明書と無効な証明書を区別するのに役立ちます。
}