Windows Server 2025 / Qué hace AD CS y cómo planificar una PKI interna

Active Directory Certificate Services (AD CS), los servicios de certificados de Active Directory, emite y administra certificados de una organización. Antes de instalarlo debe diseñar a quién se dará confianza, quién podrá solicitar y aprobar certificados, y cómo se gestionarán revocación, renovación, recuperación y responsabilidades.

Decidir si necesita una CA interna

AD CS permite operar una autoridad certificadora (CA) dentro de una infraestructura de clave pública (PKI). La CA firma certificados que vinculan identidades con claves públicas; la PKI añade políticas, protección de claves, distribución de confianza y procesos para que ese vínculo sea utilizable. El cliente debe confiar en la autoridad y validar nombre, propósito, vigencia y condiciones aplicables; disponer de un archivo de certificado no basta.

La renovación repetida de servicios internos o la autenticación de dispositivos administrados pueden justificar una PKI organizacional. Una CA interna no es automáticamente confiable para cualquier navegador o dispositivo externo. Para un servicio público usado por clientes no administrados puede encajar mejor un certificado públicamente confiable para un nombre controlado. Compare estas necesidades con los recursos de operación: un certificado autofirmado de laboratorio no crea una PKI de producción.

La descripción general de AD CS presenta sus funciones. Antes de crear otra CA inventaríe PKI ya existente, equipos responsables y servicios de emisión aprobados. Por ejemplo, para pasar de la prueba HTTPS de WEB1 a un servicio interno, documente nombre DNS, consumidores, propietario, plazo de renovación y emisor existente que puede atenderlo. Una sola web no justifica automáticamente instalar una nueva CA.

Definir jerarquía y límites de confianza

Una raíz desconectada y una CA emisora en línea son una opción de diseño, no una receta universal. La raíz establece la confianza superior; una emisora subordinada firma los certificados previstos. Desconectar la raíz reduce su exposición cotidiana, pero exige procedimientos para activarla de forma controlada, publicar lo necesario, renovar y recuperar. Más niveles aumentan también dependencias y trabajo; evalúelos frente a escala, amenazas y capacidad real de mantenerlos.

Las consideraciones de diseño PKI ayudan a fijar nombres de CA y servidor, proveedores criptográficos compatibles, protección de claves, vigencias y direcciones de publicación antes de instalar. No use el nombre del servidor y el de la CA como conceptos intercambiables ni trate el cambio de nombre de un servidor CA instalado como un ajuste rutinario. Separar gestión y protección de claves importa antes de combinar CA y controlador de dominio: concentrar esas funciones une límites de privilegio y recuperación.

Limitar plantillas y permisos de inscripción

Las plantillas definen propósito, política de claves, vigencia y condiciones de inscripción. Extended Key Usage (EKU), uso mejorado de clave, identifica finalidades como autenticación de servidor o cliente. Según la gestión de plantillas AD CS, las CA empresariales usan plantillas almacenadas en los Servicios de dominio de Active Directory (AD DS); las independientes no. Crear una plantilla, publicarla en una CA y permitir inscripción son decisiones distintas. Una emisión amplia de certificados capaces de autenticar identidades puede permitir suplantación.

• Separe solicitantes de quienes aprueban y emiten. Defina grupos concretos y quién puede modificar la política; no use una cuenta compartida para todas las funciones.
• Decida si el solicitante puede proporcionar nombres y quién validará que tiene derecho a usarlos. Para un certificado web, el nombre autorizado debe corresponder al servicio previsto, no a cualquier identidad introducida libremente.
• Limite quién usa las claves privadas y justifique si necesitan ser exportables. Distinga clave de servidor, clave de CA y material de recuperación; documente destinatarios y custodia antes de permitir exportación.
• Limite inscripción automática a grupos y propósitos aprobados. Prevea un piloto que pruebe tanto solicitantes permitidos como no permitidos y registre errores, certificados emitidos y alertas, sin activar primero un alcance general.

Revise el riesgo antes de dar permisos amplios a Authenticated Users u otro grupo numeroso. Asigne por escrito solicitante, administrador de plantillas, administrador de CA, gestor que aprueba o revoca y auditor, separando funciones según el riesgo. La guía de seguridad, delegación y auditoría de CA distingue estos controles: leer evidencia no requiere conceder administración total. Defina qué operaciones permitidas y denegadas se probarán y qué cambios o emisiones producirán una alerta revisable.

