Porque copiar ca.key para cada cliente VPN destrói a CA

Em algum ponto das instruções de configuração, um diretório é copiado integralmente para cada portátil porque era mais simples do que decidir que ficheiros lhe pertencem. Esse diretório contém ca.key, e no momento em que chega a um segundo dispositivo a autoridade de certificação deixa de ser uma autoridade. Qualquer detentor pode agora emitir identidades em que o resto da rede confiará.

Vale a pena deslindar esta confusão uma vez, porque os dois ficheiros parecem-se e fazem coisas opostas.

Material de verificação e material de assinatura

Um cliente precisa do certificado público da CA para verificar que o certificado apresentado por um par foi assinado por essa autoridade. É uma tarefa de verificação e não exige qualquer segredo. Assinar o certificado de um par é outra tarefa, executada uma única vez por quem opera a CA, com a chave privada que nunca abandona o seu armazenamento protegido. Manter estas duas tarefas separadas é todo o motivo para entregar dois ficheiros.

Assim, ca.crt pertence ao perfil e ca.key não pertence a nenhum lugar próximo. Os nomes dos ficheiros são uma convenção, não uma garantia, e por isso o tipo tem de ser inspecionado em vez de deduzido do nome.

Uma arquitetura com uma CA intermédia ou um serviço de emissão em linha não é exceção. É a forma habitual de manter a capacidade de assinatura longe dos pontos finais e ainda assim emitir certificados de dispositivo à escala.

O que um cliente deve provar com a sua própria chave

Cada dispositivo recebe o seu próprio par de chaves e o seu próprio certificado, assinado uma vez pela CA. O cliente apresenta esse certificado e prova que possui a chave privada correspondente, e o servidor decide se o aceita. É esta a identidade que é revogada quando um portátil se perde.

O contraste importa sobretudo após um furto. Com identidades por dispositivo, um cliente exposto é removido por revogação ou pela remoção do par, e o resto da frota continua a funcionar.

Uma chave de autoridade divulgada não pode ser tratada assim. Todos os certificados que tenha assinado ou pudesse assinar tornam-se suspeitos, pelo que a resposta é substituir a confiança e não uma revogação isolada. Isso é um projeto, não um bilhete.

Ler um ficheiro antes de o copiar para qualquer lado

Dois comandos dizem-lhe que tipo de objeto tem na mão sem imprimir qualquer segredo. O primeiro indica o sujeito e o indicador de CA de um certificado; o segundo valida uma chave e reporta o seu tipo. Execute ambos sobre os ficheiros do pacote que vai distribuir. Tudo o que se validar como chave privada não pertence a um diretório de cliente.

openssl x509 -in ca.crt -noout -subject -ext basicConstraints
openssl pkey -in ca.key -noout -check

Se o segundo comando tiver êxito num ficheiro que está dentro de um pacote de cliente, pare e trate o pacote como comprometido. A saída que diz que uma chave é válida diz também que ela está presente, e a presença é todo o problema.

Repare também no sentido inverso: um perfil de cliente contém legitimamente a chave privada desse cliente. Apagar todas as chaves que encontrar corta a ligação sem melhorar nada, pelo que o objeto tem de ser identificado antes de ser removido.

Conter uma chave que já distribuiu

Não assuma que apagar a cópia local reverte a exposição. Quem teve o ficheiro pode tê-lo copiado, e a suposição segura é que o fez. Siga o processo de incidentes do operador e substitua a âncora de confiança, reemitindo os certificados de dispositivo sob uma nova CA.

Depois altere o empacotamento que criou o problema. Envie uma listagem do diretório com uma lista branca explícita de ficheiros, mantenha a chave da CA numa máquina que nunca se junta à frota de clientes, e registe qual sistema a guarda.

Se a autoridade tiver de emitir com frequência, mova a assinatura para trás de um serviço ou de uma intermédia com âmbito estreito e validade curta. Assim, um erro futuro expõe um subconjunto da emissão e não a raiz de confiança de toda a implementação.