Administrar certificados y PKI en Windows paso a paso

Cuando en una organización se habla de autenticar usuarios, equipos y servicios en un entorno Microsoft, en realidad se está hablando de infraestructura de clave pública (PKI), certificados digitales y su gestión en Windows. No es un tema trivial: de estos componentes depende que el inicio de sesión, el acceso remoto, las aplicaciones web internas y hasta sistemas como Configuration Manager o un portal GIS funcionen de forma segura.

Una PKI bien diseñada en Windows suele combinar Servicios de certificados de Active Directory (AD CS), controladores de dominio, IIS, DNS, directivas de grupo y, en muchos casos, servicios como AD FS, OCSP o puntos de distribución en la nube. Lo que sigue es una guía amplia, paso a paso y con contexto, que repasa cómo se orquesta todo esto: desde la jerarquía de CA hasta las plantillas de certificado para Windows Hello para empresas, Configuration Manager, dispositivos móviles, Mac y servicios web internos.

Conceptos básicos: PKI, certificados y su papel en Windows

En un entorno Windows, una PKI se apoya típicamente en una jerarquía de entidades de certificación (CA) y en certificados X.509 emitidos para usuarios, equipos y servicios. Estas CA suelen residir en servidores Windows con el rol AD CS instalado.

La CA raíz, normalmente independiente y sin conexión, actúa como ancla última de confianza. Por debajo, una o más CA emisoras empresariales, unidas al dominio, son las que generan los certificados para el día a día: autenticación de estación de trabajo, servidores web, agentes de inscripción, puntos de distribución, etc.

Windows y las aplicaciones que usan Kerberos, SSL/TLS, autenticación con tarjeta inteligente o certificados de cliente confían en estas CA porque su certificado raíz y las CRL (listas de revocación) están publicados en ubicaciones accesibles (LDAP, HTTP, sistema de archivos). Gracias a ello, los equipos pueden validar la cadena de confianza y comprobar si un certificado sigue siendo válido.

Sobre esta base se construyen escenarios más avanzados como Windows Hello para empresas con confianza basada en certificados, Configuration Manager con clientes autenticados por PKI, portales web integrados con Active Directory y validación de estado de certificados mediante OCSP.

Windows Hello para empresas y confianza basada en certificados

En escenarios corporativos modernos, Windows Hello para empresas permite que los usuarios inicien sesión con credenciales multifactor (PIN, biometría) respaldadas por claves criptográficas. Cuando se opta por el modelo de confianza de certificados, se hace imprescindible una PKI empresarial bien montada.

En este modelo, los controladores de dominio necesitan certificados adecuados de autenticación Kerberos que actúan como raíz de confianza para los clientes. Estos certificados permiten que el KDC (Centro de distribución de claves) pruebe su identidad ante los equipos del dominio usando criptografía moderna (RSA 2048 y SHA256, al menos).

En entornos híbridos, la implementación de confianza basada en certificados para Windows Hello para empresas suele implicar que AD FS funcione como entidad de registro (CRA), firmando solicitudes de certificado en nombre de los usuarios. Los usuarios acaban recibiendo certificados de autenticación de usuario que permiten el inicio de sesión contra Active Directory usando sus credenciales de Hello.

Para esto se necesitan tres tipos clave de plantillas de certificado: autenticación Kerberos para controladores de dominio, certificados de agente de inscripción para AD FS y certificados de autenticación específicos de Windows Hello para empresas.

PKI de laboratorio frente a PKI empresarial en producción

Muchas organizaciones comienzan con un montaje sencillo de pruebas antes de desplegar una PKI definitiva. En un entorno de laboratorio se puede instalar una CA empresarial única sobre Windows Server usando, por ejemplo, PowerShell:

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools instala el rol de servicios de certificados, y posteriormente se ejecuta Install-AdcsCertificationAuthority con una configuración básica.

