IIS 7 sigue sirviendo el antiguo certificado SSL


27

Instalé un nuevo certificado SSL en IIS7, eliminé el antiguo certificado y configuré los enlaces para el nuevo certificado, por lo que https ahora está vinculado solo al nuevo certificado.

Reinicié IIS7 (y el propio Windows 2008 Server) y verifiqué el certificado con los comandos:

netsh http show sslcert

Esto mostró solo el nuevo certificado, como esperaba

certutil -store MY

Esto también solo mostró el nuevo certificado y no el anterior, como esperaba

También abrí mmc y revisé los certificados allí y solo veo el nuevo y no el viejo.

También estoy usando una cuenta con privilegios de administrador.

Sin embargo, cuando abro un navegador (desde cualquier computadora) y voy al sitio https, todavía está usando el certificado anterior. Incluso cuando elimino el antiguo certificado del navegador, todavía se envía el antiguo y no el nuevo.

¿Alguien puede ayudarme a resolver dónde me estoy equivocando? ¿Cómo puedo exorcizar el antiguo certificado fantasma?

Respuestas:


28

Primero un par de puntos que probablemente sean iguales para ti

  • Intenté actualizar un certificado porque ha caducado.
  • Tengo varios dominios vinculados a la misma IP. Resulta que son un certificado SAN, pero eso probablemente sea irrelevante.
  • Estaba tratando de usar el almacén de certificados centralizado. Nuevamente, creo que esto es irrelevante para la mayoría de mi respuesta.
  • Ya había intentado actualizar el certificado pero no mostraba la nueva fecha.
  • Probablemente esté en pánico en este momento si su antiguo certificado ya expiró. Tomar una respiración profunda...

Primero, recomendaría ir https://www.digicert.com/help/y descargar su herramienta DigiCert. También puedes usarlo en línea.

Ingrese en su sitio web https://example.comy le mostrará la fecha de vencimiento y la huella digital (lo que MS llama el hash del certificado). Realiza una búsqueda en tiempo real para que no tenga que preocuparse si su navegador (o servidor intermedio) está almacenando en caché algo.

Si está utilizando el almacén de certificados centralizado, querrá estar 100% seguro de que el archivo .pfx es la última versión, vaya al directorio de su tienda y ejecute este comando:

C:\WEBSITES\SSL> certutil -dump www.example.com.pfx

Esto le mostrará la fecha de vencimiento y el hash / huella digital. Obviamente, si esta fecha de vencimiento es incorrecta, probablemente haya exportado el certificado incorrecto al sistema de archivos, así que vaya y corríjalo primero.

Si está utilizando el CCS, entonces suponiendo que este comando certutil le dé la fecha de vencimiento esperada (de su certificado actualizado), puede continuar.

Ejecute el comando:

netsh http show sslcert > c:\temp\certlog.txt
notepad c:\temp\certlog.txt

Es probable que tenga muchas cosas aquí, por lo que es más fácil abrirlo en un editor de texto.

digicert.comQuerrá buscar en este archivo el hash INCORRECTO que obtuvo (o la huella digital que obtuvo de Chrome).

Para mí, esto produjo lo siguiente. Verá que está vinculado a una IP y no a mi nombre de dominio esperado. Este es el problema. Parece que esto (por cualquier motivo no estoy seguro) tiene prioridad sobre el conjunto de enlaces en IIS que acabo de actualizar example.com.

IP:port                      : 10.0.0.1:443
Certificate Hash             : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

Ni siquiera sé de dónde vino este enlace: ni siquiera tengo enlaces SSL en mi sitio predeterminado, pero este servidor tiene algunos años y creo que algo se corrompió y se atascó.

Entonces querrás eliminarlo.

Para estar seguro, querrás ejecutar el siguiente comando y primero para asegurarte de que solo estás eliminando este elemento:

C:\Windows\system32>netsh http show sslcert ipport=10.0.0.1:443

SSL Certificate bindings:
-------------------------

IP:port                      : 10.0.0.1:443
Certificate Hash             : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

Ahora hemos verificado que esta es la huella digital 'mala', y el registro único esperado podemos eliminarlo con este comando:

C:\Windows\system32>netsh http delete sslcert ipport=10.0.0.1:443

SSL Certificate successfully deleted

Con suerte, si ahora vuelve a Digicert y vuelve a ejecutar el comando, le dará la huella digital de certificado esperada. Debe verificar todos los nombres de SAN si tiene alguno solo para estar seguro.

