Hola, soy Aarón y en esta serie de artículos voy a cubrir lo máximo posible sobre PKI con ADCS en Windows Server 2016.

Imagino que si estáis aquí es porque ya sabéis lo que es PKI y ADCS, pero por si acaso voy a dar una explicación muy breve: PKI es la estructura de clave pública, que está compuesta por una o más CA, y las CA son las entidades certificadoras, que emiten y revocan certificados. En Windows Server la CA es un rol de ADCS.

En el diseño de la PKI hay que tomar varias decisiones, como cuántas capas/niveles vamos a tener en la jerarquía, si la CA está unida al dominio y qué cifrados vamos a usar.

Generalmente se implementa una PKI de dos niveles:

1. Root CA en grupo de trabajo (standalone), con el objetivo de mantenerla desconectada: offline Root CA.
2. CA subordinada os Sub CA, miembro del dominio (Enterprise), desde la cual se emitirán los certificados: Issuing CA.

¿Cómo funciona? La CA subordinada solicita su certificado de la Root CA, y el certificado de la Root CA es auto-firmado.

¿Por qué queremos dos niveles? Por seguridad: el certificado de la Root CA es auto-firmado, si la CA se ve comprometida no hay forma de revocarla. Ya veremos cómo funciona la revocación de certificados.

Por supuesto también podemos tener una PKI de 1 sólo nivel, desplegando la Root CA unida al dominio, y usarla para emitir los certificados a los miembros del dominio, con lo que la Root Ca y la Issusing CA serían la misma máquina. Sin embargo, no deberíamos hacer esto excepto en entornos de laboratorio, o en entornos en producción que no requieran seguridad y dónde tengamos recursos limitados. Si los recursos son extremadamente limitados, incluso podemos poner la Root CA en un controlador de dominio.
Para demostrar y explicar todos los conceptos, consideraciones y aspectos técnicos de ADCS, vamos a montar una PKI de dos niveles como descrito anteriormente.

Para el laboratorio voy a usar un host de Hyper-V Windows Server 2016 y las siguientes máquinas virtuales:

• Root CA
• Sub CA/IIS
• AD Domain Controller
• Client Windows 10 para las RSAT

Mapa del laboratorio de ADCS

Características del Host de Hyper-V

Por si a alguien le interesa, yo uso este pequeño script para desplegar nuevas máquinas virtuales rápidamente. Para poder usarlo tendréis que modificar las rutas de acuerdo a las unidades y rutas de vuestro laboratorio, el nombre del Switch y del parent disk, si es que usáis discos diferenciales. Los datos están en variables así que los cambios son más fáciles de hacer.

Click para ver PS Script

# Crear función para mostrar menú.
function Show-Menu
{
cls
Write-Host "1: Pulsa '1' para desplegar VM."
Write-Host "Q: Pulsa 'Q' para salir."
}

do
{
Show-Menu
$input = Read-Host "Elije una opción"
switch ($input)
{
'1' {
cls

# Nombre de la nueva VM
$VM= Read-Host -Prompt 'Nombre de la VM'

# Unidad donde se va a crear el VHD
$Drive="S:"

# Nombre del switch de Hyper-V
$Switch="NATSwitch"

# Parent Disk to use for the diff disk.
$ParentDisk="WinSvr2016_GUI_Parent.vhdx"

# Crear nuevo disco de diferencias
New-VHD -Path $Drive\Hyper-V\VHDs\$VM.vhdx -Differencing -ParentPath $Drive\Hyper-V\VHDs\$ParentDisk

# Crear la VM asigádole el disco creado en el paso anterior
New-VM -Name $VM -VHDPath $Drive\Hyper-V\VHDs\$VM.vhdx -SwitchName $Switch -Generation 2

# Configurar la VM con memoria dinámica
Set-VMMemory $VM -DynamicMemoryEnabled $true

Start-VM $VM
}

'q' {
return
}
}
pause
}
until ($input -eq 'q')

Y esto es todo por ahora, en el siguiente artículo muestro la implementación de la Root CA.

Saludos!

Partes: I, II, III, IV, V, VI.