Mantenha a chave de assinatura da AC do OpenVPN fora de /etc/openvpn

Dois diretórios que parecem iguais num tutorial fazem trabalhos completamente diferentes. Um contém a autoridade de certificação: a sua chave privada, o contador de números de série e o registo de tudo o que assinou. O outro contém o que o daemon precisa para arrancar e servir clientes. Colocar ambos no mesmo anfitrião sob a mesma conta é conveniente durante uma tarde e dispendioso durante o resto da vida da implementação, porque o daemon passa então a correr ao lado da única chave que pode criar qualquer identidade que queira.

O que contém a área de trabalho da AC

Um diretório PKI é estado do emissor, não configuração. Contém a chave privada e o certificado da AC, um ficheiro de número de série, um índice dos certificados emitidos e o material por identidade que foi produzido a partir deles.

Assinar um pedido altera esse estado, e é por isso que a área de trabalho pertence a uma conta controlada pelo administrador num anfitrião onde o serviço VPN não corre. Qualquer pessoa que possa ler a chave privada da AC pode emitir um certificado em que o servidor confiará, pelo que a proteção da chave é todo o modelo de confiança num único ficheiro. Copiá-la para um segundo local para poupar um passo cria uma segunda coisa a proteger e uma segunda coisa a esquecer. Cada assinatura também incrementa o número de série e acrescenta uma entrada ao índice, e é por isso que a área de trabalho é uma cópia de estado e não uma pasta de ficheiros.

O certificado público da AC é diferente. Destina-se a ser distribuído, e é o que clientes e servidores usam para se verificarem mutuamente.

O que o daemon lê ao arrancar

Um servidor em funcionamento consome um conjunto pequeno: o seu próprio certificado, a sua própria chave privada, o certificado da AC para verificar os pares e o material de chaves que o modo escolhido exigir. Lê esses caminhos no arranque e novamente ao recarregar.

A propriedade tem de ser avaliada em relação à unidade que realmente arranca, não em relação a uma shell root interativa. O isolamento declarado pode tornar parte do sistema de ficheiros só de leitura ou invisível mesmo quando um teste manual como root é bem-sucedido.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

É essa terceira linha que as pessoas saltam. Pergunta à própria conta do daemon se consegue ler a chave, e é a única versão da pergunta que importa depois de os privilégios terem sido largados. Uma saída zero como root não diz nada sobre o que acontece após o abandono.

Vale a pena separar os dois caminhos de falha antes de alterar qualquer permissão. Uma falha de assinatura aponta para o diretório PKI, para a permissão de pesquisa nos seus diretórios ascendentes e para a conta que executa o emissor. Uma falha de arranque aponta para a unidade, para o seu diretório de trabalho e para os caminhos indicados na configuração do servidor. Tornar toda a árvore legível por todos não corrige nenhuma das duas e remove a fronteira de que ambas dependem.

Por que razão copiar a chave da AC para o servidor falha mais tarde

A cópia começa normalmente como um passo de depuração: alguém quer renovar um cliente no anfitrião VPN, por isso a chave da AC acaba em /etc/openvpn e a renovação funciona. A tarefa imediata é bem-sucedida e a fronteira desapareceu.

Depois o servidor é salvaguardado, e a autoridade de assinatura junta-se às cópias de segurança. Um instantâneo, um pacote de suporte ou uma cópia do diretório de configuração passa agora a transportar a capacidade de emitir identidades fidedignas enquanto a AC for válida. Quem tiver essa cópia pode criar um certificado para qualquer nome que o servidor aceite, incluindo nomes que nunca foram emitidos. O único registo dessa emissão é o que eles decidirem guardar.

Recuperar desse estado não é uma questão de apagar um ficheiro. Tem de decidir se a chave foi exposta, rodar a AC se foi, e redistribuir a confiança por todos os pares. Uma área de trabalho separada evita toda a conversa.

Contas, diretórios, cópias de segurança

Dê ao emissor a sua própria conta e diretório pessoal, mantidos fora do anfitrião VPN quando for prático. Dê ao daemon uma conta diferente, com acesso de leitura ao material implementado e acesso de escrita a nada que emita certificados. Implemente copiando certificados públicos para fora e nunca puxando estado privado do emissor para dentro. Salvaguarde as duas funções separadamente, porque a sua sensibilidade e as suas histórias de restauro diferem.

Após uma revogação, atualize o ficheiro CRL indicado pela configuração do servidor e depois recarregue o serviço para que as novas ligações o leiam. A documentação do Easy-RSA cobre a estrutura da área de trabalho e o fluxo de assinatura; as regras de propriedade em torno dela continuam a ser uma decisão sobre o seu anfitrião. Confirme o que o serviço carregou com openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate em vez de assumir que o recarregamento o apanhou.

Um teste que prova a separação

Verifique o caso negativo, não apenas o que funciona. Assine um certificado a partir da conta do emissor conforme concebido e depois confirme que a mesma conta não consegue iniciar o serviço nem ler a chave privada do servidor. Em seguida, confirme que a conta do daemon não consegue ler a chave privada da AC.

Essas três verificações demoram alguns minutos e sobrevivem a mudanças de pessoal, porque são afirmações sobre permissões e não sobre hábitos. Escreva o resultado com os caminhos e as contas que abrangeu, mais a data em que as executou. A pessoa seguinte que herdar esta implementação irá, de outro modo, deduzir de novo a fronteira a partir de um tutorial que nunca teve uma. Um registo datado é também o que faz a próxima revisão demorar minutos em vez de uma tarde.