Ошибка «Не удалось установить доверительные отношения с удаленным сервером», когда устройство Windows Mobile .NET использует веб-службу - PullRequest
5 голосов
/ 20 февраля 2012

У нас есть существующий сертификат (глобальный признак), который отлично работает, когда приложение Windows Mobile (.NET 3.5) пыталось использовать веб-службу (также написанную в .NET 3.5), размещенную на IIS.

Однако, когда мы перерабатываем переизданный сертификат (глобальный знак), приложению Windows Mobile не удается подключиться к веб-службе, мы получаем ошибку: "Не удалось установить доверительные отношения с удаленным сервером «. Я много раз пытался найти это в Google и не нашел подходящего решения.

Мы также пытались скопировать (и установить) ROOT и промежуточный сертификат в цепочке на устройство, но это все равно не работает.

Когда мы тестируем новый сертификат с помощью веб-браузера ПК (IE, Firefox, Opera), настольного приложения, которое использует веб-сервис (.NET 3.5), и даже Internet Explorer на устройстве Windows Mobile, веб-сервис .NET Страница определений / документации отображается без проблем (без предупреждений или ошибок), кажется, что проблема возникает только на устройстве Windows Mobile, когда приложение Compact Framework (3.5) пытается использовать веб-сервис.

Мы проверили, что сертификат правильно установлен на сайте покупателя SSL, и после наших поисков в Google мы столкнулись и реализовали (в качестве теста) обработчик ICertificatePolicy «доверять всем», это решило проблему, однако я был надеясь, что эта проблема может быть решена путем изменения конфигурации / настройки, а не изменения кода и повторного развертывания более 150 устройств на базе Windows Mobile.

Модуль ICertificatePolicy действительно обнаружил ошибку, которая возвращалась при попытке проверить сертификат: для параметра проблемы было задано значение: -2146762481 (0x800B010F в HEX), что, как я полагаю, является ошибкой «CN No MATCH», однако Я искал это как в числовой, так и в шестнадцатеричной форме и в форме имени, и пока не нашел решения, отличного от изменения кода «Доверять всем».

1 Ответ

7 голосов
/ 01 марта 2012

Я думал, что выложу ответ здесь, если кто-нибудь еще столкнется с этой проблемой. Я не нашел 100% надежного объяснения, но нам удалось заставить его работать, и это заставило меня выдвинуть гипотезу о проблеме:

Похоже, что компактная структура, кажется, берет первое Общее имя (CN) из поля "Альтернатива имени субъекта" сертификата SSL и оценивает сертификат только по этому, в то время как полная структура, IE и IE на мобильном устройстве, похоже, использовали оба. Мое рассуждение для веры это ниже:

Приложение для КПК получило доступ к URL:

https://AMobileWebService.com/Webservice.asmx

Наш старый сертификат SSL, который работал , имел следующее значение в "Subject Alternative Name" :
DNS-имя = AMobileWebService.com
DNS Name = www.AMobileWebService.com

И новый сертификат, который не работал, содержал следующее в том же поле:
DNS Name = www.AMobileWebService.com
DNS-имя = AMobileWebService.com

Когда мы изменили приложение на использование https://www.AMobileSebService.com/Webservice.asmx,, старый сертификат (который ранее работал) не смог установить доверительные отношения, и новый сертификат сработал (но ранее не работал).

Как я упоминал ранее, это наводит меня на мысль, что .NET CF только извлекает имя из сертификата SSL и затем сравнивает с ним имя хоста url, а не сравнивает их с обоими, как в полной версии .NET Framework. .

Мы пришли к такому выводу, реализовав обход «доверяй всем сертификатам», который мы нашли в stackoverflow: /6354288/isklychenie-system-net-webexception-pri-ispolzovanii-veb-sluzhby-po-protokolu-https

Параметр проблемы на обходном пути возвращал значение -2146762481 . Поиск в шестнадцатеричном представлении значения ( 0x800B010F ) показал мне следующую информацию: https://blogs.technet.microsoft.com/rrasblog/2007/09/26/how-to-debug-sstp-specific-connection-failures/

Ошибка оказалась постоянной: CERT_E_CN_NO_MATCH

...