En un entorno PKI, llegará un momento en el que tendremos que renovar el certificado emitido para la Sub CA, recordar que esto debe ser hecho antes de que el certificado caduque (en nuestro PKI habíamos configurado una duración de 8 años), de lo contrario, tendremos que emitir un nuevo certificado. No es posible renovar certificados caducados.
Este sería el procedimiento, desde la Sub CA:
Nos aparecerá un mensaje preguntando si queremos parar los servicios de certificado de AD, indicamos que si:
Aquí nos indica si queremos generar un nuevo par de claves (pública y privada), indicamos que no:
En este momento, como vamos a enviar el request a nuestra Root CA, la cual es una CA offline, pues le decimos que genere un nuevo request haciendo click en «Cancel».
Esto genera un nuevo .req en C:\ de nuestra Sub CA (fijarse que aún tenemos el primer .req que habíamos utilizado en la guía de PKI):
Copiamos ese .req y lo pegamos en nuestra Root CA:
Desde la consola de certificados de nuestra Root CA, vamos a «Submit new request…»:
Y seleccionamos el .req nuevo:
Nos vamos a «Pending Requests» y emitimos el certificado:
Una vez hecho esto, ya podemos ver nuestro certificado emitido en «Issued Certificates», y lo exportamos:
Elegimos formato .CER:
Especificamos un nombre:
Y lo exportamos:
Una vez hecha la exportación, ya tenemos nuestro nuevo certificado RootCA2.cer (a diferencia del RootCA.cer que era el que originalmente utilizamos para nuestra Sub CA):
Lo copiamos y lo pegamos en la Sub CA:
Pasamos a instalarlo en la Sub CA:
Paramos el servicio de CA:
Seleccionamos el certificado:
Y finalmente ya vemos como tenemos renovada nuestra Sub CA, desde aquí podemos ver nuestro nuevo certificado:
Si comparamos ambos certificados, haciendo click en «View Certificate» y luego en la pestaña Details, vemos algunos cambios en las extensiones:
- Podemos observar que la extensión «CA Version» cambia de V0.0 a V1.0. La «CA Version» se compone de 2 dígitos separados por un punto que sólo aparece en certificados CA. Se utiliza para llevar un registro de las diferentes revisiones de los certificarlos al renovarlos.
- Vemos también que tanto el SKI (Subject Key Identifier) como el AKI (Authority Key Identifier) no cambian ya que seguimos usando el mismo par de claves existente. Estos dos valores se utilizan para la construción del «Certification Path».
- Además, vemos para el «Certificate #1» que el valor de «Previous CA Certificate Hash» no es otro que el «Thumbprint» del certificado previo «Certificate #0». El «Thumbprint» es un valor hash calculado a partir del par de claves de un certificado, se utiliza para identificar el certificado y es único.
Hablaremos más en profundidad de todas estas extensiones en otro artículo.
Esto es todo por hoy, gracias por seguirnos y un saludo!
Buenos dias Jose Ramon, me salva la vida leer este blog. Tengo una consulta que hacer puesto que una de mis SUBCA tiene la siguiente alerta: Active Directory Certificate Services could not create an encryption certificate. Requested by Midominio\MiSubCA$ Invalid Issuance Policies: 2.5.29.32.0. The certificate has invalid policy. 0x800b0113 (-2146762477). Está conectada a un HSM con Ncipher Security World. En la resolucion me dice lo siguiente pero ando algo perdido la verdad:
Use a cryptographic service provider that supports key archival and recovery
Hola Raul,
Me alegra que te sea útil, pues ese error parece que tiene que ver con el Template que estás usando para ese certificado, revisa en las extensiones, las Issuance Policies. Échale un ojo también a la pestaña de Cryptography de ese template a ver que providers tiene. Podrías testearlo así:
1. certutil -getreg ca\EncryptionCSP -csptest
2. certutil -csp
Si estás utilizando un provider nCipher quizás esto te pueda ayudar pero lo mejor es que contactes con ellos:
https://social.technet.microsoft.com/wiki/contents/articles/1730.installing-and-configuring-an-ncipher-hardware-security-module-hsm-with-fim-cm-2010.aspx
Y si el problema está en las Issuance Policies busca por este comando en Internet:
certutil –setreg CA\CRLFlags +CRLF_IGNORE_INVALID_POLICIES
Es un workaroud pero te puede dar alguna pista:
https://social.technet.microsoft.com/Forums/office/en-US/8bfc3f80-55c8-4e93-88b9-23a59bb58d2b/all-issuance-policies-for-an-intermediate-ca?forum=winserversecurity
Saludos!
Hola Raul, adicionalmente a lo que propone Jose es posible que estes usando una CA algo antigua, este tipo de errores con el Cryptographic Provider, normalmente se deben a que los servicios a los que están conectados nuestras Certification Authorities, están solicitando características de criptografía que son superiores o no soportadas por lo que se tiene configurado en la CA.
Lo mejor que puedes hacer, es utilizar Windows Server 2019 con todos sus updates y con algoritmos de encriptación fuertes para desplegar una nueva CA. Puedes desplegar la CA nueva y emitir todos los certificados que necesitas en paralelo, solo entonces puedes probar a apagar el servidor donde tienes la CA «vieja» y determinar si se genero algún impacto. Si no puedes apagar el servidor detener el servicio también es una opción.
Es importante no permitir que nuestra infraestructura de certificados se vaya quedando obsoleta, hoy en día la renovación de la tecnología sucede a una velocidad exponencialmente mayor que hace 10 años.
El error 0x800b0113 CERT_E_INVALID_POLICY también tiene varios BUGs reportados y bien documentados para Windows Server 2012 R2 y Windows Server 2016, por lo que sigue siendo buena idea mantener el sistema operativo actualizado y comenzar a desplegar nuestra infraestructura nueva en paralelo con la que existe previamente, sin migraciones, ya que esto evita mucho re-trabajo cuando la migración falla y hay que desplegar desde cero.
Cualquier pregunta o comentario adicional por favor no dudes en dejarnos tu comentario.
Muchas Gracias Jose Ramon! Realizaré pruebas con lo que me has dicho a ver si soy con ello, ya que de las 4 SubCa´s que tengo, solamente me da errores una de ellas.
Cambiando de asunto, creo que he cometido un fallo en un entorno PKI de laboratorio que tengo, ya que la SubCA estaba caducada y al renovar el certificado(tanto root como sub están en dominio) he renovado el cert pero manteniendo la clave privada. He logrado hacer unos autoenroll en unos servidores que tenia ya que no eran accesibles por LDAP y ahora si pero no puedo configurar el OCSP, no tengo activa la casilla de asignar el signing certificate. ¿Puede ser debido a que he renovado usando la misma clave? Se puede solicitar un nuevo renew de certificado y nueva clave? No se si tendré que solicitar nuevos certificados para los DC´s o se mantendrán los que ya están y aparte de publicar la CRL, aunque al estar integradas en AD puede que no sea necesario.
Gracias de nuevo!
Hola Raul!
Para renovar el certificado del OCSP está muy bien esta guía: https://social.technet.microsoft.com/wiki/contents/articles/12168.renew-ocsp-signing-certificate.aspx
Saludos,
Muchas gracias por la información, precisamente en este momento estoy con el mismo tema en mi trabajo. Me suge una duda. Que pasa con los certificados emitidos hasta el momento con esa subca?, al renovar el certificado de subca, seguirán ciendo válidos todos los certificados emitidos hasta ese momento y que no hayan caducado?, o abría que renovar dichos certificados también para que queden con la nueva subca.
Muchas gracias de nuevo.
Por defecto, serán renovados a través de autoenrollment cuando se acerque su fecha de expiración (también se puede hacer de forma manual).
Un saludo Luis y gracias por leernos!
Una vez que se renueva el certificado de CA subordinada. Aparecen dos certificados. Es posible eliminar el antiguo ?
Seguiran publicandose las listas de CRL deforma doble ?
Muchas gracias
Hola Jorge,
Se puede eliminar el antiguo, pero no lo recomiendo. En caso de borrarlo, en la CRL tendrías que actualizar dicho cambio. Pero no te lo recomiendo, aquí hablan mas del tema:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/95e790b4-7470-48f5-bd6c-b58a16ad3981/remove-revoked-subordinate-ca-certificate?forum=winserversecurity
Un saludo!