Conceber modelos de AD CS para as funções de gateway VPN e cliente

Uma AC empresarial pode emitir todos os certificados de que uma VPN precisa sem alguma vez ser ela própria o gateway. O trabalho de conceção consiste em decidir o que cada par tem de provar e, depois, qual modelo pode emitir uma credencial que prove exatamente isso. Começo por uma tabela de funções, duplico um modelo adequado em vez de editar um no próprio local, fixo a origem do sujeito por função, publico o resultado na AC emissora e inscrevo um piloto antes de alguém o automatizar. Cada passo abaixo é um ponto onde uma AC a funcionar ainda produz um certificado que a VPN vai rejeitar.

Escreva a tabela de funções antes de abrir a consola de modelos

Duas funções, dois propósitos. O gateway prova uma identidade de serviço, por isso o certificado precisa de Server Authentication (1.3.6.1.5.5.7.3.1), de uma utilização de chave de assinatura digital e cifra de chave, e do nome do anfitrião que os clientes contactam num nome alternativo do sujeito. Os clientes que se autenticam com certificados precisam de Client Authentication (1.3.6.1.5.5.7.3.2) e de uma identidade que corresponda ao que o gateway espera na sua verificação do par. Um certificado de utilizador e um certificado de computador não são intermutáveis, porque vivem em arquivos diferentes e são usados por processos diferentes.

Anote quatro colunas por função: a identidade que tem de aparecer, o propósito, o consumidor da chave e se a chave pode sair da máquina. Essa tabela decide cada caixa mais adiante e é também o que entrega a um revisor. A autenticação de clientes por palavra-passe é um ramo separado: se o gateway autentica utilizadores com credenciais, distribuir certificados de cliente acrescenta trabalho sem acrescentar prova.

Duplique um modelo em vez de editar um partilhado

Parta de um modelo com o propósito aproximadamente certo, como RAS and IAS Server para o gateway ou Computer para dispositivos associados ao domínio, duplique-o e dê à cópia um nome que diga para que serve. Alargar um modelo que outros serviços já usam é a alteração que parte algo sem relação seis semanas depois. Na cópia, defina as políticas de aplicação segundo o propósito da tabela de funções, mantenha a utilização de chave coerente com ele, escolha o algoritmo e o comprimento de chave que os seus gateways aceitam e marque a chave privada como não exportável, a menos que um equipamento precise de a exportar para a mover.

A validade e a renovação também pertencem ao modelo. Uma vida curta é mais fácil de revogar e mais difícil de operar; uma longa reduz o trabalho de inscrição e prolonga a exposição de uma chave divulgada. Escolha um número que consiga defender e note que a validade da própria AC e o período de renovação do modelo podem encurtar o resultado.

Decida de onde vem o sujeito

Para um computador ou utilizador de domínio, construa o sujeito a partir da informação do diretório para que o requerente não possa escrever o nome. Para um gateway que não está associado ao domínio, ou um dispositivo cuja identidade é atribuída fora do AD, o modelo precisa em vez disso de um caminho de pedido controlado. Ativar o sujeito e os nomes alternativos fornecidos pelo requerente é uma decisão real: não é uma licença para cada inscrito reclamar qualquer nome, e a política do lado da AC ainda tem de dizer quem pode pedir e que prova é exigida.

O Windows IKEv2 é rigoroso aqui. O certificado do gateway é comparado com o nome que o cliente configurou, por isso o nome DNS tem de estar presente onde o cliente o procura, normalmente uma entrada dNSName no nome alternativo do sujeito. Desativar a verificação do nome ou do propósito para fazer funcionar um certificado que não corresponde elimina a verificação que teria apanhado a discrepância em produção.

Publique o modelo e depois restrinja as permissões

Criar o objeto de modelo no AD DS e publicá-lo na AC emissora são operações separadas, feitas em consolas diferentes. Publique a cópia a partir da consola Certification Authority em Certificate Templates e depois verifique a partir da linha de comandos que a AC já a oferece:

certutil -CATemplates
certutil -TCAInfo

As permissões vêm a seguir. Conceda Read e Enroll aos grupos que devem pedi-lo e nada mais, mantenha intacto o acesso de leitura da própria AC e conceda Autoenroll apenas onde a inscrição automática é intencional e está apoiada na política de implementação que a faz funcionar. Uma caixa do modelo não inscreve nada por si só, e um modelo publicado sem permissão de inscrição produz um portal que lista o certificado e depois recusa o pedido.

Inscreva um piloto no consumidor real

Peça o certificado no contexto que o vai usar e depois examine o que voltou em vez de confiar no nome do ficheiro. Um certificado de utilizador fica no arquivo do utilizador atual e um de computador no arquivo do computador local, e o MMC mostra ambos, por isso uma inscrição que “funcionou” pode continuar invisível ao serviço VPN.

certlm.msc
certutil -dump vpn-gateway.cer

Leia o despejo quanto ao sujeito, aos nomes alternativos, à utilização melhorada da chave e à cadeia. Para um gateway que não é Windows, submeta o pedido pelo fluxo de trabalho suportado em vez de assumir que a inscrição automática do domínio chega até ele, e confirme que o formato exportado é um que o consumidor importa juntamente com a sua chave privada correspondente. Por fim, mantenha a confiança e a autorização separadas: a VPN ainda tem de decidir que utilizadores ou dispositivos chegam a que recursos, e a revogação só retira acesso se o gateway verificar a revogação. O guia da Microsoft para gerir modelos de certificados cobre a consola de modelos, as permissões e o passo de publicação separado.