2012-02-20 20 views
5

Tenemos un certificado existente (signo global) que funciona bien cuando una aplicación Windows Mobile (.NET 3.5) intentó consumir la web servicio (también escrito en .NET 3.5) alojado en IIS.Error "No se pudo establecer una relación de confianza con el servidor remoto" cuando el dispositivo Windows Mobile .NET consume un servicio web

Sin embargo, cuando hacemos el certificado reeditado (signo global) en vivo, la aplicación de Windows Mobile no puede conectarse al servicio web, el error que obtenemos es "No se pudo establecer una relación de confianza con el servidor remoto". He intentado buscar esto en Google muchas veces y no he encontrado una solución adecuada.

También hemos intentado copiar (e instalar) la RAÍZ y el certificado intermedio de la cadena en el dispositivo, pero esto todavía no funciona.

Cuando probamos el nuevo certificado con un navegador web para PC (IE, Firefox, Opera), una aplicación de escritorio que consume el servicio web (.NET 3.5) e incluso Internet Explorer en el dispositivo Windows Mobile .NET web la página de definiciones/documentación de servicios se muestra sin problemas (sin advertencias ni errores), parece que solo es un problema en el dispositivo móvil de Windows cuando se usa una aplicación de marco compacto (3.5) que intenta consumir el servicio web.

Hemos validado que el certificado está instalado correctamente en el sitio del comprador SSL, y después de nuestras búsquedas en Google encontramos e implementamos (como prueba) un controlador ICertificatePolicy "confía en todos", esto resolvió el problema, sin embargo esperaba que este problema se solucionara mediante el cambio de configuración/configuración en lugar de un cambio de código y una redistribución de más de 150 dispositivos basados ​​en Windows Mobile.

El hander ICertificatePolicy mostró el error que se estaba devolviendo al intentar validar el certificado: el parámetro de problema se estableció en: -2146762481 (0x800B010F en HEX), que creo que es el error "CN NO MATCH", sin embargo, he buscado esto tanto en su forma numérica, hexadecimal y de nombre, y aún tengo que encontrar una resolución diferente al cambio del código "Confiar en todos".

+0

¿Por qué usted y la etiqueta esto como una cuestión de ColdFusion? –

+0

Lo siento, no era mi intención, no sabía que las etiquetas se completaban automáticamente cuando añadía la pregunta al desbordamiento de la pila, ya que era la primera vez que tenía que hacer una pregunta, normalmente la busqué en Google y encontré una pregunta que alguien más tenía Ya había respondido. Cambiaré las etiquetas si es posible para mí – dtpuk

+0

Como un mensaje de excepción más específico, recibimos el mensaje "El certificado remoto ha fallado el procedimiento de validación". – thecoolmacdude

Respuesta

7

Pensé que publicaría la respuesta aquí en caso de que alguien más se encuentre con este problema. No he encontrado una explicación sólida al 100%, pero hemos logrado hacerlo funcionar y esto me ha hecho pensar en una hipótesis sobre el problema:

Parece que el marco compacto parece estar tomando el primer nombre común (CN) fuera del campo "Subject Name Alternative" del certificado SSL y solo evaluando el certificado contra eso mientras que el marco completo, IE e IE en el dispositivo móvil parecían estar usando ambos. Mi razonamiento para creer que esto es a continuación:

La aplicación PDA estaba accediendo a la URL:

https://AMobileWebService.com/Webservice.asmx

Nuestro certificado SSL de edad que trabajado tenía la siguiente en el "nombre alternativo del sujeto":
nombre DNS = AMobileWebService.com
Nam DNS e = www.AMobileWebService.com

Y el nuevo certificado que no funcionó fue el siguiente contenido en el mismo campo:
DNS Name = www.AMobileWebService.com
nombre DNS = AMobileWebService.com

Cuando cambiamos la aplicación a usar https://www.AMobileSebService.com/Webservice.asmx, el antiguo certificado (que estaba trabajando anteriormente) no pudo establecer una relación de confianza, y el nuevo certificado trabajó (pero anteriormente no lo hizo).

Como mencioné anteriormente, esto me lleva a pensar que .NET CF solo está recuperando el primer nombre en el certificado SSL y luego evaluando el nombre de host de la url contra eso, en lugar de hacerlo contra ambos como en .NET completo. Marco de referencia.

Llegamos a esta conclusión mediante la implementación de un "fideicomiso todos los certificados de" trabajar en torno a que nos encontramos en stackoverflow: https://stackoverflow.com/questions/6552598/system-net-webexception-thrown-when-consuming-a-web-service-over-https

El parámetro problema en la solución regresaba el valor -2146762481. Buscando en representación hexadecimal del valor (0x800b010f) señaló conmigo a la siguiente información: https://blogs.technet.microsoft.com/rrasblog/2007/09/26/how-to-debug-sstp-specific-connection-failures/

El error resultó ser la constante: CERT_E_CN_NO_MATCH

+0

Recientemente me encontré con esto también, pero para mí fue el nombre amistoso cambiado a xyz.com-2048 en lugar de xyz.com como lo era antes. Pude resolver esto usando el enlace de arriba, pero quería dejarles saber a otros que no es el orden de nombre de CN, ya que era lo mismo en mis certificados. –

+1

Solo quería decir que recientemente nos encontramos con este problema (sí, aún usamos el marco compacto) y la regeneración del certificado SSL con el nombre propio primero en la lista de SAN fue la solución. – Hypino

+0

Finalmente encontré esto después de días que vale la pena tratar de resolver nuestro problema. ¡Gracias! – thecoolmacdude

Cuestiones relacionadas