'Kunne ikke etablere tillidsforhold med fjernserver' -fejl, når Windows Mobile .NET-enhed bruger en webservice

Indlæg af Hanne Mølgaard Plasc

Problem



Vi har et eksisterende certifikat (globalt tegn), der fungerer fint, når en Windows Mobile-applikation (.NET 3.5) forsøgte at forbruge webtjenesten (også skrevet i .NET 3.5), der er hostet på IIS.


Men når vi laver det genudstedte certifikat (globalt tegn) live, fejler Windows Mobile-applikationen ikke at oprette forbindelse til webtjenesten. Den fejl, vi får, er 'Kunne ikke etablere tillidsforhold til fjernserver' . Ive forsøgte at søge efter dette på Google mange gange og har ikke fundet en passende løsning.


Vi har også forsøgt at kopiere (og installere) ROOT- og mellemcertifikatet i kæden til enheden, men det virker stadig ikke.


Når vi tester det nye certifikat med en pc-webbrowser (IE, Firefox, Opera), et desktop-program, der bruger webtjenesten (.NET 3.5) og endda Internet Explorer på Windows Mobile-enheden .NET webservice definitioner/dokumentation siden vises uden problemer (ingen advarsler eller fejl) synes det kun at være et problem på Windows-mobilenheden, når du bruger en kompakt ramme (3.5), forsøger programmet at forbruge webtjenesten.


Vi har valideret, at certifikatet er installeret korrekt på SSL shopper-webstedet, og efter vores google-søgninger kom vi på tværs og implementerede (som en test) en 'trust all' ICertificatePolicy-handler, dette har løst problemet, men jeg håbede, at dette Problemet kunne løses ved konfigurations-/opsætningsændring snarere end en kodeændring og en genudnyttelse af over 150 Windows-mobilbaserede enheder.


ICertificatePolicy-handeren viste fejlen, der blev returneret, da man forsøgte at validere certifikatet: Problemparameteren blev indstillet til: -2146762481 (0x800B010F i HEX), som jeg mener er 'CN No MATCH' -fejlen, men Ive søgte efter dette i både sin numeriske, hex og navneformular og har endnu ikke fundet en anden opløsning end 'Trust All' -kodeændringen.

Bedste reference


Jeg troede, jeg ville sende svaret her, hvis nogen andre løber ind på dette problem. Jeg har ikke fundet en 100\% rock solid forklaring, men vi har formået at få det til at fungere, og det har fået mig til at komme med en hypotese om problemet:


Det ser ud til, at den kompakte ramme synes at være at tage det første Common Name (CN) ud af feltet 'Subject Name Alternative' i SSL-certifikatet og kun evaluere certifikatet mod det, mens den fulde ramme, IE og IE på mobilenheden syntes at bruge begge dele. Min begrundelse for at tro på dette er nedenfor:


PDA-applikationen fik adgang til url:


https://AMobileWebService.com/Webservice.asmx [1]


Vores gamle SSL-certifikat, som arbejdede , havde følgende i 'Emne Alternativt Navn' :

DNS navn=AMobileWebService.com

DNS-navn=www.AMobileWebService.com


Og det nye certifikat, der ikke fungerede, indeholdt følgende i samme felt:

DNS-navn=www.AMobileWebService.com

DNS-navn=AMobileWebService.com


Da vi ændrede applikationen til at bruge https://www.AMobileSebService.com/Webservice.asmx , lykkedes det gamle certifikat (der tidligere fungerede) ikke at etablere et betroet forhold, og det nye certifikat fungerede ( men tidligere ikke). [2]


Som jeg nævnte tidligere, fører det mig til at tro, at .NET CF kun henter fornavnet i SSL-certifikatet og derefter evaluerer url-værtsnavnet mod det, i stedet for at gøre det mod både som i hele .NET Framework.


Vi kom til denne konklusion ved at gennemføre en 'trust all certificates' arbejde rundt, vi fandt på stackoverflow:
https://stackoverflow.com/questions/6552598/system-net-webexception-thrown-when-consuming-a-web-service-over-https



Problemparameteren i løbet af løsningen returnerede værdien -2146762481 . Søgning på hex-repræsentation af værdien ( 0x800B010F ) pegede mig på følgende oplysninger: https://blogs.technet.microsoft.com/rrasblog/2007/09/26/how-to-debug- SSTP-specifik-forbindelse-svigt/[4]


Fejlen viste sig at være konstant: CERT\_E\_CN\_NO\_MATCH