¿Por qué Windows 2012 R2 no confía en mi certificado autofirmado?

9

En un entorno de prueba, actualmente estoy retrasado de probar algunas cosas que deben implementarse pronto (en realidad ya, pero ya saben cómo son los plazos ...) porque Windows se niega a confiar en el certificado autofirmado que tenemos en nuestro entorno de prueba aislado. Si bien podría evitar el problema con el certificado "real" y algunos trucos de DNS, por razones de seguridad / compartimentación no tengo dicho certificado.

Estoy intentando conectarme a un servidor de correo electrónico basado en Linux llamado Zimbra; está utilizando un certificado OpenSSL autofirmado autofirmado. Si bien las páginas que Google ha aparecido se refieren específicamente a sitios web de IIS con certificados autofirmados de IIS, no creo que el método de generarlo realmente importe.

De acuerdo con las instrucciones que encontré aquí y aquí , esto debería ser una simple cuestión de instalar el certificado en la tienda de la Autoridad de Certificación de Raíz de Confianza de la computadora local. Lo que he hecho, así como copiar manualmente el certificado e importarlo directamente a través del complemento MMC. Los cierres de sesión y reinicios no cambian nada.

Aquí está el error de certificado que recibo cada vez: ingrese la descripción de la imagen aquí

Y aquí está la ruta de certificación (spoiler: es solo el certificado en sí): ingrese la descripción de la imagen aquí

Finalmente, aquí está el certificado guardado de forma segura en la tienda de certificados de la computadora local, exactamente como las instrucciones que he encontrado dicen que deberían ser: ingrese la descripción de la imagen aquí

Estas instrucciones hacen referencia específicamente a Vista (bueno, la segunda no menciona el sistema operativo) y IIS, mientras uso Server 2012 R2 para conectarse a un servidor basado en Linux; existen algunas diferencias en el asistente de importación (como el mío tiene la opción de importar para el usuario actual o el sistema local, aunque he intentado con ambos), ¿entonces quizás hay algo diferente que tengo que hacer aquí? ¿Es necesario cambiar una configuración en algún lugar que no haya encontrado para que realmente confíe realmente en el certificado en el que ya le he dicho que confíe?

¿Cuál es la forma correcta de hacer que Windows Server 2012 R2 confíe en un certificado autofirmado?

Kromey
fuente
No se puede reproducir tu problema. Si usa "Crear un certificado autofirmado" de IIS y selecciona instalarlo en la tienda Personal (también probé la tienda de alojamiento web), no hay ningún problema. ¿Cómo creaste el certificado? ¿De IIS o de la autoridad de certificación MMC snapin?
¿Has intentado seleccionar la tienda de destino explícitamente (importando desde la consola mmc)?
JoaoCC
@SujaySarma No es para un sitio web de IIS, sino para una aplicación de Linux llamada Zimbra. Es un certificado autofirmado de OpenSSL.
Kromey
@ user1703840 Sí, especifiqué explícitamente la tienda de destino, y permití que Windows la seleccionara automáticamente, tanto a través de MMC como del asistente de importación de certificados en IE. Los mismos resultados en ambos sentidos, que es ninguno.
Kromey
¿Eh? ¿De dónde vino Linux? Toda su pregunta y los enlaces que ha publicado (incluidas sus capturas de pantalla) se refieren a Windows Server 2012 R2 e IIS. Por favor aclarar

Respuestas:

1

El error que está recibiendo no es que no sea un certificado raíz confiable, sino que no pueda verificar la cadena hasta un certificado confiable. Si alguna parte de la cadena está rota, no es de confianza o falta, recibirá dicho error. El error que obtengo con una raíz autofirmada y no confiablees esto: este certificado raíz de CA no es de confianza. Para habilitar la confianza, instale este certificado en el almacén de Autoridades de certificación raíz de confianza. Pero para usted, dice que no puede verificar hasta un certificado raíz de confianza. Esto puede deberse a que durante el proceso de auto firma, es posible que le haya dicho a openssl que firme el certificado con una raíz diferente (no auto firma), o que no se haya configurado como una CA raíz. Si es el primero, debe confiar en la raíz con la que se firmó. Si es lo último, se trata de establecer algunas propiedades en openssl.conf.

