Dois certificados OpenVPN, um só nome CCD: o que correu mal

Dois certificados de cliente com números de série diferentes, chaves diferentes e até sujeitos completos diferentes podem ainda assim acabar no mesmo ficheiro de política, porque o servidor não olha para nada disso. Lê um nome do certificado e abre o ficheiro de configuração de cliente correspondente. Se ambos os certificados tiverem o mesmo nome, o segundo herda a política do primeiro no momento em que se liga.

A colisão é criada na inscrição e só é descoberta na ligação, normalmente quando um dispositivo recebe um endereço ou um conjunto de rotas que pertencem a outra máquina. Preveni-la significa acordar qual campo o servidor mapeia e, em seguida, reservar esse valor antes de qualquer coisa ser assinada.

As suas ferramentas de certificados não o avisam, porque a unicidade dentro do X.509 e a unicidade de um nome de política OpenVPN são requisitos diferentes aplicados por sistemas diferentes.

O servidor procura um nome, não uma impressão digital

Com o mapeamento habitual baseado em certificados, o servidor retira o nome comum do certificado apresentado e procura um ficheiro com esse nome no seu diretório de configuração de clientes. Esse ficheiro pode fixar um endereço estático, enviar rotas ou aplicar marcas de firewall por cliente. A procura é uma correspondência de cadeia com um nome de ficheiro, pelo que maiúsculas, espaços e pontuação são todos importantes.

Algumas implementações trocam deliberadamente o mapeamento para que um nome de utilizador autenticado assuma o nome comum, e então é o nome de utilizador que tem de ser único. De qualquer forma, o valor que seleciona a política é o valor que reserva. Decida qual é antes de emitir seja o que for; adivinhar depois de uma colisão custa mais do que perguntar.

Onde duas autoridades se encontram no mesmo nome

Uma organização que aceita certificados de mais do que uma autoridade emissora executa dois processos de inscrição independentes que escrevem num único espaço de nomes. As regras de unicidade de cada autoridade aplicam-se dentro dela própria, pelo que ambas podem emitir legitimamente para o mesmo nome comum sem que nenhuma note nada de errado.

Os números de série não ajudam. O X.509 exige que um número de série seja único no âmbito do seu emitente, o que é uma propriedade da contabilidade dessa autoridade e não uma identidade global do dispositivo. A verificação do sujeito também é um teste diferente da verificação do nome comum: dois certificados podem partilhar um CN mas diferir na unidade organizacional e, por isso, transportar sujeitos distintos. Todas essas propriedades podem verificar-se enquanto o servidor continua a mapear os dois certificados para um único nome de ficheiro.

A documentação do OpenSSL CA abrange a definição unique_subject que rege a opinião da sua própria base de dados, e o ponto de partida honesto é ler a sua configuração de emissão em vez de assumir que se aplica um determinado valor predefinido do EasyRSA ou do OpenSSL.

Reserve o nome efetivo antes de assinar

Mantenha um registo que mapeia um dispositivo para o seu registo aprovado e daí para um nome exato de ficheiro de política, para que um nome seja atribuído uma vez e permaneça atribuído. A reserva tem de ser atómica, o que na prática significa uma restrição de base de dados ou um bloqueio em torno do passo atribuir-e-depois-assinar, não uma folha de cálculo editada por duas pessoas.

Depois faça da verificação parte da emissão: recuse assinar quando o nome pedido já existe, e inclua nessa verificação todas as autoridades em que o servidor confia, porque um nome reservado pela outra autoridade está igualmente ocupado. Um pedido recusado com um motivo claro fica mais barato do que um ticket sobre um dispositivo que continua a receber o endereço estático de outra pessoa.

A renovação reutiliza um nome de propósito

Reemitir para um dispositivo existente deve produzir um novo número de série sob o mesmo nome de política, e isso é uma reutilização legítima e não uma colisão. O que tem de ser decidido antecipadamente é a sobreposição: se os certificados antigo e novo podem ser válidos em simultâneo, e como a credencial antiga é retirada.

Não recorra a duplicate-cn para resolver isto. Essa opção do servidor rege as ligações simultâneas que apresentam o mesmo nome; não bloqueia a inscrição, e ativá-la não torna um endereço estático partilhado seguro para duas máquinas ao mesmo tempo. A revogação identifica normalmente um certificado por emitente e número de série, pelo que retirar a credencial antiga não tem de invalidar a sua substituição desde que o servidor receba e aplique os dados de revogação corretos.

Confirme o mapeamento com as ferramentas da máquina

Antes de entregar a um dispositivo a sua nova credencial, leia o nome do certificado tal como o servidor o fará e, em seguida, compare-o com o ficheiro de política que espera ver escolhido.

openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf

O primeiro comando imprime os campos do sujeito em separado, o que torna imediatamente visível uma unidade organizacional perdida ou um espaço duplicado. O segundo confirma que existe um ficheiro de política exatamente com esse nome, e o terceiro mostra se o servidor está configurado para permitir várias sessões com um só nome. Execute os três sobre um certificado novo antes de este sair do passo de inscrição, enquanto um erro ainda custa uma assinatura em vez de um incidente. Guarde a saída com o ticket para que a pessoa seguinte veja que nome o servidor recebeu realmente.

Termine com uma ligação real e compare o endereço atribuído e as rotas enviadas com o ficheiro de política, e não com o que pensava escrever. Se dois dispositivos reportarem o mesmo endereço estático, o registo tem uma colisão que nenhuma inspeção de certificados revelará jamais.