i faced this issue recently and hope it helps someone…so here we go:

a service provider gave me a XML Webservice to consume. this service was SSL secured and they gave us the certificate to install. However, they did not give us the CA…lets move on.

i created a .net console app to test the web service and of course i had to write the code to ignore the certificate warning since again i did not have the CA. now do not judge me just yet 🙂 instantly i mailed the web service owner asking for the CA; but it took some time…

so meanwhile, my console app worked just fine. now i went to my main ASP.NET application and used the same code to invoke the web service…and there was a big problem: the first call took forever (more like 30 seconds really), then the subsequent calls were fast until my application is restarted!
now since the console application worked just fine (first call was fast) but the problem was only in the ASP.NET application i moved my attention immediately to the serialzation issue.

i read alot about how the serializer dll might take time to load the first time and thus the first call was slow. Now although this does not really explain why the problem occured only when calling the web service from my IIS hosted web site; however, i still used the SGen tool to pre-generate the serializer assembly in the form of [myproxyassemblyname].XmlSerializers.dll and put it inside my bin folder but without any result…still the first call was too slow.

Note: instead of using the SGen tool you can use the compile options from VS and turn on the generate serialzer assembly option which will create the serialzer dll for you…

now out of no where, the service provider sent my the CA. i installed it in the trusted root certificate authorities folder, removed the warning-ignoring code and boom the first call was fast and the problem was solved!
thinking about it, the SSL handshake on the first call was taking a lot of time to find a problem in the CA and generating a warning.

i have to admit though, it was a by chance. because till this moment i do not know why the console app did not complain about the SSL handshake (or to be more accurate, the SSL handshake did not take much time) while when from IIS the SSL handshake took about 30 seconds…the first logical explanation – although do not quote me on this – is that the IIS worker process was much slower than the .NET managed assembly (console app) in dealing with the SSL handshake issues…

anyway, i can live with this for now 🙂