Vamos con la última parte, ya tenemos nuestro certificado para la Sub CA emitido, y ahora vamos a exportarlo e instalarlo en nuestra Sub CA, para ello:
Y continuamos como habíamos hecho anteriormente:
Pero ahora seleccionando la extensión .P7B:
Y lo guardamos en C:\ de la Root CA:
Si todo va bien:
Ahora copiamos ese archivo y lo llevamos a la Sub CA:
Lo pegamos en C:\ de la Sub CA:
Abrimos la consola de CA de la Sub CA e instalamos el certificado .P7B que hemos generado en nuestra Root CA (fijarse que la Sub CA hasta este momento está parada):
Al darle a «Open» instalará el certificado y podemos comprobar desde una mmc con Snap-in de certificados que efectivamente si lo está:
Ahora ya podemos iniciar el servicio de CA en la Sub CA:
Al cabo de un tiempo, la Sub CA ya estará plenamente funcional:
Vemos que la Sub CA está ejecutándose ya que tiene el icono en verde, por lo tanto ya podemos emitir certificados desde la Sub CA, y podríamos apagar la Root CA y guardarla en un sitio seguro desconectándola de la red.
Podemos comprobar además que el certificado que tenemos instalado contiene los valores que habíamos especificado previamente, vemos que el «Certification path» está completo:
Vemos también que las direcciones HTTP de la CRL y AIA son correctas:
Si nos fijamos en otros valores como el «Basic Constraints» vemos que contiene lo que habíamos especificado en el capolicy.inf:
También podemos comprobar las diferencias que hay entre CA´s Standalone y Enterprise, una de ellas es que en las CA Enterprise tenemos templates disponibles para publicar certificados y en las Standalone no, como podemos comprobar:
Un detalle importante es que en la Sub CA no hemos configurado aún la publicación de las CRL, para ello hacemos click con el secundario y propiedades de la sección «Revoked Certificates»:
Y aquí vemos los períodos de publicación de la lista base (es una lista completa de los certificados caducados y revocados) y de la lista delta (contiene las diferencias entre listas CRL, desde la última publicación de una CRL base). Desde la pestaña «View CRLs» podemos ver estas listas una vez hayan sido creadas. Después de revisar que los períodos son los adecuados, las publicamos:
Estos archivos se encuentran físicamente en la siguiente ubicación, el que tiene el símbolo + es la lista delta.
Las CRL en grandes organizaciones presentan el problema de generar archivos de gran tamaño, que sobrecargan el ancho de banda y aumentan el tiempo de descarga al usuario. Y otro problema no menos importante, la latencia con la que se actualizan, podría darse el caso de que un certificado caducase y durante unas horas, mientras no se vuelva a publicar la CRL base o delta, la información de la CRL no contendría esta última caducidad. Para solventar estos problemas se suele recurrir a OCSP (Online Certificate Status Protocol) el cual es mucho mas rápido y eficiente que las CRL (pero que no abarcaremos en esta guía).
Recordar que en este caso no estamos publicando CDP y AIA a través de una página web como habíamos hecho en la parte III de la guía, estamos usando las rutas internas por defecto, pero sería necesario en el caso de necesitar acceso externo o desde Internet. El procedimiento sería el mismo pero esta vez para nuestra Sub CA.
Y hasta aquí hemos llegado, ya tenemos nuestro PKI desplegado y funcionando. En futuros artículos hablaremos sobre la administración básica de los servicios de certificado (plantillas, emisión y revocación de certificados, etc…). Espero que os haya servido de ayuda. No dudéis en comentar o preguntar las dudas que tengáis!
Un saludo!
Hola Ramón,
Hemos seguido tus seis capítulos y todo perfecto, y certutil nos verifica correctamente CDP, AIA y OCSP en local, pero no conseguimos comprobar revocados externamente. ¿has solucionado tú ese paso?
Muchas gracias y un saludo.
Luis Thuillier
Hola Luis!
Si quieres que máquinas externas al dominio puedan acceder a la CRL, AIA o OCSP de la SubCA tendrás que publicarlos mediante IIS, de igual forma que en la guía lo hice para la RootCA, pero en tu caso para la SubCA.
Un saludo!
Muchas gracias, ya nos funciona.
¿Es posible mediante comando en PowerShell actualizar datos de revocación
en el respondedor en línea?. una vez mas gracias por tu inestimable ayuda.
Me alegro Luis, con respecto a powershell y el OCSP en este blog hay info muy buena: https://www.sysadmins.lv/blog-en/managing-online-responders-ocsp-with-powershell-part-1.aspx , en la parte 2 también tienes mas info.
Saludos!
Muchas gracias, una vez mas,
Hemos visto la documentación que nos dices y parece que entendemos que nos es posible actualizar la matriz del respondedor en linea si no es mediante la consola, ¿es cierto?.
En los comentarios, hay uno que dice solucionarlo mediante NONCE, para que la revocación sea inmediata. ¿ Es así?
Saludos.Luis
Hola Luis, hasta donde yo sé, el refresh sólo es posible desde la mmc, o sea, gráficamente. Lo de la extensión Nonce lo he visto en algunas organizaciones, pero no lo he implementado. Sé que es un método que incrementa la seguridad ante replay attacks ya que inhabilita las respuestas cacheadas (ojo con esto porque incrementa notablemente la carga del OCSP responder), y seguramente al invalidar las respuestas cacheadas tiene que ser inmediato. Creo recordar también que no todos los clientes soportaban este tipo de extensión en los request.
Aquí tienes mas info sobre nonce:
https://www.sysadmins.lv/blog-en/ocsp-client-tool-advanced-stuff.aspx
Espero te sea de ayuda!
Muchas gracias Jose Ramon,
le hecho un vistazo y ya te comento
Hola,
He seguido todo el tutorial, y hasta ahora todo me funciona bien. me gustaría que me ayudaras con algunos temas. Cómo te puedo consultar para contratar asesorioas?
Hola, me alegro que te haya servido, no he pensado sobre realizar asesorías, pero que necesitas?
Saludos,