Um CSR sozinho não é inscrição: o que uma CA de VPN deve verificar
Um pedido de assinatura prova apenas a posse da chave e mais nada. Compare os modelos de inscrição pelo que eles vinculam antes de a CA conceder acesso à VPN.
Um pedido de assinatura de certificado traz uma chave pública e um assunto solicitado, assinados com a chave privada correspondente. Essa assinatura prova que o solicitante possui a chave. Não prova que ele tem direito ao nome, ao dispositivo ou à função de VPN pedidos, e tratá-lo como se provasse é exatamente como um ticket de help desk se torna uma concessão de acesso.
Vale comparar dois modelos de inscrição pelo que eles vinculam, não pelo protocolo que falam.
Um pedido afirma um nome, não o prova
Leia o pedido pelo que ele realmente contém: uma chave pública, um assunto escolhido pelo solicitante e uma autoassinatura sobre ambos. Nada nessa estrutura remete ao seu inventário, ao diretório de contas ou ao fluxo de aprovação. Um assunto como cn=finance-laptop é uma string que alguém digitou. Até que o processo de emissão verifique essa string contra um registro confiável, o certificado é uma afirmação com uma assinatura anexada. Essa distinção é a razão inteira de existir um processo de inscrição.
O corolário importa operacionalmente. Uma autoridade de certificação nunca precisa da chave privada do cliente para emitir um certificado, e um fluxo que a pede confundiu assinatura com custódia de chaves. Mantenha a geração no endpoint e envie apenas a metade pública.
Compare os modelos pelo que eles vinculam
A assinatura manual vincula o que o operador lembra de verificar. Um serviço de inscrição automatizado vincula um pedido autenticado a uma decisão que o serviço pode impor, e RFC 7030 descreve um projeto assim em que o cliente se autentica antes de um certificado ser devolvido. A diferença que sobrevive a uma auditoria não é a automação; é se a verificação de identidade acontece dentro do caminho de emissão ou ao lado dele.
Ambos os modelos ainda precisam responder às mesmas três perguntas. Quem pergunta, em que dispositivo ou função, e por quanto tempo. Um sistema de tickets que registra as respostas faz trabalho real; uma fila em que alguém encara um nome comum não, por mais cuidado com que o certificado seja formatado depois.
Escolha o modelo pelo número de inscrições esperadas e pela rotatividade dos dispositivos. Alguns servidores por ano sobrevivem a uma revisão manual com uma lista de verificação escrita. Uma frota de notebooks não.
Registre o ciclo de vida desde a primeira emissão
Guarde o identificador do certificado, o proprietário, o uso pretendido, a validade e o caminho de remoção no momento da emissão, não no primeiro incidente. O uso pretendido pertence ao próprio certificado por meio de um uso estendido de chave, e o registro deve concordar com ele. Um certificado criado para autenticação de clientes não deve ser indistinguível de um para servidor.
Planeje a renovação e a revogação de um dispositivo perdido antes de emitir o décimo perfil. Um certificado compartilhado por um departamento transforma uma remoção pontual em interrupção, e revisar essa decisão agora custa muito menos do que durante um incidente de sexta-feira.
Verifique o certificado emitido, depois o acesso
Após a inscrição, inspecione o que foi emitido e confirme que ele encadeia até a autoridade esperada. Dois comandos cobrem os erros comuns: um certificado com o uso errado e uma cadeia que só funciona porque o cliente está configurado para ignorar a validação.
openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt
Depois teste o acesso, não o artefato. Um certificado estabelece identidade, e a política ainda decide quais serviços essa identidade pode alcançar. Verifique os dois, porque um artefato correto com uma política ampla demais também reprova numa revisão. Confirme que o cliente se autentica e recebe apenas as rotas ou os recursos previstos. Anote o que você observou, não o que o perfil deveria fazer.
Um perfil que funciona pelo motivo errado, como um nome comum correspondente e nenhuma verificação de identidade, continuará funcionando depois que o controle que você achava ter for removido.