Adicionar um cliente VPN sem reconstruir a CA: quando e como

Precisa de mais um certificado para mais um portátil, e o primeiro tutorial dos resultados de pesquisa começa com um comando que apaga a diretoria da PKI. Esse comando pertence à configuração inicial, não à inscrição, e executá-lo custa-lhe a CA, o histórico de emissões e todos os perfis de cliente que confiavam no emissor antigo. A decisão à sua frente é mais estreita: o seu emissor existente ainda tem estado utilizável, e o novo dispositivo encaixa na política de inscrição que já aplica? Três condições decidem-no, e apenas uma delas alguma vez justifica uma reconstrução.

O que uma reconstrução realmente destrói

Reinicializar uma PKI substitui a diretoria por uma estrutura em branco: nova chave e certificado da CA, base de dados de emissões vazia, contador de números de série novo. Os clientes não seguem em silêncio. Os seus perfis fixam a CA antiga, por isso todos os dispositivos existentes têm de se inscrever de novo, e qualquer dispositivo que não seja alcançável tem de ser inscrito de novo à mão ou substituído.

A perda mais silenciosa é a contabilidade. A revogação depende de saber que números de série emitiu e a quem. Limpe o índice e ainda consegue assinar certificados, mas deixa de conseguir dizer com confiança quais dos pendentes pretendia revogar. Uma diretoria de CA com certificados mas sem o estado do emissor correspondente é uma cópia de segurança que restaura a metade errada do sistema.

Copiar a chave privada da CA para junto do servidor em funcionamento é o outro atalho que vale a pena recusar. Transforma uma autoridade de assinatura que devia estar offline ou num armazenamento protegido em mais um ficheiro num anfitrião que termina tráfego não fidedigno.

Condição um: o estado do emissor ainda está acessível?

Encontre a diretoria em que o servidor realmente confia antes de decidir seja o que for. Compare o certificado que o servidor apresenta como a sua CA com o da sua diretoria PKI, por impressão digital, não por nome de ficheiro:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

Se as duas impressões digitais coincidirem, a inscrição é incremental por predefinição e não deve estar a reconstruir nada. Se diferirem, está prestes a assinar com uma CA em que o servidor não confia, o que produz um certificado que se instala sem erros e falha no handshake, e essa falha em particular é mal diagnosticada como um erro do cliente durante horas.

Depois procure o estado de emissão: o ficheiro de índice, o contador de números de série e o ficheiro do número da CRL que as ferramentas da CA utilizam. Se o índice desapareceu mas a chave sobrevive, ainda pode emitir, mas herda um problema de registo de revogações. Registe isso no registo de alterações em vez de o disfarçar, porque o próximo pedido de revogação vai revelá-lo.

Condição dois: quem guarda a nova chave privada?

É esta a decisão que os utilizadores sentem, por isso decida-a explicitamente. Uma chave gerada pelo cliente, submetida como pedido, mantém a metade privada no dispositivo desde o primeiro comando e significa que o administrador nunca lhe toca. Uma chave gerada no servidor é mais fácil para dispositivos cujas ferramentas não conseguem produzir um pedido, mas torna o administrador o depositário de todas as chaves de cliente e alarga o raio de impacto de um compromisso do servidor.

Com o Easy-RSA 3 contra uma CA existente, importar e assinar um pedido são dois comandos:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

Escolha o tipo de certificado de forma deliberada. Um pedido assinado como certificado de servidor em vez de certificado de cliente produz um ficheiro que parece bem e é recusado pelo par, e a mensagem de erro raramente diz porquê. Se estiver a assinar com openssl ca, a mesma escolha vive nas extensões que passa, não na secção predefinida que herdou.

Condição três: o servidor precisa de mais do que um certificado?

Para um servidor OpenVPN simples com autenticação por certificado, o certificado é a inscrição: o nome comum torna-se a identidade do cliente, e qualquer diretoria por cliente, rota empurrada ou endereço estático é indexado a esse nome. Adicione o certificado e esqueça a configuração de cliente correspondente, e o túnel liga enquanto as rotas de que o utilizador precisa nunca aparecem.

As plataformas mudam isto. O OpenVPN Access Server mantém a sua própria base de dados de utilizadores, por isso um certificado assinado não é uma conta de utilizador; a conta tem de existir e estar autorizada antes de qualquer certificado contar. Outros gateways mapeiam uma cadeia de identidade para um grupo. Inscrever um dispositivo significa normalmente tocar em dois sistemas, e o certificado é apenas o primeiro.

O procedimento incremental, e quando faz sentido reconstruir

A sequência que adiciona um dispositivo sem danos colaterais é esta: confirmar o emissor por impressão digital, tirar uma cópia de segurança nova da diretoria PKI, importar e assinar o pedido para o papel de cliente, entregar o certificado com a sua cadeia pelo canal aprovado e depois verificar antes de o utilizador ligar:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

A linha de propósito deve mostrar SSL client. Termine atualizando a cópia de segurança da CA depois da emissão, porque uma cópia tirada antes de o novo número de série ser registado restaura um estado que não inclui o dispositivo que acabou de adicionar.

Uma reconstrução é a decisão certa em três situações: a chave da CA está comprometida, o estado de emissão está irreversivelmente perdido, ou está deliberadamente a mudar o algoritmo de chave ou a política de certificados. As três são projetos com um plano de reinscrição para cada cliente, não passos de um pedido de um dispositivo. Se nenhuma se aplicar, inscreva de forma incremental e deixe o emissor existente em paz.