Most commercial 3rd party web-services are now implementing SSL (secure sockets layer) to encrypt data sent via A2A (application-to-application). (The interop examples I’ve been using thus far have all required SSL). Whenever this protocol is used, some initial checks take place to ensure that the machine certificates are valid at either end of the communications channel.
 
Ordinarily, if your server copy of windows is genuine and you haven’t tinkered with any of the standard machine settings (i.e. system date) then the validation should work and the two systems will handshake just fine.
 
There are situations, however, when things go wrong both in production and development code. The “Contosso” VM’s are released with a standard 90 day server licence expiration date and I always end-up downloading extra evaluation software (into them) which often doesn’t get evaluated when it needs to or I simply need to go back and reset the VM system date in order to review an old demo. (I’m sure this is not an uncommon scenario for many busy developers!) In situations like this any attempt to use SSL fails with certification problems and it can be a very confusing time, especially when you are sure that your demo “used-to-work”.
 
Some 3rd party services also allow their certificate renewals to lapse and when you manually navigate to the web-service (using a browser) you’ll see a security warning pop-up saying there is a problem with the sites security certificate (security certificate has expired or is not yet valid). For server code this manifests as an exception:
 
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
 

·         Best-practice dictates that you should allow these exceptions to occur and stop communication with the 3rd party until the certificate is valid again, however, in reality this often holds up business.

 
In order to workaround this; add the following to the top of your code stack (before you make the first call to the service). The following code adds a delegate to the validation callback event and therefore should only execute once (do not place this code into a loop):
 
// bypass certificate verification for SSL requests
System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate(object sender,
                         System.Security.Cryptography.X509Certificates.X509Certificate certificate,
                         System.Security.Cryptography.X509Certificates.X509Chain chain,
                         System.Net.Security.SslPolicyErrors sslPolicyErrors) { return true; };
 
 
This overrides the certificate validation process and returns a “true” regardless of the outcome. Strictly speaking this is should not be done in production code unless a notification method is in place to alert an administrator of the failing condition.
 
More information about the server validation callback property can be found here [http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.servercertificatevalidationcallback.aspx]
 
 
REGARDS