Sin embargo, en un entorno real es mucho más habitual una jerarquía de dos niveles: CA raíz independiente y CA emisora empresarial. La raíz suele estar fuera de línea, no unida al dominio, y solo se enciende para emitir o renovar certificados de CA e incluso CRL de larga duración. La emisora, en cambio, sí se integra con Active Directory y gestiona el grueso de las emisiones diarias.

En ambos casos es necesario configurar de forma cuidadosa las rutas AIA (Authority Information Access) y CDP (CRL Distribution Point), que indicarán dónde se puede obtener el certificado de la CA y las CRL correspondientes, típicamente combinando rutas:

• Ruta local en el sistema de archivos (C:\Windows\System32\CertSrv\CertEnroll)
• LDAP dentro de la partición Configuration de Active Directory
• HTTP publicado en un servidor IIS, normalmente bajo un alias tipo pki.dominio.com/CertEnroll

Certificados de controladores de dominio y autenticación Kerberos

Para que los equipos confíen de forma robusta en los controladores de dominio, no basta con Kerberos «a pelo». Es importante que cada controlador de dominio disponga de un certificado válido de autenticación Kerberos, con un OID EKU específico para esta función.

Las plantillas clásicas de «controlador de dominio» y «autenticación de controlador de dominio» no incluyen el OID añadido posteriormente a la RFC de Kerberos, por lo que se recomienda crear una plantilla nueva basada en la de Autenticación Kerberos, actualizando su criptografía y compatibilidad:

• Compatibilidad con Windows Server 2016 en la CA y Windows 10/Server 2016 en el destinatario.
• Uso de Proveedor de almacenamiento de claves (KSP), algoritmo RSA, tamaño mínimo de 2048 bits y SHA256.
• Asunto construido desde Active Directory, con el nombre DNS incluido en el SAN y sin otros identificadores adicionales.

Una vez creada la plantilla (por ejemplo, «Autenticación de controlador de dominio (Kerberos)»), se marca como plantilla que sustituye a las antiguas de controlador de dominio y autenticación de controlador de dominio. Esto se hace en la pestaña de plantillas reemplazadas, de forma que cuando se publique esta nueva plantilla, cualquier certificado basado en las anteriores acabe siendo reemplazado mediante inscripción automática.

La publicación de la nueva plantilla en la CA emisora y la anulación de publicación de las antiguas plantillas garantizan que no se sigan emitiendo certificados obsoletos. Después, se configura una GPO aplicada a la OU «Controladores de dominio» para activar la inscripción automática de certificados de equipo, de forma que los DC renueven y sustituyan sus certificados de manera transparente.

Plantillas de agente de inscripción y certificados para Windows Hello para empresas

En una implementación de Windows Hello para empresas con confianza basada en certificados, AD FS actúa como entidad de registro (Certificate Registration Authority o CRA). Para poder firmar las solicitudes de certificado, los servidores AD FS necesitan un certificado de agente de inscripción adecuado.

Normalmente se parte de la plantilla «Agente de inscripción de Exchange (solicitud sin conexión)» y se crea una plantilla duplicada adaptada a la cuenta de servicio utilizada por AD FS. Hay dos escenarios típicos:

• Cuenta de servicio administrada de grupo (gMSA): la plantilla debe configurarse con «Suministro en la solicitud» en el nombre del firmante, ya que las gMSA no admiten construcción del sujeto desde Active Directory.
• Cuenta de servicio estándar: se puede usar «Compilar a partir de esta información de Active Directory», con formato de nombre completo (CN) e inclusión de UPN en el SAN.

En ambos casos, la plantilla de agente de inscripción debe usar RSA 2048, SHA256 y proveedor de almacenamiento de claves, y limitar los permisos de inscripción exclusivamente a la cuenta adfssvc (o la que corresponda), deshabilitando Inscribir e Inscripción automática para el resto de grupos.

Con los agentes de inscripción listos, se crea la plantilla de autenticación de Windows Hello para empresas, partiendo de la de «Inicio de sesión de tarjeta inteligente». Algunos puntos críticos en su configuración son:

