OpenVPN sen certificado de cliente: política do servidor, non do perfil

Vostede borra as liñas de certificado e chave, entrega o perfil, e a conexión segue fallando cun erro de certificado. O perfil nunca foi o que impuña ese requisito. O servidor decide se un certificado de cliente é obrigatorio, e ningunha edición no lado do cliente o negocia. Así que a solución é un cambio de política do servidor, feito a propósito, con todo o que depende del actualizado na mesma pasada.

O perfil non é a política

Community OpenVPN 2.6 distribúese con certificados de cliente obrigatorios, porque verify-client-cert toma por defecto o valor require. Ponlo en none é o que detén a esixencia dun certificado e entrega a autenticación do cliente ao arranxo de usuario e contrasinal que o servidor xa executa. As guías antigas recorren a client-cert-not-required, a grafía herdada da mesma idea, así que use a directiva que documente a súa versión instalada. En calquera caso, o cambio ocorre no servidor, e ningún perfil de cliente pode realizalo.

O fragmento seguinte é todo o cambio do lado do servidor, e por si só non é unha configuración de autenticación funcional. verify-client-cert none elimina o requisito de certificado, mentres que username-as-common-name fai que o nome da conta sexa a identidade que ven as devolucións de chamada posteriores e os ficheiros de cada cliente. Ningunha das dúas liñas comproba un contrasinal, así que aínda debe existir un verificador.

verify-client-cert none
username-as-common-name

Ese verificador é un complemento ou un script impulsado por auth-user-pass-verify, e debe estar no seu sitio antes de que calquera das liñas anteriores signifique algo. Inverter a orde dálle unha xanela na que o servidor non pide certificado e non comproba conta algunha.

Que segue verificando o servidor

Descartar o certificado de cliente non significa descartar TLS. O servidor conserva o seu certificado e a súa chave, e o cliente conserva a confianza na CA e as comprobacións de nome de host que lle impiden falar cun impostor. Quitar remote-cert-tls server ou o paquete de CA porque o cliente xa non ten certificado é unha mala interpretación común e grave, e a referencia da 2.6 é explícita en que as dúas direccións son independentes. Unha demostra o servidor ao cliente; a outra demostra o cliente ao servidor.

Un perfil tamén pode levar un bloque tls-auth ou tls-crypt. É unha chave compartida da canle de control co seu propio ciclo de distribución e rotación, así que un ficheiro sen liñas de certificado nin chave non é automaticamente seguro para publicar. Tráteo como un segredo ata que o teña lido.

Un ficheiro de certificado copiado dun perfil funcional non demostra nada por si só; a posesión significa ter a chave privada que lle corresponde, cousa que comproba un despregamento autenticado por certificado. Un ficheiro que contén un certificado non é un ficheiro co que se poida autenticar.

Que debe facer o verificador

Co requisito de certificado eliminado, todo descansa no verificador: un complemento ou un script impulsado por auth-user-pass-verify. Debe rexeitar credenciais non válidas, rexeitar contas desactivadas ou non elixibles e fallar pechado cando non pode alcanzar o seu backend. username-as-common-name adoita activarse ao mesmo tempo, e cambia a identidade que ven as devolucións de chamada posteriores e os ficheiros de configuración de cada cliente. Non verifica un contrasinal nin fai elixible unha conta que non o é. Son traballos separados, e mesturalos é como unha migración supera a súa proba de camiño feliz e falla no seu primeiro incidente real.

Probe os casos negativos con tanto coidado como o positivo. Un perfil que mostra unha petición de contrasinal só demostra que o cliente pode debuxar unha petición, mentres que un servidor que acepta o contrasinal incorrecto demostra algo moito peor. Engada unha conta desactivada e unha credencial caducada ao conxunto de probas, non só un contrasinal incorrecto.

Cambie a política, o perfil e o mapeo á vez

Coordine tres cousas: a directiva do servidor, o perfil do cliente e o mapeo de identidade por cliente. Cámbieos por separado e os clientes fallan antes da verificación, ou conéctanse cun nome que o administrador non esperaba, o que é peor porque parece un éxito. Unha conexión que ten éxito coa identidade equivocada é máis difícil de notar que unha que falla.

Manteña dúas contas de proba para esta ruta, unha válida e outra coñecida como mala, e use ambas despois de calquera cambio no verificador. A conta válida demostra o camiño feliz e o mapeo de identidade; a mala demostra que o rexeitamento segue funcionando. Ningunha das probas lle di nada sobre as regras de elixibilidade, así que engada unha conta que debería ser rexeitada por motivos de política se o despregamento as ten. Execute as tres despois de cada cambio, porque un verificador que comeza a aceptalo todo parece exactamente un inicio de sesión funcional.

Rexistre que métodos de autenticación acepta realmente o servidor, non os que suxire o perfil. Ese rexistro responde a pregunta que a xente segue facendo, que é quen pode conectarse a este servizo. Tamén sobrevive ao seguinte administrador, que doutro xeito o redescubriría a partir dunha captura de paquetes.