Operar publicación de revocación y renovación

Planifique la revocación ante una clave comprometida, salida de un usuario o retirada de un servidor. Una lista de revocación de certificados (CRL) publica certificados revocados. Authority Information Access (AIA), acceso a información de la autoridad, facilita localizar información del emisor, como el certificado de la CA; los puntos de distribución de CRL (CDP) indican dónde obtener listas de revocación. Cadena y estado de revocación son comprobaciones distintas. Especifique las rutas efectivas, quién publica, frecuencia, vencimiento de las listas y clientes que deben alcanzarlas.

DNS o publicación LDAP solo internos pueden no servir a clientes externos o no unidos al dominio. Compruebe acceso con el dispositivo y contexto reales, incluidos proxy y restricciones de red. Detener la CA no revoca inmediatamente todos los certificados emitidos, pero interrumpe funciones distintas como emitir, renovar o actualizar información de revocación. La vigencia de CRL, cachés y política de cada aplicación condiciona el resultado: no prometa continuidad por el mero hecho de que los certificados aún no caducaron. Cambiar una URL de publicación afecta a certificados nuevos; los ya emitidos pueden seguir necesitando la ubicación antigua.

Coordine renovación de raíz, emisoras y certificados de servicio. Pedir una duración larga para un certificado no anula la vigencia restante de su emisor ni las políticas aplicables. Registre dependencia, dueño, fecha de actuación y validación de la nueva cadena. Después de renovar un servicio, compruebe el certificado que realmente presenta y su enlace, no solo el objeto nuevo del almacén. Si también cambia la clave o cadena de la CA, planifique distribución y compatibilidad de los clientes antes de retirar lo anterior.

Documentar protección de claves y recuperación

Comprometer la clave privada de una CA afecta a todo su ámbito de confianza. Evalúe un módulo de seguridad de hardware (HSM), un dispositivo dedicado para protección y operaciones de claves, junto con accesos administrativos restringidos y responsabilidades separadas; el HSM no sustituye procedimientos ni copias recuperables. La guía de respaldo y migración de CA identifica base de datos, claves privadas, configuración del registro, CAPolicy.inf si se utiliza y lista de plantillas asignadas de una CA empresarial. Las plantillas y sus asociaciones en AD DS no quedan cubiertas solo por la base de datos de CA. Diseñe respaldo protegido, custodia de contraseñas y recuperación aislada; para claves en HSM siga además el método compatible del proveedor. Una copia del certificado público no respalda la clave privada.

1. Inventaríe consumidores, propósito y demanda esperada. Para cada servicio anote nombres, dispositivos y usuarios clientes, emisor actual, responsable, dependencia de red y necesidad de continuidad.
2. Asigne un propietario y compare reutilizar la PKI o emisión aprobada existente con crear una nueva. Deje una decisión motivada, recursos operativos y asuntos pendientes, no solo la selección de una casilla del instalador.
3. Diseñe raíz y emisoras, protección de claves, plantillas cuando correspondan, permisos y distribución de confianza. Incluya quién podrá solicitar, aprobar, cambiar y auditar, y cómo se retirará confianza al terminar el servicio.
4. Defina publicación de CRL/AIA, responsables de renovación, alertas, respaldo y recuperación aislada. Especifique ubicaciones y evidencias que se verificarán, incluyendo continuidad de URLs antiguas y recuperación del material protegido.
5. Valide en un entorno separado una solicitud autorizada y otra no autorizada, nombres correctos y rechazados, renovación, revocación según la aplicación y recuperación desde el respaldo. Documente resultado esperado, observado y acción ante fallos; una emisión exitosa no valida todas las demás condiciones.

El resultado de este ejercicio es un documento de diseño revisable, no una CA instalada. No instale AD CS en DC1 ni distribuya una raíz de prueba a equipos reales. Para decidir el despliegue deben quedar resueltos responsables, procedimientos mantenibles, evidencia de aceptación y un plan de retirada de confianza o transición del servicio. Si aún no se sabe quién publicará CRL, recuperará las claves o atenderá una renovación fallida, registre esa decisión pendiente antes de autorizar la instalación.