Deseño de modelos de AD CS para os roles de pasarela VPN e cliente

Unha CA de empresa pode emitir todos os certificados que necesita unha VPN sen ser nunca a pasarela. O traballo de deseño consiste en decidir que debe demostrar cada par e, despois, que modelo pode emitir unha credencial que demostre exactamente iso. Comezo cunha táboa de roles, duplico un modelo axeitado en lugar de editar un no seu sitio, fixo a orixe do suxeito por rol, publico o resultado na CA emisora e inscribo un piloto antes de que ninguén o automatice. Cada paso de abaixo é un punto onde unha CA que funciona aínda produce un certificado que a VPN rexeitará.

Escriba a táboa de roles antes de abrir a consola de modelos

Dous roles, dous propósitos. A pasarela demostra unha identidade de servizo, así que o seu certificado necesita Server Authentication (1.3.6.1.5.5.7.3.1), un uso de clave de sinatura dixital e cifrado de clave, e o nome de host ao que marcan os clientes dentro dun nome alternativo do suxeito. Os clientes que se autentican con certificados necesitan Client Authentication (1.3.6.1.5.5.7.3.2) e unha identidade que coincida co que a pasarela espera na súa comprobación do par. Un certificado de usuario e un certificado de equipo non son intercambiables, porque viven en almacéns distintos e úsanos procesos distintos.

Anote catro columnas por rol: a identidade que debe aparecer, o propósito, o consumidor da clave e se a clave pode saír da máquina. Esa táboa decide cada caixa máis adiante e tamén é o que se entrega a un revisor. A autenticación de clientes con contrasinal é unha rama aparte: se a pasarela autentica usuarios con credenciais, distribuír certificados de cliente engade traballo sen engadir ningunha proba.

Duplique un modelo en lugar de editar un compartido

Parta dun modelo co propósito aproximadamente correcto, como RAS and IAS Server para a pasarela ou Computer para dispositivos unidos ao dominio, logo duplíqueo e dea á copia un nome que diga para que serve. Ampliar un modelo que outros servizos xa usan é o cambio que rompe algo non relacionado seis semanas despois. Na copia, fixe as políticas de aplicación ao propósito da táboa de roles, manteña o uso de clave coherente con el, escolla o algoritmo e a lonxitude de clave que aceptan as súas pasarelas e marque a clave privada como non exportable salvo que un aparello necesite exportala para movela.

A validez e a renovación tamén pertencen ao modelo. Unha vida curta é máis fácil de revogar e máis difícil de operar; unha longa reduce o traballo de inscrición e alonga a exposición dunha clave filtrada. Escolla un número que poida defender e teña en conta que a validez propia da CA e o período de renovación do modelo poden acurtar o resultado.

Decida de onde vén o suxeito

Para un equipo ou usuario de dominio, constrúa o suxeito a partir da información do directorio para que o solicitante non poida escribir o nome. Para unha pasarela que non está unida ao dominio, ou un dispositivo cuxa identidade se asigna fóra de AD, o modelo necesita en cambio un camiño de solicitude controlado. Habilitar o suxeito e os nomes alternativos proporcionados polo solicitante é unha decisión real: non é unha licenza para que cada inscrito reclame calquera nome, e a política do lado da CA aínda ten que dicir quen pode pedir e que evidencia se require.

Windows IKEv2 é estrito aquí. O certificado da pasarela compárase co nome que configurou o cliente, así que o nome DNS debe estar presente onde o cliente o busca, normalmente unha entrada dNSName no nome alternativo do suxeito. Desactivar a comprobación de nome ou de propósito para que funcione un certificado que non coincide elimina a comprobación que tería detectado a discrepancia en produción.

Publique o modelo e logo restrinxa os permisos

Crear o obxecto de modelo en AD DS e publicalo na CA emisora son operacións separadas, feitas desde consolas distintas. Publique a copia desde a consola Certification Authority en Certificate Templates e logo verifique desde a liña de comandos que a CA xa a ofrece:

certutil -CATemplates
certutil -TCAInfo

Os permisos veñen despois. Conceda Read e Enroll aos grupos que deben solicitalo e nada máis, manteña intacto o acceso de lectura da propia CA e conceda Autoenroll só onde a inscrición automática é intencionada e está respaldada pola política de despregamento que a fai funcionar. Unha caixa do modelo non inscribe nada por si soa, e un modelo publicado sen permiso de inscrición produce un portal que lista o certificado e logo rexeita a solicitude.

Inscriba un piloto no consumidor real

Solicite o certificado no contexto que o vai usar e logo examine o que volveu en lugar de confiar no nome do ficheiro. Un certificado de usuario acaba no almacén do usuario actual e un de equipo no almacén do equipo local, e MMC mostra ambos, por iso unha inscrición que “funcionou” pode seguir sendo invisible para o servizo VPN.

certlm.msc
certutil -dump vpn-gateway.cer

Lea o volcado en busca do suxeito, os nomes alternativos, o uso de clave mellorado e a cadea. Para unha pasarela que non é Windows, envíe a solicitude polo fluxo de traballo admitido en lugar de supor que a inscrición automática do dominio chega ata ela, e confirme que o formato exportado é un que o consumidor importa xunto coa súa clave privada correspondente. Por último, manteña a confianza e a autorización separadas: a VPN aínda ten que decidir que usuarios ou dispositivos chegan a que recursos, e a revogación só quita acceso se a pasarela comproba a revogación. A guía de Microsoft para xestionar modelos de certificados cobre a consola de modelos, os permisos e o paso de publicación separado.