Diseño de plantillas de AD CS para roles de puerta de enlace VPN y cliente

Una CA de empresa puede emitir todos los certificados que necesita una VPN sin ser nunca la puerta de enlace. El trabajo de diseño consiste en decidir qué debe demostrar cada par y, después, qué plantilla puede emitir una credencial que demuestre exactamente eso. Empiezo con una tabla de roles, duplico una plantilla adecuada en lugar de editar una en su sitio, fijo el origen del sujeto por rol, publico el resultado en la CA emisora e inscribo un piloto antes de que nadie lo automatice. Cada paso de abajo es un punto donde una CA que funciona todavía produce un certificado que la VPN rechazará.

Escriba la tabla de roles antes de abrir la consola de plantillas

Dos roles, dos propósitos. La puerta de enlace demuestra una identidad de servicio, así que su certificado necesita Server Authentication (1.3.6.1.5.5.7.3.1), un uso de clave de firma digital y cifrado de clave, y el nombre de host al que marcan los clientes dentro de un nombre alternativo del sujeto. Los clientes que se autentican con certificados necesitan Client Authentication (1.3.6.1.5.5.7.3.2) y una identidad que coincida con lo que la puerta de enlace espera en su comprobación del par. Un certificado de usuario y un certificado de equipo no son intercambiables, porque viven en almacenes distintos y los usan procesos distintos.

Anote cuatro columnas por rol: la identidad que debe aparecer, el propósito, el consumidor de la clave y si la clave puede salir de la máquina. Esa tabla decide cada casilla más adelante y también es lo que se entrega a un revisor. La autenticación de clientes con contraseña es una rama aparte: si la puerta de enlace autentica usuarios con credenciales, distribuir certificados de cliente añade trabajo sin añadir ninguna prueba.

Duplique una plantilla en lugar de editar una compartida

Parta de una plantilla con el propósito aproximadamente correcto, como RAS and IAS Server para la puerta de enlace o Computer para dispositivos unidos al dominio, luego duplíquela y dé a la copia un nombre que diga para qué sirve. Ampliar una plantilla que otros servicios ya usan es el cambio que rompe algo no relacionado seis semanas después. En la copia, fije las directivas de aplicación al propósito de la tabla de roles, mantenga el uso de clave coherente con él, elija el algoritmo y la longitud de clave que aceptan sus puertas de enlace y marque la clave privada como no exportable salvo que un dispositivo necesite exportarla para moverla.

La validez y la renovación también pertenecen a la plantilla. Una vida corta es más fácil de revocar y más difícil de operar; una larga reduce el trabajo de inscripción y alarga la exposición de una clave filtrada. Elija un número que pueda defender y tenga en cuenta que la validez propia de la CA y el periodo de renovación de la plantilla pueden acortar el resultado.

Decida de dónde viene el sujeto

Para un equipo o usuario de dominio, construya el sujeto a partir de la información del directorio para que el solicitante no pueda escribir el nombre. Para una puerta de enlace que no está unida al dominio, o un dispositivo cuya identidad se asigna fuera de AD, la plantilla necesita en cambio una ruta de solicitud controlada. Habilitar el sujeto y los nombres alternativos proporcionados por el solicitante es una decisión real: no es una licencia para que cada inscrito reclame cualquier nombre, y la directiva del lado de la CA todavía tiene que decir quién puede pedir y qué evidencia se requiere.

Windows IKEv2 es estricto aquí. El certificado de la puerta de enlace se compara con el nombre que configuró el cliente, así que el nombre DNS debe estar presente donde el cliente lo busca, normalmente una entrada dNSName en el nombre alternativo del sujeto. Desactivar la comprobación de nombre o de propósito para que funcione un certificado que no coincide elimina la comprobación que habría detectado la discrepancia en producción.

Publique la plantilla y luego restrinja los permisos

Crear el objeto de plantilla en AD DS y publicarlo en la CA emisora son operaciones separadas, hechas desde consolas distintas. Publique la copia desde la consola Certification Authority en Certificate Templates y luego verifique desde la línea de comandos que la CA ya la ofrece:

certutil -CATemplates
certutil -TCAInfo

Los permisos vienen después. Conceda Read y Enroll a los grupos que deben solicitarla y nada más, mantenga intacto el acceso de lectura de la propia CA y conceda Autoenroll solo donde la inscripción automática es intencionada y está respaldada por la directiva de implementación que la hace funcionar. Una casilla de la plantilla no inscribe nada por sí sola, y una plantilla publicada sin permiso de inscripción produce un portal que lista el certificado y luego rechaza la solicitud.

Inscriba un piloto en el consumidor real

Solicite el certificado en el contexto que lo va a usar y luego examine lo que volvió en lugar de confiar en el nombre del archivo. Un certificado de usuario acaba en el almacén del usuario actual y uno de equipo en el almacén del equipo local, y MMC muestra ambos, por eso una inscripción que “funcionó” puede seguir siendo invisible para el servicio VPN.

certlm.msc
certutil -dump vpn-gateway.cer

Lea el volcado en busca del sujeto, los nombres alternativos, el uso de clave mejorado y la cadena. Para una puerta de enlace que no es Windows, envíe la solicitud por el flujo de trabajo admitido en lugar de suponer que la inscripción automática del dominio llega hasta ella, y confirme que el formato exportado es uno que el consumidor importa junto con su clave privada correspondiente. Por último, mantenga la confianza y la autorización separadas: la VPN todavía tiene que decidir qué usuarios o dispositivos llegan a qué recursos, y la revocación solo quita acceso si la puerta de enlace comprueba la revocación. La guía de Microsoft para administrar plantillas de certificados cubre la consola de plantillas, los permisos y el paso de publicación separado.