flashbang
fuente
Las capturas de pantalla muestran que el certificado está instalado en Trusted Root CA, y también muestran que toda la cadena es el certificado en sí mismo: es la raíz y, por lo tanto, debería ser suficiente estar en Trusted Root CA. La pregunta es ¿por qué no es así?
Kromey
Estoy diciendo que podría no ser la raíz, no es que no se agregue al almacén de raíces de confianza. El error es lo extraño: no debería decir que no puede verificarlo hasta una CA confiable, si se supone que es una CA, por lo que sugiero que en realidad no es una raíz, sino que está firmada con otro certificado
flashbang
intente ejecutar este comando en el cuadro para el que está tratando de obtener el certificado openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 30 -sha256 -nodese importe ese certificado en el almacén de CA raíz de confianza. (así como configurarlo para que sea el certificado y la clave utilizados por Zimbra, por supuesto).
flashbang
Oh, ya veo lo que quieres decir. Lo siento, he entendido mal. Pero si no es la raíz, ¿no debería aparecer en la ventana Ruta de certificación? En cualquier caso, desafortunadamente, en realidad no puedo probar esto más: logré obtener nuestro certificado legítimo y, junto con un poco de piratería en el hostsarchivo, funcionó de esa manera.
Kromey
Su certificado es de una CA raíz, según la captura de pantalla. Si mira los detalles del certificado para idp.godaddy.com, se presenta la ruta completa y puede usarla como una comparación. Si observa las propiedades del certificado en MMC, ¿incluye la autenticación del servidor en los propósitos del certificado? (Haga clic derecho sobre el certificado en la segunda captura de pantalla y seleccione propiedades).
John Auld
1

por lo que puedo resolver, necesita agregar zmaster como CA de fuente confiable ya que esa es la autoridad emisora, WS2k12 está tratando de verificar el certificado contra un host del que no sabe nada. Tienes razón en que el método de generación no es importante, pero sí una fuente verificable. Esto tiene el efecto que está experimentando: que WS2k12 no confía en un certificado solo porque tiene un nombre de $ Random_issuing_authority, necesita poder verificar el certificado.

James Gugelstuphukenmuch Moore
fuente
Es un certificado autofirmado: al colocar el certificado en la tienda Trusted Root CA, por definición, confía en el emisor.
Chris McKeown
A menos que me falte algo, eso es exactamente lo que he hecho: vea la tercera captura de pantalla que muestra el certificado de zmaster dentro de la tienda Trusted Root CA.
Kromey
0

Tuve el mismo problema, resulta que mi solución fue actualizar los archivos .crt y .key para el servidor de correo como lo usó dovecot. Exim4 en el correo tenía un conjunto de claves / cert actualizado, pero dovecot todavía apuntaba al antiguo conjunto de claves / cert.

El antiguo par cert / key funcionó bien con la mayoría de las situaciones, pero no con outlook.com ni con MS Outlook 2013.

Los problemas con outlook.com me hicieron actualizar el certificado exim4 recientemente, ahora dovecot [y el servidor de correo web] también usa los nuevos archivos cert (y key). El servidor de correo también se actualizó recientemente [desde el antiguo Debian squeeze-lts a wheezy], la configuración anterior estaba bien con el antiguo conjunto de claves / cert, pero después de la actualización, necesitaba crear el nuevo conjunto de claves / cert antes Los productos de MS funcionarían correctamente con el servidor de correo.

Andrew McGlashan
fuente
0

Creo que el problema es cómo accediste a los recursos. Para su red local, puede usar el nombre de host en lugar del nombre de dominio completo. Sin embargo, su certificado se emite con el nombre de dominio completo.

puffel
fuente
Esta pregunta ya tiene una respuesta aceptada.
BE77Y
-1

Instale el certificado en Trusted Root Certification Authorities y Trusted Publishers.

Dimaf
fuente