• Compatibilidad ajustada a Windows Server 2016 / Windows 10 o superior.
• Asunto basado en Active Directory, con Nombre completo y UPN en el SAN.
• Criptografía con RSA 2048 y SHA256.
• Extensión de directivas de aplicación que incluya el inicio de sesión con tarjeta inteligente.
• Requerir al menos una firma autorizada de directiva de aplicación «Agente de solicitud de certificado», asegurando que solo se emiten certificados cuando la solicitud viene firmada por un agente de inscripción válido.
• Control de solicitudes que permita la renovación con la misma clave.
• Permisos de inscripción limitados a un grupo de seguridad con los usuarios que podrán usar Windows Hello para empresas.

Por último, se marca esta plantilla como específica para inicio de sesión Hello ejecutando, desde un símbolo con privilegios elevados, certutil.exe -dsTemplate <NombrePlantilla> msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY. La salida mostrará el valor anterior y el nuevo, donde se añadirá el flag HELLO_LOGON_KEY.

Configuración de autoinscripción y validación en controladores de dominio

Para que los controladores de dominio y demás equipos renueven sus certificados sin intervención manual, se usa la inscripción automática (autoenrollment) mediante directiva de grupo. En un GPO vinculado a la OU de controladores de dominio se activa:

• Renovar certificados expirados y actualizar certificados pendientes.
• Quitar certificados revocados.
• Actualizar certificados que usan plantillas de certificado.

Una vez aplicada la GPO, se puede forzar la actualización con gpupdate /force y provocar la inscripción usando certreq.exe -autoenroll -q. La verificación se realiza por varias vías:

• Visor de eventos en Application and Services Logs > Microsoft > Windows > CertificateServices-Lifecycle-System para comprobar eventos de nueva inscripción y archivo de certificados antiguos.
• certlm.msc para ver certificados de equipo en el almacén «Personal» (aunque aquí no se ven los archivados).
• certutil.exe -q -store my o con la opción -v para información detallada, incluyendo EKU, huella digital y plantilla usada.

La clave es asegurarse de que los nuevos certificados usan la plantilla actualizada de Autenticación Kerberos para controladores de dominio y que contienen los EKU esperados, incluidos los necesarios para autenticación Kerberos en Windows Hello para empresas.

PKI y autenticación integrada de Windows en portales y aplicaciones web

No todo son inicios de sesión de usuario y certificados de máquina. Muchos entornos combinan autenticación integrada de Windows (Kerberos/NTLM) con certificados de cliente para elevar el nivel de seguridad de portales corporativos, por ejemplo en soluciones como ArcGIS Enterprise.

En estos casos se suele desplegar ArcGIS Web Adaptor sobre IIS y configurarlo para usar SSL y autenticación integrada con el almacén de identidades de Active Directory. La PKI entra en juego proporcionando certificados de servidor y, en algunos casos, certificados de cliente para la autenticación mutua.

Los pasos clave pasan por:

• Configurar el portal para que todas las comunicaciones sean HTTPS.
• Apuntar el almacén de identidades del portal a usuarios y grupos de Active Directory.
• Instalar y habilitar en IIS la característica de autenticación de asignaciones de certificado de cliente de Active Directory, que permite mapear certificados a cuentas AD.
• Configurar el adaptador web para requerir certificados cliente y SSL, y controlar qué usuarios pueden crear cuentas integradas o si se fuerza el uso exclusivo de credenciales corporativas.

Configuration Manager y su integración con certificados PKI

System Center Configuration Manager (hoy Microsoft Configuration Manager) saca mucho partido de una PKI corporativa. Los distintos roles (puntos de administración, puntos de distribución, clientes Windows, dispositivos móviles, Mac) pueden autenticarse y cifrar tráfico mediante certificados emitidos por una CA de Windows.

En un laboratorio típico de ejemplo se parte de:

