¿Pueden los servicios de certificados de MS ser subordinados a CA creados con OpenSSL?

Quiero configurar una autoridad de certificación empresarial para mi dominio. Entonces puedo emitir certificados para varios propósitos. Me gustaría seguir la mejor práctica de tener una CA fuera de línea como raíz, y configurar mi CA empresarial como una subordinada. Pero parece una tontería licenciar una copia completa de Windows para esta tarea.

Lo que espero poder hacer es instalar alguna distribución en vivo en un disco flash USB, y luego instalar openssl, y configurar mi CA en la unidad flash. Cuando esté listo para construir la clave / certificado raíz, desconectaré la computadora de la red y nunca más volveré a usar ese disco USB en una computadora conectada a la red.

¿Podré firmar y crear correctamente un certificado de CA subordinada para una CA empresarial de Windows, que será utilizable? ¿Qué opciones necesito usar con OpenSSL para construir la CA y firmar el certificado de CA subordinada correctamente?

Intenté buscar en la web, y esto fue lo único que pude encontrar sobre el tema. Pero es anterior a 2008, y no estoy completamente seguro de que la persona haya tenido éxito.

Sí, funciona bien; una autoridad de certificación de Windows no tiene reparos en ejecutarse como subordinado de una raíz que no sea Windows.

Probado con una raíz OpenSSL y una subordinada de Windows 2008 R2 en modo Enterprise.

Un par de cosas para jugar bien con lo que MS CA espera en la configuración de OpenSSL:

• Las ubicaciones válidas de AIA y CDP deben aplicarse al certificado raíz, en la sección configurada por la x509_extensionspropiedad de la [req]sección para la raíz autofirmada . Algo en este sentido:

  authorityInfoAccess = caIssuers;URI:http://test-rootca.test.local/root.pem
  crlDistributionPoints = URI:http://test-rootca.test.local/root.crl
  

• Una configuración de OpenSSL dada probablemente no permita CA subordinadas por defecto. Cambie eso para las solicitudes firmadas (asegúrese de que esto no esté en su lugar para las solicitudes que no deberían ser CA, por supuesto). Esto estará en la sección configurada por la x509_extensionspropiedad de la [ca]sección:

  basicConstraints=CA:TRUE
  certificatePolicies=2.5.29.32.0
  

Entonces, haremos una CA para probar.

Haz tu raíz:

openssl req -new -x509 -keyout /etc/ssl/private/root.key -out /etc/ssl/certs/root.pem -nodes -extensions v3_ca

Juega con tu configuración y crea los archivos y directorios necesarios en la [ca]sección de tu configuración OpenSSL.

Todo listo para poner en marcha el lado de Microsoft; cree una CA subordinada de Windows con firma manual.

Cargue la solicitud de certificado al servidor OpenSSL. Mientras lo hace, descargue el certificado raíz. Importarlo a la tienda de raíces de confianza - de la computadora, no su usuario!

Emitir el certificado subordinado:

openssl ca -in test-subca.req
(you might need to specify a permissive policy manually with -policy, check your config)

Si eso no funcionó, su CA probablemente tenga un problema con la configuración: nuevo directorio de certificaciones, archivo de índice, archivo de serie, etc. Verifique el mensaje de error.

Si se fue, entonces eso es todo. Si no lo ha hecho, haga una CRL y colóquela en el CDP que configuró anteriormente; Acabo de instalar Apache y lo atasqué en webroot:

openssl ca -gencrl -out /var/www/root.crl

Y ponga su certificado en la ubicación de AIA, si aún no lo está:

cp /etc/ssl/certs/root.pem /var/www/root.pem

Descargue el certificado subordinado recién emitido e instálelo en la CA con el complemento MMC de la Autoridad de certificación. Se quejará de cualquier problema con la confianza o la validación, pero no tiene ninguna objeción moral para tomarlo.

Resultado final; una CA de Windows funcional sin quejas del complemento Enterprise PKI, con un indicador OpenSSL Generated Certificateen los atributos.

Veo a lo que te refieres, pero no creo que OpenSSL sea una buena herramienta para el trabajo. Es posible que desee ver los proyectos de la Autoridad de certificación de código abierto , como EJBCA, que se centran más en esta funcionalidad que OpenSSL y tienen documentación específica que puede usar.

No veo una razón por la cual el concepto no funcionaría, ya que todo lo que está haciendo es firmar el certificado de la CA subordinada. Si estuviera pagando a una CA pública para que lo haga por usted, no necesariamente sabría o no le importaría qué sabor de servidor estaban usando.

Todo lo que necesita preocuparse es:

• puede firmar el certificado del CSR generado por su subordinado
• el resultado puede instalarse en el subordinado mismo
• tiene un certificado de firma raíz que se puede instalar como confiable en cualquier cliente al que se dirija
• puede generar una lista de revocación que se sirve en algún lugar

No puedo decir que haya hecho esto, pero estoy seguro de que si sigue los documentos para generar una CSR desde un cuadro de Windows, luego siga sus documentos de CA para generar un certificado .p7k a partir de una CSR, entonces debería estar bien.

Por cierto, le recomendaría que cree su CA como una máquina virtual para un hipervisor popular como Hyper-V o VMware, en lugar de un disco de arranque, asegúrese de almacenarlo de forma muy segura en algún lugar donde su sucesor pueda encontrarlo, y gírelo fuera de línea periódicamente para asegurarse de que se ejecuta o transferirlo a nuevos medios / tecnología. Una CA raíz puede tener una vida de 10 o 20 años ...