Hola, soy Aarón de nuevo y en esta segunda parte de la serie de PKI voy a implementar la Root CA.
La primera parte de esta serie se encuentra aquí.
Ya está claro que queremos al menos dos niveles de PKI, por lo que la Root CA debe de desplegarse:
- Standalone: en grupo de trabajo, sin unir al dominio
- Offline: una vez desplegada la PKI, la Root CA se desconecta y se guarda en un lugar seguro.
Ya he desplegado el dominio con un DC, que también es servidor DNS y DHCP. He desplegado una máquina virtual para convertirla en la Root CA, la he nombrado RootCA y la he dejado unida al WORKGROUP. Esta VM está conectada al mismo switch virtual que el dominio, para simplificar. En un entorno en producción es posible que ni siquiera esté conectada a ninguna red.
NOTA: la VM que he desplegado es con el Shell gráfico , también podría ser una VM CORE, pero al administrar ADCS remotamente faltan algunas opciones en la consola, así que para algunas acciones nos vamos a ver obligados a utilizar Certutil o PowerShell. Además, si la CA va a estar desconectada de la red, no la vamos a administrar remotamente, y probablemente prefiramos poder administrarla con la consola de ADCS. Yo, al menos para el blog, prefiero instalar la GUI.
Primero, es bastante probable que queramos usar el archivo capolicy.inf para configurar la Root CA. En este archivo podemos establecer una serie de parámetros en lugar de la configuración por defecto, que de otro modo tendríamos que cambiar después de la instalación. El archivo capolicy.inf se crea en %systenroot%\capolicy.inf y podemos editarlo con Notepad.
Para mi, la forma más rápida de crearlo es directamente con notepad desde CMD o PoweShell:
> notepad c:\windows\capolicy.inf
Para la Root CA voy a establecer los siguientes parámetros. RenewalKeyLength, RenewalValidityPeriod y RenewalValidityPeriodUnits que los explicaré un poco más adelante, y el período de CRL que es el tiempo de expiración de la lista de revocación. Cada vez que expire la CRL tenemos que poner la Root CA online, renovarla y publicarla en dónde corresponda para que esté accesible. Si expira muy rápido nos encontraremos con que estamos encendiendo la Root CA cada dos por tres, y si el tiempo de expiración es muy largo estamos haciendo el entorno menos seguro. Un año debería ser un período aceptable. Darse cuenta de que aunque la Delta CRL está en semanas, lo tengo puesto a 0, por lo que realmente no hay Delta CRL.
[Version] Signature="$Windows NT$" [PolicyStatementExtension] Policies=InternalPolicy [InternalPolicy] OID= 1.2.3.4.1455.67.89.5 Notice="Legal Policy Statement" URL=http://pki.lab.itadmins.es/pki/cps.txt [Certsrv_Server] RenewalKeyLength=4096 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=16 CRLPeriod=Year CRLPeriodUnits=1 CRLDeltaPeriod=Weeks CRLDeltaPeriodUnits=0 AlternateSignatureAlgorithm=0 LoadDefaultTemplates=0 [BasicConstraintsExtension] PathLength=1 Critical=Yes
Voy a instalar el rol con PowerShell, podemos hacerlo con la GUI, pero PowerShell siempre es más interesante. Primero voy a buscar la “feature” que me interesa para la CA:
PS C:\Users\Administrator Get-WindowsFeature *cert*
Display Name Name Install State
------------ ---- -------------
[ ] Active Directory Certificate Services AD-Certificate Available
[ ] Certification Authority ADCS-Cert-Authority Available
Instalo ADCS-Cert-Authority, hay que instalar el rol de ADCS y el de entidad certificadora:
PS C:\Users\Administrator Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Active Directory Certificate Services, Ce...</pre>
True No Success {Remote Server Administration Tools, Activ...
Y siempre está bien comprobar que hemos instalado todo lo que necesitamos al finalizar:
PS C:\Users\Administrator Get-WindowsFeature *cert*
Display Name Name Install State
------------ ---- -------------
[X] Active Directory Certificate Services AD-Certificate Installed
[X] Certification Authority ADCS-Cert-Authority Installed
Ahora hay que configurar la CA. Si abrimos server manager tenemos un aviso para comenzar la configuración:
Voy a configurar el rol a través de la GUI. Primero seleccionamos las credenciales.
Elijo el rol de la CA.
Elijo Standalone CA, ya que no estamos en dominio la opción Enterprise CA no está disponible.
Esta va a ser nuestra Root CA.
Y vamos a crear una private key nueva, ya que es una nueva instalación, no estamos por ejemplo recuperando un backup:
Opciones criptográficas:
- Cryptographic provider: voy a elegir “RSA#Microsoft Software Key Storage Provider”.
Los que incluyen un hash ‘#’ son los cifrados con más nivel de seguridad. - Key length: la longitud de la clave pública/privada. El nuevo estándar es 4096, así que lo cambio para asegurar compatibilidad.
- Hash algorithm: el algoritmo para calcular el hash de la clave. Dejo la configuración por defecto en SHA256. SHA1 y MDX son mala idea, ya que no son seguros y están deprecados.
- Allow administrator interaction… : permite que un administrador haga cambios en estas opciones en el futuro, así que me parece buena idea activarlo.
El common name es el nombre de la Root CA, que no tiene que ver con el nombre de la máquina, y no debería ser el mismo. Por defecto el CN de la CA es %COMPUTERNAME%-CA.
En mi Root CA voy a cambiarlo añadiendo el nombre del blog. Normalmente en CAs públicas vemos el nombre de la compañía, por ejemplo “GeoTrust Global CA”.
Lo siguiente es el tiempo de validez. Este período sólo se aplica para el certificado que se genera durante esta configuración. Anteriormente en capolicy.inf hemos configurado el tiempo de validez de los consiguientes certificados una vez se renueve el certificado expirado, en los parámetros RenewalValidityPeriod y RenewalValidityPeriodUnits.
16 años puede parecer mucho, pero según un estudio de RSA es lo adecuado para claves de 4096. Cuanto más larga, más tiempo es necesario para hackearla.
Estas son las recomendaciones de relación entre longitud de clave y tiempo de validez del certificado:
Key length 1024: Validity period = 12 meses
Key length 2048: Validity period = 2 años
Key length 4096: Validity period = 16 años
Evidentemente, cuanto más largo sea el tiempo de renovación, menos trabajo administrativo, ya que cada vez que tengamos que renovar el certificado hace falta poner la Root CA online, renovarlo, emitir certificados nuevos para las CAs por debajo en la jerarquía de PKI, y así sucesivamente. Generalmente cuanta más seguridad, más trabajo.
En el siguiente paso configuramos la localización de las bases de datos, yo voy a dejar los valores por defecto:
Ya sólo queda confirmar y finalizar la configuración. Usará los valores que hemos elegido durante el Wizard y los que hemos especificado en capolicy.inf.
Y ya podemos ir a la cola de “certification authority” desde server manager o ejecutando certsrv.msc.
Ahora mismo la Root CA ya es funcional, pero tenemos que configurar la ubicación de CDP y AIA. En un momento explico brevemente qué es cada una de ellas, pero es importante entender que antes de instalar la CA subordinada y solicitar el certificado a la Root CA tenemos que configurar ambas extensiones, porque ahora mismo están publicadas de forma local en la Root CA, y cuando todo esté terminado la vamos a desconectar de la red y apagarla. Cada certificado emitido por una CA va a contener información de AIA y CDP, si cambiamos las extensiones a posteriori, los cambios no tendrán efecto en certificados emitidos con anterioridad, por lo que habría que volver a emitirlos.
Yo voy a publicar ambas extensiones por HTTP, en un servidor web IIS, que en este entorno de demostración lo voy a instalar en la propia Sub CA, pero en producción lo mejor es montarlo en al menos dos servidores web con balanceo de carga (NLB, Round Robin o soluciones de terceros como por ejemplo un balanceador Kemp), para asegurar la total disponibilidad. También podemos publicarlas en AD, con el comando certutil -publish. Sea como sea, tenemos que modificar las extensiones CRL y AIA para definir en donde vamos a poner los archivos de cada una de ellas.
AIA: indica la ubicación del certificado de la CA, en formato CRT. Es necesario para que los clientes puedan verificar el certificado y así validar la cadena de confianza.
CDP: indica la ubicación de la CRL y la Delta CRL. La CRL es la lista de revocación de certificados. Una CA puede revocar cualquier certificado que haya emitido, y una vez revocado debe publicarlo en su CRL.
De este modo la Root CA puede revocar los certificados emitidos a la CA subordinada, y ésta puede revocar los certificados que haya emitido a usuarios y máquinas del dominio.
La CRL hay que publicarla cada vez que se revoca un certificado, o cuando la propia CRL va a expirar.
En las propiedades de la CA podemos ver las extensiones:
“Publish” en este contexto significa que se van a crear los archivos correspondientes en esta localización. No podemos publicar en la ruta de HTTP, así que lo normal es colocar los archivos manualmente en el destino, o crear una ruta FILE apuntando al destino para publicarlos.
“Include” significa que la localización se va a incluir en los certificados emitidos por la CA.
Tanto para CDP como para AIA, las únicas localizaciones que me interesan de las que vienen de serie es la que apunta al disco local, C: en este caso. Esta localización no se incluye en el certificado, de hecho no se puede marcar (no tendría sentido) y es donde se van a publicar, es decir crear, los archivos. Así que voy a borrar LDAP, porque no voy a publicar en AD, y también HTTP y FILE, porque apuntan al servidor local y la CA la vamos a apagar.
En su lugar voy a crear las siguientes rutas HTTP:
CDP: http://pki.lab.itadmins.es/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
AIA: http://pki.lab.itadmins.es/pki/<ServerDNSName>_<CaName><CertificateName>.crt
Como podemos ver el nombre de cada archivo se crea con variables, que coinciden con las variables usadas al publicar los archivos. Si quisiéramos podríamos cambiarlo a un nombre fijo y no tendría que haber ningún problema.
Una vez añadidos seleccionamos las opciones para que se incluyan en los certificados emitidos y aplicamos los cambios, lo cual va a requerir reiniciar el servicio de certificados.
Ahora voy a publicar la CRL, que generará el archivo .crl con la lista de revocación y el .crt con el certificado de la CA.
La CRL se publica haciendo click derecho en la carpeta de certificados revocados, en la consola de la CA.
Y los archivos nos los encontramos en la ruta local de C:\ que configuramos en las extensiones de CDP y AIA para publicar los archivos.
Esto es todo por el momento con la Root CA. Las próximas acciones son relativas a configurar el servidor de IIS para hospedar los archivos CRT y CRL que acabamos de crear, en las ubicaciones que hemos configurado anteriormente en las extensiones, pero eso es ya material para el próximo artículo.
Un saludo!
excelente articulo
Gracias!