• Un dominio único en Active Directory con Windows Server 2008 o superior.
• Una CA empresarial raíz que emite certificados dentro del dominio.
• Un servidor miembro con IIS donde se instalarán los sistemas de sitio de Configuration Manager.
• Un cliente Windows (por ejemplo, Windows Vista o superior) unido al dominio.

Los certificados implicados abarcan varios tipos: certificados de servidor web para sistemas de sitio, certificados de cliente para equipos Windows, certificados exportables para puntos de distribución (incluidos los basados en la nube), certificados para dispositivos móviles y para clientes Mac.

Certificados de servidor web para sistemas de sitio con IIS

Para proteger los sitios de Configuration Manager en IIS se crea primero un grupo de seguridad de AD con los servidores IIS que actuarán como sistemas de sitio, por ejemplo «ConfigMgr servidores IIS». Después, en la consola de plantillas de certificado de la CA, se duplica la plantilla de «Servidor web» y se ajusta:

• Se le da un nombre representativo (por ejemplo, «ConfigMgr certificado de servidor web»).
• En la seguridad, se quita el permiso Inscribir de Administradores de dominio / empresa y se asigna Inscribir (y Leer) al grupo de servidores IIS de ConfigMgr.

La plantilla se publica en la CA y, desde el servidor IIS, se solicita el certificado mediante la consola MMC de certificados de equipo. Al inscribirse, se rellenan los nombres DNS en el SAN que corresponderán a FQDN de intranet e Internet del sistema de sitio (por ejemplo server1.internal.contoso.com y server.contoso.com).

Una vez instalado el certificado en el almacén Personal del equipo, se va a Administrador de IIS y se vincula el certificado al binding HTTPS del sitio web predeterminado. Así se garantiza que el tráfico de cliente a los roles de sitio se cifra y que el nombre al que se conectan los clientes coincide con el certificado.

Certificados de servicio para puntos de distribución basados en la nube

Cuando se usan puntos de distribución basados en la nube (Cloud DP), se necesita un certificado de servidor web cuya clave privada sea exportable, ya que se subirá a la nube junto con el servicio. Para ello se duplica de nuevo la plantilla de Servidor web:

• Nombre de plantilla como «ConfigMgr Cloud-Based certificado de punto de distribución».
• En Control de solicitudes, se permite exportar la clave privada.
• Permisos de inscripción otorgados a un grupo de servidores de sitio de ConfigMgr.
• Tamaño mínimo de clave en 2048 bits.

Tras publicarla, un servidor de sitio la solicita desde MMC, especificando un nombre común FQDN del servicio cloud (por ejemplo clouddp1.contoso.com). Luego se exporta el certificado a un fichero .PFX, protegiéndolo con contraseña, y se guarda de forma segura para usarlo al crear el punto de distribución en la consola de Configuration Manager.

Certificados de cliente para equipos Windows

Para que los clientes de Configuration Manager se autentiquen frente a los roles de sitio a través de HTTPS, cada equipo necesita un certificado de autenticación de cliente. Se suele partir de la plantilla «Autenticación de estación de trabajo» y crear una copia, por ejemplo «ConfigMgr certificado de cliente».

En esta plantilla se otorga a Equipos de dominio los permisos de Lectura, Inscribir e Inscripción automática. Se publica en la CA, y a continuación se crea un GPO a nivel de dominio que habilite la inscripción automática de certificados de equipo.

Una vez aplicada la directiva, los equipos de dominio solicitarán de forma transparente el certificado de cliente. En MMC de certificados de equipo se puede comprobar que en el almacén Personal aparece un certificado con propósito de autenticación de cliente y plantilla «ConfigMgr certificado de cliente».

Certificados de cliente exportables para puntos de distribución

Los puntos de distribución de Configuration Manager pueden necesitar certificados de cliente exportables para autenticarse frente a otros servicios. En este caso se vuelve a duplicar la plantilla de «Autenticación de estación de trabajo», pero habilitando la exportación de la clave privada y restringiendo los permisos de inscripción a un grupo de servidores IIS de ConfigMgr.