Probablemente quiera IISRESET aquí para asegurarse de que no haya sorpresas más tarde.

Nota final: si está utilizando el almacén de certificados centralizado y observa un comportamiento errático que intenta incluso determinar si está recogiendo su certificado desde allí o no, no se preocupe, no es su culpa. Parece que a veces recoge nuevos archivos de inmediato, pero almacena en caché los viejos. Abrir y volver a guardar el enlace SSL después de realizar cualquier tipo de cambio parece restablecerlo, pero no el 100% del tiempo.

Buena suerte :-)


3
Eres un Simon entre Simons. En nuestro caso, resultó que nuestro servidor había "almacenado en caché" el certificado caducado, [::1]:443mientras que la actualización del certificado en IIS solo actualizaba el registro 0.0.0.0:443. ¡Gracias!
Martes

1
Esto resolvió mi problema con múltiples dominios en la misma IP; no utiliza la tienda de certificados centralizada.
Chris F Carroll

1
He tenido que usar esto algunas veces. El software de administración de alojamiento web PLESK ocasionalmente desordena los enlaces de certificados y termino necesitando los comandos netsh anteriores para eliminar el enlace ofensivo. No estoy seguro de qué versiones están afectadas, pero estoy usando la versión actual de PLESK Onyx en Windows Server 2016.
BenSwayne

En mi caso fue por nombre de host y puerto. Entonces, para filtrar y eliminar por nombre de host, los comandos serían: "netsh http show sslcert hostnameport = www.example.com: 443" y "netsh http delete sslcert hostnameport = www.example.com: 443"
Karthik Jayapal

14

Verifique el certificado vinculado al sitio en IIS. Puede hacer clic con el botón derecho en el sitio y elegir editar enlaces. Allí, debería ver un enlace para el puerto 443 que está asociado con un certificado SSL. Eso todavía puede estar apuntando al viejo.


Lo comprobé y el certificado en los enlaces para el puerto 443 es el nuevo certificado, no el antiguo. Gracias por tu sugerencia.
joechip

1
Extraño, nunca me ha pasado esto. Aunque nunca elimino los viejos certificados. ¿Cómo estás seguro de que sigues obteniendo el antiguo certificado? ¿Está mostrando que ha expirado?
Tatas

Sí, en el navegador puede verificar los detalles del certificado (fecha de vencimiento, etc.) y es el antiguo que IIS7 está sirviendo.
joechip

1
He visto esto con - Chrome. Chrome almacena en caché el certificado anterior y se lo muestra al usuario.
TomTom

3

Solo lo resolví. El servidor estaba realmente sentado detrás de un servidor ISA, por lo que también tuvimos que instalar el nuevo certificado SSL en el servidor ISA.


3

Tuve el mismo problema y verifiqué los enlaces también. Tenía 2 aplicaciones instaladas en IIS, una estaba usando el nuevo certificado, otra usando el viejo.

Para solucionarlo, tuve que eliminar el certificado del servidor por completo (luego posiblemente un reinicio).

Desde el Administrador IIS -> (raíz del árbol IIS) -> icono Certificados del servidor, seleccione el certificado anterior y haga clic en Eliminar en el panel Acciones.


1
Del mismo modo, en realidad teníamos un sitio DETENIDO adicional que hacía referencia al certificado anterior, y una vez que actualizamos ese sitio para usar el nuevo, ¡el sitio real comenzó a mostrar el nuevo certificado!
Acción Dan

1

Experimenté esto durante una actualización de IPv6. Tenía IIS proporcionando una redirección en caso de que alguien intentara acceder a un servicio a través de HTTP que en realidad no era un servicio basado en un servidor web. Actualicé el servicio real (un servidor de voz) para que sea IPv6, sin embargo, no pude actualizar los enlaces para que la redirección incluya las direcciones IPv6.

Esto dio como resultado que las resoluciones fallaran en un sitio global de captura de todo el sitio que tenía el certificado obsoleto. Dado que la captura era simplemente de 404, parecía que el sitio no funcionaba, cuando en realidad estaba llegando al sitio equivocado.


0

En caso de que alguien todavía tropiece con este problema. La mía se resolvió yendo a

C:\inetpub\wwwroot

Luego encontrará un archivo web.config, ábralo con el bloc de notas y elimine la línea con

<httpRedirect enabled="true" destination="http://foo.company.org" />

Guarde e intente nuevamente para acceder al localhost o al sitio raíz de su servidor IIS.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.