“无法与远程服务器建立信任关系” Windows mobile .NET 设备使用 Web 服务时出现错误
我们有一个现有的证书（全局标志），当 Windows Mobile 应用程序 (.NET 3.5) 尝试使用 IIS 上托管的 Web 服务（也是用 .NET 3.5 编写）时，该证书可以正常工作。
然而，当我们使重新颁发的证书（全局签名）生效时，Windows Mobile 应用程序无法连接到 Web 服务，我们收到的错误是“无法与远程服务器建立信任关系”。我曾多次尝试在 Google 上搜索此问题，但尚未找到合适的解决方案。
我们还尝试将链中的 ROOT 和中间证书复制（并安装）到设备，但这仍然不起作用。
当我们使用 PC Web 浏览器（IE、Firefox、Opera）、使用 Web 服务的桌面应用程序 (.NET 3.5) 甚至 Windows Mobile 设备上的 Internet Explorer 测试新证书时，.NET Web 服务定义/文档页面显示没有问题（没有警告或错误），这似乎只是在使用紧凑框架 (3.5) 应用程序尝试使用 Web 服务时 Windows 移动设备上的问题。
我们已经验证了证书是否正确安装在 SSL 购物者网站上，并且在我们的 google 搜索之后，我们发现并实现了（作为测试）“信任所有”ICertificatePolicy 处理程序，这已经解决了问题，但是我希望这问题可以通过配置/设置更改来解决，而不是更改代码和重新部署 150 多个基于 Windows Mobile 的设备。
ICertificatePolicy 处理程序确实显示了尝试验证证书时返回的错误：问题参数设置为：-2146762481（十六进制中的 0x800B010F），我认为这是“CN No MATCH”错误，但是我已经搜索过其数字、十六进制和名称形式都存在，并且尚未找到除“信任所有”代码更改之外的解决方案。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想我会在这里发布答案，以防其他人遇到这个问题。我还没有找到 100% 可靠的解释，但我们已经设法让它发挥作用，这让我对这个问题提出了一个假设：
看起来紧凑的框架似乎采用了第一个通用名称（ CN）关闭了 SSL 证书的“主题名称替代”字段，并且仅根据该字段评估证书，而完整的框架、IE 和移动设备上的 IE 似乎都在使用两者。我相信这一点的理由如下：
PDA 应用程序正在访问 url：
https://AMobileWebService.com /Webservice.asmx
我们有效的旧 SSL 证书在“主题备用名称”中具有以下内容：
DNS 名称=AMobileWebService.com
DNS Name=www.AMobileWebService.com
并且无效的新证书在同一字段中包含以下内容：
DNS 名称=www.AMobileWebService.com
DNS Name=AMobileWebService.com
当我们将应用程序更改为使用 https ://www.AMobileSebService.com/Webservice.asmx，旧证书（以前有效）无法建立信任关系，而新证书有效（但以前无效）。
正如我之前提到的，这让我相信 .NET CF 仅检索 SSL 证书中的第一个名称，然后根据该名称评估 url 主机名，而不是像在完整的 .NET Framework 中那样对两者进行评估。
我们通过实施我们在 stackoverflow 上找到的“信任所有证书”解决方案得出了这个结论：
https://stackoverflow.com/questions/ 6552598/system-net-web-service-over-https 时抛出的异常
解决方法中的问题参数返回值 -2146762481。搜索该值的十六进制表示形式 (0x800B010F) 为我提供了以下信息：https://blogs.technet.microsoft.com/rrasblog/2007/09/26/how-to-debug-sstp-specific-connection-failures/
错误结果是常量： CERT_E_CN_NO_MATCH
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