SslStream.AuthenticateAsClient is slow (calling the RemoteCertificateValidationCallback)

21 Dec 2006 2:24 PM

davidkclark

Hello,

I have a very simple SslStream interaction with another vendor's server
software. Their certificate is self signed so I have implemented a
RemoteCertificateValidationCallback to ignore the error that this
generates.

In testing, the call to AuthenticateAsClient takes about 400ms (ie my
code in the callback has control about 400ms after the call to
authenticate). However in production there is often (4 out of 5 times)
a delay of 15s. (The other one time the delay is a fairly regular 400
or 500ms) The server is running on the same machine as the client, same
network interface, there does not appear to be any outgoing network
traffic during this phase.

Has anyone seen this before? Does anyone have any idea what might cause
this? Two of the test machines (where it works in less than 1s) are
exactly the same hardware as the production machine.

Other ideas for how to get a finer grained debugging on what is going
on in those 15s would also be useful.

Thanks.

21 Dec 2006 7:18 PM

Dominick Baier

This may be related to some CRL checking that is done....

You can turn on tracing for SslStream - this may give you more pointers

http://www.leastprivilege.com/TracingSystemNet.aspx

-----
Dominick Baier (http://www.leastprivilege.com)

Show quoteHide quote

> Hello,
>
> I have a very simple SslStream interaction with another vendor's
> server software. Their certificate is self signed so I have
> implemented a RemoteCertificateValidationCallback to ignore the error
> that this generates.
>
> In testing, the call to AuthenticateAsClient takes about 400ms (ie my
> code in the callback has control about 400ms after the call to
> authenticate). However in production there is often (4 out of 5 times)
> a delay of 15s. (The other one time the delay is a fairly regular 400
> or 500ms) The server is running on the same machine as the client,
> same network interface, there does not appear to be any outgoing
> network traffic during this phase.
>
> Has anyone seen this before? Does anyone have any idea what might
> cause this? Two of the test machines (where it works in less than 1s)
> are exactly the same hardware as the production machine.
>
> Other ideas for how to get a finer grained debugging on what is going
> on in those 15s would also be useful.
>
> Thanks.
>