Como gerar uma chave de cliente VPN e enviar uma CSR para assinatura

Mais cedo ou mais tarde, um usuário de VPN oferece enviar por e-mail uma chave privada para que o administrador possa criar um certificado, e é justamente essa oferta que se deve recusar. O fluxo que funciona mantém a chave no cliente desde o primeiro comando: o cliente a gera, envia uma solicitação de assinatura de certificado, o emissor a verifica e a autoriza, e o certificado assinado volta para ficar ao lado da chave que o criou. A lista de verificação abaixo falha de forma fechada em cada etapa, e esse é o ponto, porque duas das cinco etapas são justamente as que as pessoas pulam quando estão com pressa.

Etapa 1: gere a chave onde ela vai viver

Gere na máquina que vai manter a chave e deixe-a lá. Uma chave de software vai para um arquivo com permissões restritas; uma chave respaldada por hardware ou em um armazenamento gerenciado nunca se torna um arquivo, e seu caminho de inscrição costuma ser uma ferramenta separada e não um comando OpenSSL. De qualquer forma, ninguém precisa ver a metade privada.

O fluxo de software é assim, com a chave e a solicitação criadas em uma única sessão:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

A linha umask importa mais do que parece. Sem ela a chave é escrita legível por todos em um sistema permissivo por padrão, e copiar o arquivo depois espalha isso. Reutilizar uma chave existente é legítimo quando ela já está protegida e atende à sua política; gerar uma nova por dispositivo é mais fácil de justificar.

Etapa 2: coloque a identidade na solicitação, não no e-mail

Decida o que a VPN realmente autentica antes de criar a solicitação, porque essa resposta pertence ao interior da CSR. OpenVPN tradicionalmente vincula a identidade do cliente ao nome comum do certificado, e ferramentas como strongSwan comparam uma cadeia de identidade com o sujeito ou um nome alternativo do sujeito. Um e-mail que diz que meu nome é alice não é prova, e uma solicitação cujo sujeito diz o mesmo é apenas um pouco melhor.

Adicione um nome alternativo do sujeito quando seu verificador verificar um, já que a correspondência moderna costuma ignorar o CN antigo:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

Mantenha o CN curto, estável e ligado à conta em vez de a um modelo de notebook. Um nome que contenha o número de série do dispositivo do usuário é um problema de suporte esperando a primeira substituição de hardware.

Etapa 3: verifique a solicitação antes de assiná-la

O emissor verifica duas coisas diferentes, e confundi-las é o erro clássico. Primeiro, que a solicitação é internamente consistente: a assinatura é verificada contra a chave pública que ela carrega. Segundo, que o solicitante tem direito ao que a solicitação pede, e isso nenhuma verificação criptográfica consegue responder.

A parte mecânica é um único comando, e ele deve imprimir um resultado de verificação junto com o sujeito:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

Observe o que isso prova. Uma solicitação que se verifica mostra apenas que o remetente detinha a chave privada correspondente no momento do envio; não prova que o remetente é a pessoa nomeada no sujeito, e não autoriza o acesso ao grupo ou à rota solicitados. A revisão de inscrição é um portão separado, e uma solicitação de um grupo que ninguém aprovou deveria ser rejeitada em vez de editada em silêncio.

Etapa 4: autorize e depois assine com extensões explícitas

A assinatura é onde a CA decide a política em vez de aceitar a solicitação ao pé da letra. Validade, uso da chave e a extensão de função pertencem a um arquivo de extensões, não a padrões que você não vai lembrar seis meses depois. Um certificado de cliente para autenticação VPN precisa da autenticação de cliente como finalidade.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

Use -CAserial com o arquivo de série existente se já houver um em uso, e mantenha a chave da CA offline ou no armazenamento protegido que sua política nomear. Os números de série dos certificados devem ser únicos por emissor; recriar o arquivo de série do zero arrisca colisões que tornam a revogação ambígua.

Registre o que foi emitido: número de série, sujeito, identidade solicitada, pessoa que aprovou e validade. Esse registro é do que depende depois uma decisão de revogação, e ele não pode ser reconstruído apenas a partir do certificado se o rastro de inscrição viver apenas em uma caixa de correio.

Etapa 5: instale-o ao lado da chave correspondente e comprove o par

O cliente recebe o certificado e a cadeia do emissor, nunca uma chave. Antes de conectar, confirme que o certificado realmente forma par com a chave que já está no disco, porque um par incompatível produz uma falha de handshake confusa muito mais tarde:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

Os dois resumos devem coincidir. Depois conecte e confirme que a identidade que o servidor registra é a que você autorizou, e não apenas que o túnel subiu. Se a chave for perdida ou o dispositivo trocado, a resposta é revogação mais uma nova solicitação do novo dispositivo; pedir ao administrador que devolva uma chave de outro lugar não recupera o original e quebra em silêncio o modelo que tornava a solicitação segura.