El flujo es muy similar a los puntos de distribución en la nube: el servidor IIS que actuará como DP solicita el certificado, se comprueba que su plantilla sea la correcta y que el propósito incluya autenticación de cliente, y luego se exporta a un PFX con la clave privada para importarlo en la configuración del DP.

Certificados de inscripción y certificados para dispositivos móviles y Mac

Cuando Configuration Manager se usa para administrar dispositivos móviles, se crea una plantilla de certificado de inscripción para usuarios que registrarán dispositivos. Normalmente se basa en la plantilla «Sesión autenticada» y se ajusta:

• Nombre de plantilla tipo «ConfigMgr certificado de inscripción de dispositivos móviles».
• Asunto construido desde AD, con nombre común y sin UPN en el SAN.
• Permisos de Inscribir para un grupo de usuarios con permisos de inscripción de dispositivos.

Para equipos Mac se realiza algo parecido: se duplica la plantilla de «Sesión autenticada» y se crea una plantilla como «ConfigMgr certificado de cliente Mac», asignando permisos de Inscribir solo a un grupo de administradores que se encargarán de la inscripción en Mac. De nuevo, el asunto se construye desde AD con nombre común y sin UPN en el SAN.

Ambas plantillas se publican en la CA y luego se seleccionan en la configuración de cliente de Configuration Manager al definir los perfiles de inscripción para móviles y las opciones específicas para clientes Mac.

Diseño de jerarquía PKI empresarial con CA raíz offline y CA emisora

En entornos empresariales serios no se deja la CA raíz expuesta. Se instala una CA raíz independiente, fuera de línea, no unida al dominio, y una CA emisora empresarial subordinada que sí se integra con Active Directory.

En la CA raíz se prepara un archivo CAPolicy.inf con parámetros como longitud de clave, periodo de validez del certificado de CA y uso (o no) de algoritmos de firma alternativos. Posteriormente se instala el rol de AD CS con tipo de CA independiente y CA raíz, configurando periodos de validez largos (por ejemplo, 20 años) y ubicaciones AIA/CDP apropiadas.

Tras la instalación, se afinan detalles de registro con certutil: CRLPeriodUnits y CRLPeriod (por ejemplo, 52 semanas), parámetros de superposición de CRL para evitar ventanas sin cobertura, y el periodo de validez máximo de los certificados emitidos por esa CA.

Es fundamental activar la auditoría en la CA raíz, habilitando Acceso a objetos en la política de seguridad local y configurando CA\AuditFilter a 127 con certutil para registrar todos los eventos relevantes en el visor de eventos.

Publicación de AIA y CDP mediante IIS y DNS

Para que los clientes puedan recuperar certificados de CA y CRL incluso fuera de la red interna, se implementa un servidor web IIS que publica las rutas HTTP de AIA y CDP. Por ejemplo, un servidor SRV1 con el rol de servidor web y una carpeta compartida C:\CertEnroll.

Se comparte la carpeta CertEnroll otorgando permisos de cambio y modificación al grupo de publicadores de certificados para que la CA pueda publicar ahí sus CRL y certificados. En IIS se crea un directorio virtual «CertEnroll» apuntando a C:\CertEnroll y se habilita la exploración de directorios. Además, se habilita el doble escape en IIS (allowDoubleEscaping) para permitir la publicación de CRL delta y otros archivos con caracteres especiales en las URLs.

En DNS se crea un alias CNAME tipo pki.dominio.com apuntando a SRV1, que será la URL usada en las rutas HTTP de AIA y CDP. De este modo, si en el futuro se cambian los servidores que alojan CertEnroll, se puede redirigir el alias sin tocar los certificados ya emitidos.

Configuración de AIA y CDP en las CA raíz y emisora

Las ubicaciones AIA y CDP se establecen mediante certutil modificando las claves de registro correspondientes. Para AIA se suelen definir tres rutas:

