We have an existing certificate (global sign) that works fine when a Windows Mobile application (.NET 3.5) tried to consume the web service (also written in .NET 3.5) that is hosted on IIS.
However the when we make the re-issued certificate (global sign) live, the Windows Mobile application is failing to connect to the web service, the error we are getting is “Could not establish trust relationship with remote server”. Ive tried searching for this on Google many times and have not found a suitable fix.
We have also tried to copy (and install) the ROOT and intermediate certificate in the chain to the device, but this still does not work.
When we test the new certificate with a PC web browser (IE, Firefox, Opera), a Desktop application that consumes the web service (.NET 3.5), and even Internet Explorer on the Windows Mobile device the .NET web service definitions/documentation page is show without problems (no warnings, or errors), it seems to only be an issue on the windows mobile device when using a compact framework (3.5) application is trying to consume the web service.
We have validated that the certificate is installed correctly on the SSL shopper site, and after our google searches we came across and implemented (as a test) a “trust all” ICertificatePolicy handler, this has resolved the problem, however i was hoping that this problem could be addressed by configuration/setup change rather than a code change and a re-deployment of over 150 windows mobile based devices.
The ICertificatePolicy hander did show up the error that was being returned when trying to validate the certificate: the problem parameter was set to: -2146762481 (0x800B010F in HEX), which i believe is the “CN No MATCH” error, however Ive searched for this in both its numeric, hex and name form and have yet to find a resolution other than the “Trust all” code change.
I thought I would post the answer here in case anyone else runs in to this problem. I’ve not found a 100% rock solid explanation, but we have managed to make it work and this has made me come up with a hypothesis as to the problem:
It appears that the compact framework seems to be taking the first Common Name (CN) off the “Subject Name Alternative” field of the SSL certificate and only evaluating the certificate against that whilst the full framework, IE and IE on the mobile device seemed to be using both. My reasoning for believing this is below:
The PDA application was accessing the url:
https://AMobileWebService.com/Webservice.asmx
Our old SSL certificate that worked had the following in the “Subject Alternative Name”:
DNS Name=AMobileWebService.com
DNS Name=www.AMobileWebService.com
And the new certificate that did not work was contained the following in the same field:
DNS Name=www.AMobileWebService.com
DNS Name=AMobileWebService.com
When we changed the application to use https://www.AMobileSebService.com/Webservice.asmx, the old certificate (that was previously working) failed to establish a trusted relationship, and the new certificate worked (but previously did not).
As I mentioned earlier this leads me to believe that the .NET CF is only retrieving the first name in the SSL certificate and then evaluating the url host name against that, rather than doing it against both as in the full .NET Framework.
We came to this conclusion by implementing a “trust all certificates” work around that we found on stackoverflow:
https://stackoverflow.com/questions/6552598/system-net-webexception-thrown-when-consuming-a-web-service-over-https
The problem parameter on the workaround was returning the value -2146762481. Searching on hex representation of the value (0x800B010F) pointed me to the following information: https://blogs.technet.microsoft.com/rrasblog/2007/09/26/how-to-debug-sstp-specific-connection-failures/
The error turned out to be the constant : CERT_E_CN_NO_MATCH