Błąd "Nie można ustalić relacji zaufania ze zdalnym serwerem", gdy mobilne urządzenie z systemem Windows Mobile korzystające z usługi internetowej

Question

Mamy istniejący certyfikat (znak globalny), który działa poprawnie, gdy aplikacja Windows Mobile (.NET 3.5) próbowała skonsumować sieć usługa (również napisana w .NET 3.5) obsługiwana w IIS.

Jednak kiedy wydajemy ponownie wydany certyfikat (znak globalny) na żywo, aplikacja Windows Mobile nie łączy się z serwisem internetowym, otrzymujemy błąd: "Nie można ustanowić relacji zaufania ze zdalnym serwerem". Próbowałem wyszukiwać to w Google wiele razy i nie znalazłem odpowiedniej poprawki.

Próbowaliśmy również skopiować (i zainstalować) certyfikat ROOT i certyfikat pośredni w łańcuchu na urządzenie, ale to nadal nie działa.

Podczas testowania nowego certyfikatu za pomocą przeglądarki internetowej komputera (IE, Firefox, Opera), aplikacji komputerowej, która pobiera usługę sieciową (.NET 3.5), a nawet Internet Explorera na urządzeniu z systemem Windows Mobile, sieci .NET strona z definicjami usług/dokumentacja jest wyświetlana bez problemów (bez ostrzeżeń i błędów), wydaje się, że problem dotyczy tylko urządzenia mobilnego z systemem Windows, gdy korzystanie z aplikacji Compact Framework (3.5) próbuje korzystać z usługi WWW.

Potwierdziliśmy, że certyfikat jest poprawnie zainstalowany na stronie klienta korzystającego z protokołu SSL, a po naszych wyszukiwaniach Google natknęliśmy się i wdrożyliśmy (jako test) program obsługi "zaufaj wszystkim" ICertificatePolicy, to rozwiązało problem, jednak miał nadzieję, że problem ten można rozwiązać poprzez zmianę konfiguracji/konfiguracji, a nie zmianę kodu i ponowne wdrożenie ponad 150 urządzeń mobilnych z systemem Windows.

Osoba obsługująca ICertificatePolicy pokazała błąd, który był zwracany podczas próby sprawdzenia poprawności certyfikatu: parametr problemu został ustawiony na: -2146762481 (0x800B010F w HEX), co moim zdaniem jest błędem "CN No MATCH", jednakże Ive szukał tego zarówno w postaci liczbowej, heksadecymalnej, jak i nazwy, i jeszcze nie znalazł rozwiązania innego niż zmiana kodu "Zaufaj wszystkim".

Answer 1

Pomyślałem, że zamieściłbym tutaj odpowiedź na wypadek, gdyby ktoś inny wpadł na ten problem. Nie znalazłem w 100% wyjaśnień na temat bryły skalnej, ale udało nam się sprawić, że zadziałało, a to doprowadziło mnie do sformułowania hipotezy dotyczącej problemu:

Wydaje się, że kompaktowa struktura wydaje się pierwsza nazwa zwyczajowa (CN) z pola "Alternatywa nazwy podmiotu" pole certyfikatu SSL i wyłącznie ocena certyfikatu przeciwko temu, podczas gdy cała struktura, IE i IE na urządzeniu mobilnym zdają się używać obu. Moje rozumowanie, by sądzić, to jest poniżej:

Aplikacja PDA został dostęp do adresu URL:

https://AMobileWebService.com/Webservice.asmx

Nasz stary certyfikat SSL, który pracował miały następujące w "Subject Alternative Name":
Nazwa DNS = AMobileWebService.com
DNS Nam e = www.AMobileWebService.com

A nowy certyfikat, który nie praca została zawarta następujące w tym samym polu:
DNS Name = www.AMobileWebService.com
Nazwa DNS = AMobileWebService.com

Kiedy zmienił wniosek do korzystania https://www.AMobileSebService.com/Webservice.asmx, stary certyfikat (który był poprzednio pracujących) nie udało się ustanowić relacji zaufania, a nowy certyfikat pracował (ale wcześniej nie).

Jak już wspomniałem wcześniej, prowadzi to mnie do przekonania, że ​​.NET CF pobiera tylko imię w certyfikacie SSL, a następnie ocenia nazwę hosta URL pod kątem tego, zamiast robić to na obu, jak w pełnym .NET Struktura.

Doszliśmy do tego wniosku przez wdrożenie „Trust wszystkie certyfikaty” obejść, że znaleźliśmy na stackoverflow: https://stackoverflow.com/questions/6552598/system-net-webexception-thrown-when-consuming-a-web-service-over-https

Parametr problem na obejście wracał wartość -2146762481. Wyszukiwanie w reprezentacji hex wartości (0x800B010F) wskazał mi do następujących informacji: https://blogs.technet.microsoft.com/rrasblog/2007/09/26/how-to-debug-sstp-specific-connection-failures/

Błąd okazał się stała: CERT_E_CN_NO_MATCH