Como solucionar problemas de conexión SSL/TLS contra IIS

La mayoría de los casos de soporte que nos abren para diagnosticar problemas al conectarse por HTTPS a un sitio web, suelen resolverse realizando alguno de los pasos descritos a continuación. Partimos de la premisa de que podemos acceder correctamente por HTTP para acotar el escenario a un problema al establecer la conexión HTTPS.

1) Lo primero que suelo comprobar es que el certificado es válido y está emitido con el propósito adecuado.

a) Para ello debemos examinar las propiedades del certificado de servidor, y en la pestaña General verificar que el certificado es válido y tiene una clave privada.

b) Comprobar también en la pestaña Details que la propiedad Enhanced Key Usage (o Uso Mejorado de Clave) incluye el valor Server Authentication (1.3.6.1.5.5.7.3.1) .

c) Por último vayamos a la pestaña Certification Path y verifiquemos que todos los certificados en la cadena de certificación tienen el estado OK.

Las condiciones descritas en los pasos a, b y c constituyen el mínimo imprescindible para que se pueda establecer una conexión SSL, pero el hecho de que todo esté correcto no descarta por completo que el problema se encuentre en el certificado. Más adelante realizaremos pruebas adicionales para descartar problemas de integridad con el certificado.

2) Comprobar si existe un conflicto con alguna otra aplicación que esté escuchando por el puerto 443 (o el que aplique en cada caso). Si este es el caso, es posible que veamos el siguiente evento registrado en los logs de eventos NT:

Event Type: Error

Event Source: W3SVC

Event Category: None

Event ID: 1114

Description: One of the IP/Port combinations for site '1' has already been configured to be used by another program. The other program's SSL configuration will be used.

Para diagnosticar esta situación, inicialmente ejecutaremos el siguiente comando:

C:\WINDOWS\system32>netstat -noa

Si todo es correcto, sólo debería haber una aplicación escuchando por el puerto 443, y el resultado debería ser algo parecido a esto (el PID 4 siempre equivale al proceso System):

Active Connections

  Proto Local Address Foreign Address State PID

  TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4

  TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 688

  TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4

  TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4

Si nos surgen dudas sobre si realmente es IIS (o el proceso System) el que está escuchando por el puerto 443, podéis utilizar la herramienta tasklist.exe o simplemente Task Manager para confirmarlo. Si el puerto estuviera en uso por otra aplicación, habría que determinar qué aplicación usa el puerto y para qué. La forma de verificar si este es realmente el problema sería probar a configurar SSL en un puerto distinto y verificar si funciona.

Si netstat no arroja luz sobre el conflicto de puertos, pero no obstante vemos el evento mencionado anteriormente (Event ID 1114) en los logs de eventos, ejecutaremos el siguiente comando para sacar un listado de los certificados SSL asociados a IIS:

C:\Program Files\Support Tools>httpcfg query ssl

 

Cuando revisemos la lista debemos buscar alguna entrada en la que el campo de Hash y CertStoreName están vacíos o nulos, y el Guid está todo a ceros. Este es indicativo de un problema.

IP : 0.0.0.0:443

Hash :

Guid : {00000000-0000-0000-0000-000000000000}

CertStoreName : (null)

CertCheckMode : 0

RevocationFreshnessTime : 0

UrlRetrievalTimeout : 0

SslCtlIdentifier : (null)

SslCtlStoreName : (null)

Flags : 0

Para solventar este problema, debemos eliminar el binding entre IIS y el certificado ejecutando el siguiente comando (la sintaxis genérica es: httpcfg delete ssl -i ip:puerto):

C:\Program Files\Support Tools>httpcfg delete ssl -i 0.0.0.0:443

Y posteriormente volver a configurar el certificado SSL desde INETMGR.EXE. Si volvemos a listar los certificados SSL con httpcfg.exe el resultado ahora debería ser algo parecido a esto:

IP : 0.0.0.0:443

Hash : d753a06831d416db4bf2 9f5 aa33ae714dfba5d

Guid : {4dc3e181-e14b-4a21-b022-59fc669b0914}

CertStoreName : MY

CertCheckMode : 0

RevocationFreshnessTime : 0

UrlRetrievalTimeout : 0

SslCtlIdentifier :

SslCtlStoreName :

Flags : 0

3) Crear un certificado de pruebas con SelfSSL.exe para verificar que el problema no es del certificado. Esta herramienta se puede descargar como parte del Resource Kit de IIS 6.0 . La herramienta genera un certificado de pruebas automáticamente y lo instala para un sitio web determinado. La sintaxis es la siguiente:

selfssl.exe /N:CN=[Nombre Cert.] /V:[Días Validez Cert.] /S:[ID Sitio Web] /P:[Puerto SSL]

Por ejemplo, para nuestro sitio web de anteriores ejemplos ejecutaríamos el siguiente comando y posteriormente volveríamos a probar si podemos establecer la conexión HTTPS:

C:\Program Files\IIS Resources\SelfSSL>selfssl.exe /N:CN=mywebsite.microsoft.com /V:365 /S:1 /P:443

Microsoft (R) SelfSSL Version 1.0

Copyright (C) 2003 Microsoft Corporation. All rights reserved.

Do you want to replace the SSL settings for site 1 (Y/N)?Y

The self-signed certificate was successfully assigned to site 1.

4) Por último reinstalaremos el certificado seleccionando manualmente el almacén de certificados en el que se instala. Es decir, al instalar el certificado, no seleccionar la opción de Automatically select the certificate store based on the type of certificate, sino hacerlo manualmente marcando la casilla Show physical stores y seleccionando el almacén deseado desde aquí.

De esta forma descartaremos que tenemos el problema descrito en el post Certificate has private key but we get "the keyset does not exist" error .

Si llegados a este punto seguís sin poder establecer una conexión HTTPS contra vuestro servidor, será un buen momento para abrir un caso de soporte con Microsoft.

 

Espero que os haya sido de utilidad.

- Daniel Mossberg