2012-02-20 8 views
5

Abbiamo un certificato esistente (segno globale) che funziona correttamente quando un'applicazione Windows Mobile (.NET 3.5) ha provato a consumare il Web servizio (scritto anche in .NET 3.5) ospitato su IIS."Impossibile stabilire la relazione di trust con il server remoto" errore quando il dispositivo Windows mobile .NET consuma un servizio web

Tuttavia, quando il certificato di nuova esecuzione (segno globale) è attivo, l'applicazione Windows Mobile non riesce a connettersi al servizio Web, l'errore che stiamo ottenendo è "Impossibile stabilire una relazione di trust con il server remoto". Ho provato a cercarlo su Google molte volte e non ho trovato una soluzione adatta.

Abbiamo anche provato a copiare (e installare) il ROOT e il certificato intermedio nella catena sul dispositivo, ma questo non funziona ancora.

Quando testiamo il nuovo certificato con un browser Web per PC (IE, Firefox, Opera), un'applicazione desktop che utilizza il servizio Web (.NET 3.5) e anche Internet Explorer sul dispositivo Windows Mobile sul Web .NET. la pagina delle definizioni/documentazione del servizio è visualizzata senza problemi (senza avvisi o errori), sembra che si tratti solo di un problema sul dispositivo mobile Windows quando si utilizza un'applicazione framework (3.5) compatta che sta tentando di utilizzare il servizio web.

Abbiamo convalidato che il certificato è stato installato correttamente sul sito dello shopper SSL, e dopo le nostre ricerche su google ci siamo imbattuti e implementato (come test) un gestore ICertificatePolicy "trust all", questo ha risolto il problema, tuttavia io speravo che questo problema potesse essere risolto dalla modifica della configurazione/installazione piuttosto che da un cambio di codice e una ridistribuzione di oltre 150 dispositivi basati su Windows Mobile.

L'hander ICertificatePolicy ha mostrato l'errore restituito durante il tentativo di convalidare il certificato: il parametro problema è stato impostato su: -2146762481 (0x800B010F in HEX), che credo sia l'errore "CN No MATCH", tuttavia Ive ha cercato questo in forma numerica, esadecimale e nome e non ha ancora trovato una risoluzione oltre al cambio di codice "Trust all".

+0

Perché di contrassegnare questo come una domanda di ColdFusion? –

+0

Scusa, non volevo, non ero a conoscenza del completamento automatico dei tag quando ho aggiunto la domanda allo stack overflow, poiché è la prima volta che ho dovuto rispondere alla domanda di aska, di solito google e trovo una domanda che qualcun altro aveva già aveva risposto Cambierò i tag se è possibile che lo faccia – dtpuk

+0

Come messaggio di eccezione più specifico, abbiamo ricevuto il messaggio "Il certificato remoto ha fallito la procedura di convalida". – thecoolmacdude

risposta

7

Ho pensato di postare la risposta qui nel caso in cui qualcun altro si imbattesse in questo problema. Non ho trovato una spiegazione solida al 100%, ma siamo riusciti a farlo funzionare e questo mi ha fatto venire in mente un'ipotesi sul problema:

Sembra che la struttura compatta sembra prendere il primo nome comune (CN) dal campo "Subject Name Alternative" del certificato SSL e solo valutando il certificato rispetto a quello mentre il framework completo, IE e IE sul dispositivo mobile sembravano utilizzare entrambi. Il mio ragionamento per credere questo è al di sotto:

L'applicazione PDA stava accedendo alla url:

https://AMobileWebService.com/Webservice.asmx

Il nostro vecchio certificato SSL che lavorato avuto la segue nella "nome soggetto alternativo":
nome DNS = AMobileWebService.com
Nam DNS E = www.AMobileWebService.com

E il nuovo certificato che non ha funzionato è stata contenuta la seguente nello stesso campo:
DNS Name = www.AMobileWebService.com
nome DNS = AMobileWebService.com

Quando abbiamo cambiato l'applicazione per utilizzare https://www.AMobileSebService.com/Webservice.asmx, il vecchio certificato (che è stato in precedenza lavorando) non è riuscito a stabilire un rapporto di fiducia, e il nuovo certificato ha funzionato (ma in precedenza non lo fece).

Come ho detto prima, questo mi porta a credere che .NET CF stia recuperando solo il nome nel certificato SSL e quindi valutando il nome dell'host dell'URL rispetto a quello, piuttosto che farlo contro entrambi come nel .NET completo. Struttura.

Siamo venuti a questa conclusione mettendo in atto una "fiducia tutti i certificati" aggirare che abbiamo trovato su StackOverflow: https://stackoverflow.com/questions/6552598/system-net-webexception-thrown-when-consuming-a-web-service-over-https

Il parametro problema sulla soluzione tornava il valore -2.146,762481 millions. Ricerca su rappresentazione esadecimale del valore (0x800b010f) ha sottolineato che io le seguenti informazioni: https://blogs.technet.microsoft.com/rrasblog/2007/09/26/how-to-debug-sstp-specific-connection-failures/

L'errore si è rivelata la costante: CERT_E_CN_NO_MATCH

+0

Recentemente mi sono imbattuto in questo anche ma per me è stato il nome amichevole è stato cambiato in xyz.com-2048 invece di xyz.com come era prima. Sono stato in grado di risolvere questo problema usando il link sopra ma volevo far sapere agli altri che potrebbe non essere l'ordine del nome in cn dato che era lo stesso nei miei certificati. –

+1

Volevo solo dire che ci siamo imbattuti recentemente in questo problema (sì, abbiamo ancora usato il framework compatto) e la rigenerazione del certificato SSL con il nome corretto prima nell'elenco di SAN era la soluzione. – Hypino

+0

Finalmente trovato questo dopo giorni vale la pena di cercare di capire il nostro problema. Grazie! – thecoolmacdude

Problemi correlati