remote-cert-tls server: que comproba nun perfil de OpenVPN
A directiva comproba o rol codificado no certificado do par, non o seu nome. Compare o rol, a áncora de confianza e a comprobación do nome de host antes de desactivar nada.
Tres preguntas distintas reciben resposta de tres partes distintas dun perfil de OpenVPN, e fusionalas é como a xente acaba desactivando unha comprobación que funcionaba. O certificado do par está asinado pola autoridade na que confío? Ese certificado declara o rol de servidor TLS? É o servidor concreto ao que quería chegar? remote-cert-tls server só responde á pregunta intermedia, e faino lendo extensións dentro do certificado.
Tres comprobacións fáciles de fusionar na cabeza
A áncora de confianza vive na directiva ca. A comprobación do rol pertence a remote-cert-tls. A comprobación de identidade pertence a verify-x509-name, cando un perfil a usa, ou a calquera comprobación de nome que engada o despregamento.
Cobren fallos distintos:
| Question | Directive | Failure it catches |
|---|---|---|
| Who signed this? | ca | Certificate from an unrelated authority |
| Is this a server? | remote-cert-tls | Client certificate presented by a peer |
| Is this my server? | verify-x509-name | Another valid server from the same CA |
Un perfil pode ter as tres e seguir sendo feble se a CA se comparte demasiado amplamente, o que é unha cuestión de xestión de chaves e non de directivas.
Que le a comprobación do rol
A directiva é unha macro. Expándese nun requisito de uso de chave e nun requisito de uso de chave estendido que nomea o rol de servidor web TLS, así que o certificado do par debe declarar realmente ese propósito. Un certificado emitido para autenticación de cliente non o satisface, mesmo cando a mesma autoridade asinou ambos.
Iso importa porque unha CA compartida é habitual en despregamentos pequenos. Unha autoridade asina todos os clientes e o servidor, e sen unha comprobación de rol calquera deses certificados podería completar o lado servidor do aperto de mans. A comprobación non fai imposible ese escenario, pero elimina a súa versión trivial.
A directiva é asimétrica por deseño: os clientes levan remote-cert-tls server, e os servidores levan remote-cert-tls client. Cámbieos e cada conexión falla cun erro de rol que parece un certificado roto.
Os perfís antigos ás veces usan ns-cert-type para o mesmo propósito. As páxinas de manual actuais tratan esa opción como superada, así que un perfil que aínda depende dela merece migrarse en lugar de depurarse.
Por que desactivala parece unha solución
Cando a comprobación do rol falla, a conexión detense cun erro de verificación e o movemento obvio é borrar a liña. Entón a conexión sobe, o que parece un progreso e en realidade é o modo de fallo que a directiva existe para evitar. Agora acepta un par cuxo certificado nunca estivo pensado para ese rol.
Lea o erro no seu lugar. Nomea a comprobación que fallou, e o certificado do outro lado pode inspeccionarse para ver que extensións leva realmente. Dous minutos de lectura deciden se o fallo é de emisión ou de configuración. Adiviñar custa unha tarde e adoita acabar cun perfil debilitado. Un certificado de servidor renovado que perdeu o seu uso de chave estendido é un fallo real na renovación, non unha razón para relaxar o cliente.
A comprobación do nome é unha directiva aparte
Satisfacer a comprobación do rol di que o par é algún servidor asinado pola súa autoridade. Non di nada sobre cal, o que importa cando a mesma CA emite certificados para varias pasarelas e unha delas está comprometida ou reutilizada.
verify-x509-name compara o suxeito do certificado cun valor que vostede configura, con modos de coincidencia para un suxeito exacto, un prefixo ou un só campo. Use o campo que identifica realmente a pasarela, e espere actualizalo deliberadamente cando cambie o nome.
Ningunha das dúas directivas substitúe unha boa xestión de chaves. Se o ficheiro de chave do cliente se copia dun lado a outro co perfil, a identidade do par é tan forte como a lista de distribución.
Inspeccione o certificado antes de editar o perfil
Lea o certificado do par e o rexistro do cliente, nesa orde. O certificado dille que roles declara; o rexistro dille que comprobación o rexeitou.
Estes comandos imprimen as extensións de uso e as liñas de verificación dunha conexión detallada:
openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verifySe as extensións mostran o rol de servidor e o rexistro segue informando un fallo de rol, o perfil probablemente apunta a un ficheiro de certificado equivocado e non a un certificado defectuoso. Se as extensións só mostran autenticación de cliente, deixe de mirar o cliente e arranxe a emisión. En calquera caso, restaure a comprobación antes de dar a conexión por sana, porque un aperto de mans exitoso tras eliminar a verificación demostra menos que o erro que substitúe.