• Sistema de archivos: C:\Windows\System32\CertSrv\CertEnroll\%1_%3%4.crt
• LDAP al contenedor AIA de AD: ldap:///CN=%7,CN=AIA,CN=PublicKeyServices,CN=Services,%6%11
• HTTP público: http://pki.dominio.com/CertEnroll/%1_%3%4.crt

Para CDP se definen rutas análogas, apuntando a CRL base y delta en el sistema de archivos, LDAP y HTTP, e incluso a la carpeta compartida en SRV1 para facilitar la replicación. Tras ajustar estas rutas, se reinicia el servicio de certificados y se publica una nueva CRL con certutil -crl.

En la CA emisora se repite el patrón, cambiando obviamente el nombre de la CA en las rutas. Además, se copia el certificado de la CA emisora a la carpeta CertEnroll en SRV1, de manera que las rutas HTTP queden válidas para toda la cadena.

Instalación de la CA emisora y publicación de la jerarquía

La CA emisora se instala como CA subordinada empresarial en un servidor unido al dominio. Durante la instalación se genera una solicitud de certificado que se lleva a la CA raíz offline, donde se firma y se devuelve como certificado de CA subordinada.

Una vez emitido, se instala el certificado de CA emisora en el servidor subordinado y se inicia el servicio de autoridad de certificación. Debido a la configuración CAPolicy.inf de la emisora, es posible que no se publiquen plantillas predeterminadas por defecto, obligando al administrador a seleccionar explícitamente qué plantillas se van a usar.

Para que la cadena sea visible en toda la organización, se publican el certificado de la CA raíz y su CRL en Active Directory con certutil -dspublish, y se copian ambos archivos a la carpeta CertEnroll en SRV1, garantizando que las rutas LDAP y HTTP se resuelvan correctamente en herramientas como PKIView.msc.

Servicio de respuesta en línea (OCSP) y distribución del estado de revocación

Además de las CRL, muchas organizaciones utilizan OCSP para ofrecer verificación rápida del estado de revocación de certificados. En el servidor web (por ejemplo SRV1) se instala el servicio de rol «Respondedor en línea» de AD CS.

Desde la CA emisora se crea una plantilla de «Firma de respuesta de OCSP» ajustando la seguridad para que la máquina SRV1 pueda inscribirse. Luego se publica en la CA emisora, se configura una nueva «configuración de revocación» en el respondedor en línea y se selecciona:

• La CA emisora empresarial como origen de certificados.
• Un certificado de firma de respuesta, que puede ser emitido automáticamente por la CA.
• Proveedores de revocación que leen CRL desde LDAP y HTTP, con un intervalo de actualización reducido (por ejemplo, cada 15 minutos).

En la CA emisora se añade la URL OCSP (http://srv1.dominio.com/ocsp) en la extensión AIA, marcando únicamente «Incluir en la extensión del protocolo de estado de certificado en línea (OCSP)». Así, todos los certificados nuevos incorporarán la URL del respondedor en línea sin necesidad de reinscribir los ya existentes, aunque para estos últimos se puede usar política de grupo para que los clientes conozcan la URL OCSP.

PKIView.msc (Enterprise PKI) se utiliza para comprobar el estado general de la jerarquía: certificados de CA raíz y emisora, CRL base y delta, y la presencia de los certificados correctos en los contenedores NTAuth, AIA y CDP de Active Directory.

Un entorno PKI bien montado en Windows, con CA raíz offline, CA emisora empresarial, IIS para publicar AIA/CDP, OCSP para verificación de estado, plantillas adaptadas para controladores de dominio, Windows Hello para empresas, Configuration Manager, dispositivos móviles y Mac, y con autoinscripción y auditoría correctamente configuradas, permite que toda la autenticación basada en certificados se integre de manera natural con Active Directory y las aplicaciones corporativas, ofreciendo seguridad fuerte y una administración centralizada.