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

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:

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

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:

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?

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.

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.

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.

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.

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