OpenVPN username-as-common-name: por que sua verificação de CN está vazia
Um script client-connect que compara common_name com username pode comparar um nome consigo mesmo. Vincule o certificado à conta antes que a substituição ocorra.
Você adiciona um script client-connect que rejeita toda conexão em que common_name difere de username, e ele parece um vínculo entre um certificado e uma conta. Num servidor que executa username-as-common-name, essa comparação já perdeu o sentido quando o script é executado. Os dois valores são a mesma string, então o teste passa para um certificado emitido a outra pessoa completamente diferente.
A verificação não está errada porque o script foi mal escrito. Ela está errada porque o valor que ele lê foi substituído antes na mesma conexão.
O que a comparação parece provar
A autenticação por certificado e a autenticação por senha são provas separadas, e um servidor pode exigir ambas sem exigir que pertençam à mesma pessoa. A lacuna é real: um certificado de dispositivo válido mais qualquer conta válida é uma afirmação diferente daquele certificado mais uma única conta nomeada. Um script que compara common_name com username lê-se como o elo perdido entre os dois. Seria, se common_name ainda significasse o que o certificado dizia.
Se é o caso depende de uma opção do servidor, e essa opção costuma ser ativada por um motivo não relacionado, como tornar os arquivos de configuração por usuário mais fáceis de nomear.
O que username-as-common-name faz com o nome
Com username-as-common-name habilitado, o OpenVPN substitui o nome comum do certificado pelo nome de usuário autenticado depois que o nome de usuário e a senha são verificados. O gancho de verificação que roda durante essa checagem ainda recebe o nome comum do certificado, porque a substituição ainda não aconteceu. Tudo depois disso, incluindo client-connect, vê o nome de usuário. Assim, o retorno de chamada posterior recebe uma identidade duas vezes e não pode compará-la com o certificado apresentado.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
Acompanhe uma conexão ilustrativa: um certificado emitido para bob-device, um login de diretório bem-sucedido como alice e a opção habilitada. A fase de verificação ainda pode ver duas strings diferentes. A fase de conexão vê alice e alice.
Esse exemplo mostra por que a comparação está vazia. Ele não mostra que a conexão seria aceita de outra forma, já que a validação do certificado e a verificação da senha ainda rodam por conta própria.
Coloque o vínculo onde ambas as identidades ainda existem
A regra deve ser aplicada numa fase que veja a identidade do certificado e a conta ao mesmo tempo, o que na prática significa o gancho de verificação de nome de usuário e senha ou um plugin carregado ali. Um plugin suportado que já realiza a verificação de senha costuma ser o lugar certo para adicionar uma regra de pareamento, porque substituí-lo por uma comparação de nomes eliminaria a checagem de senha por completo.
Defina o mapeamento antes de escrever código, já que a igualdade raramente é a política real. Um certificado muitas vezes identifica um dispositivo enquanto o login identifica uma pessoa, e um dispositivo pode legitimamente atender várias pessoas. Armazene a relação numa forma cuja emissão você controla, e decida o que acontece na renomeação, na reemissão e com nomes qualificados por domínio. Converter para minúsculas ou remover um prefixo de domínio sem entender o diretório pode fundir duas contas que deveriam permanecer distintas.
Lembre-se de que a opção também muda qual configuração por cliente se aplica, porque client-config-dir é indexado pelo nome comum.
Teste o pareamento com duas credenciais válidas
Comece com o par que sua política permite e confirme que ele conecta. Depois apresente o mesmo certificado válido com uma conta diferente, mas igualmente válida: essa tentativa deve falhar, e deve falhar pela regra de pareamento e não por uma senha digitada errado. Uma senha errada prova que a checagem de senha funciona e não diz nada sobre a regra entre certificado e conta.
Verifique também os caminhos sem certificado e com certificado inválido, e confirme qual identidade o servidor usa para as configurações por cliente. Se o único jeito de a comparação funcionar é desativar username-as-common-name, calcule primeiro o custo dessa mudança, porque ela devolve a busca de configuração de cada cliente ao nome do certificado.