Forum Moderators: open
Affiliates develop a web interface to the merchants test system & perform a set of read/writes for developer acceptance. This part I have working fine.
Next I apply for SSL client certificate for my web app and wsdl for the live system. Merchant emails SSL certificate and password and copy of WSDL files for live system. I install SSL in trusted authorities, hook the app up to the new wsdl file and connect my app – now I get an SSL transport error, the connection is closed.
Even when I try to reach the API using IE with my client cert installed locally to export the server cert it refuses the connection. I was however able to obtain the server cert using an old Fire Fox browser, which also refused to connect but was at least decent enough to allow me to download and export the server public certificate. I have installed this in the trusted authorities but still no good.
It seems it’s a problem with the Microsoft SSL stack (used by both IE and .Net) - connecting via the Java stack with SoapUI works fine.
As far as I can see the problem is that the server certificate isn’t trusted by the Microsoft SSL stack, presumably because it’s not from a trusted root authority such as Verisign, and so authentication is failing.
Whats the way to explicitly trust this using .NET ? Any ideas appreciated.
[forums.iis.net...]
This one isnt going to be fixed. I have explicity set the certifcate on the call like this:
objService.ClientCertificates.Add(new System.Security.Cryptography.X509Certificates.X509Certificate(@"c:\myWebServiceCert.pfx", "c6740911m2008$"));
But it still fails. It seems M$ are correctly implementing the RFC in refusing to allow authentication to take place this way because the cert is self signed, so we are re-writing in Java which is less secure, as the merchant cannot make the switch verisign because of annual costs of all the client certs.
Check it here:
[microsoft.com...]
