Tres preguntes diferents reben resposta de tres parts diferents d'un perfil d'OpenVPN, i fusionar-les és com la gent acaba desactivant una comprovació que funcionava. El certificat de l'equip remot està signat per l'autoritat en què confio? Aquest certificat declara el rol de servidor TLS? És el servidor concret al qual volia arribar? remote-cert-tls server només respon la pregunta del mig, i ho fa llegint extensions dins del certificat.

Tres comprovacions que és fàcil fusionar al cap

L'àncora de confiança viu a la directiva ca. La comprovació del rol pertany a remote-cert-tls. La comprovació d'identitat pertany a verify-x509-name, quan un perfil la fa servir, o a qualsevol comprovació de nom que afegeixi el desplegament.

Cobreixen fallades diferents:

QuestionDirectiveFailure it catches
Who signed this?caCertificate from an unrelated authority
Is this a server?remote-cert-tlsClient certificate presented by a peer
Is this my server?verify-x509-nameAnother valid server from the same CA

Un perfil pot tenir les tres i continuar sent feble si la CA es comparteix massa àmpliament, cosa que és una qüestió de gestió de claus i no de directives.

Què llegeix la comprovació del rol

La directiva és una macro. S'expandeix en un requisit d'ús de clau i un requisit d'ús de clau estès que anomena el rol de servidor web TLS, de manera que el certificat de l'equip remot ha de declarar realment aquesta finalitat. Un certificat emès per a autenticació de client no el satisfà, fins i tot quan la mateixa autoritat ha signat tots dos.

Això importa perquè una CA compartida és habitual en desplegaments petits. Una autoritat signa tots els clients i el servidor, i sense una comprovació de rol qualsevol d'aquests certificats podria completar el costat servidor de l'apretada de mans. La comprovació no fa impossible aquest escenari, però n'elimina la versió trivial.

La directiva és asimètrica per disseny: els clients porten remote-cert-tls server, i els servidors porten remote-cert-tls client. Canvieu-los i cada connexió falla amb un error de rol que sembla un certificat trencat.

Els perfils antics de vegades fan servir ns-cert-type per a la mateixa finalitat. Les pàgines de manual actuals tracten aquesta opció com a superada, així que un perfil que encara hi confia val la pena migrar-lo en lloc de depurar-lo.

Per què desactivar-la sembla una solució

Quan la comprovació del rol falla, la connexió s'atura amb un error de verificació i el moviment obvi és esborrar la línia. Llavors la connexió s'aixeca, cosa que sembla un progrés i en realitat és el mode de fallada que la directiva existeix per evitar. Ara accepteu un equip remot el certificat del qual mai no estava pensat per a aquest rol.

Llegiu l'error en lloc d'això. Anomena la comprovació que ha fallat, i el certificat de l'altre costat es pot inspeccionar per veure quines extensions porta realment. Dos minuts de lectura decideixen si la fallada és d'emissió o de configuració. Endevinar costa una tarda i normalment acaba amb un perfil debilitat. Un certificat de servidor renovat que ha perdut l'ús de clau estès és una fallada real en la renovació, no una raó per relaxar el client.

La comprovació del nom és una directiva separada

Satisfer la comprovació del rol diu que l'equip remot és algun servidor signat per la vostra autoritat. No diu res sobre quin, cosa que importa quan la mateixa CA emet certificats per a diverses passarel·les i una d'elles està compromesa o reutilitzada.

verify-x509-name compara el subjecte del certificat amb un valor que configureu, amb modes de coincidència per a un subjecte exacte, un prefix o un sol camp. Feu servir el camp que identifica realment la passarel·la, i espereu actualitzar-lo deliberadament quan el nom canviï.

Cap de les dues directives substitueix una bona gestió de claus. Si el fitxer de clau del client es copia d'un lloc a un altre amb el perfil, la identitat de l'equip remot és tan forta com la llista de distribució.

Inspeccioneu el certificat abans d'editar el perfil

Llegiu el certificat de l'equip remot i el registre del client, en aquest ordre. El certificat us diu quins rols declara; el registre us diu quina comprovació l'ha rebutjat.

Aquestes ordres imprimeixen les extensions d'ús i les línies de verificació d'una connexió 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 verify

Si les extensions mostren el rol de servidor i el registre encara informa d'una fallada de rol, el perfil probablement apunta a un fitxer de certificat equivocat i no a un certificat dolent. Si les extensions només mostren autenticació de client, deixeu de mirar el client i arregleu l'emissió. En qualsevol cas, restaureu la comprovació abans de dir que la connexió és sana, perquè una apretada de mans reeixida després de treure la verificació demostra menys que l'error que ha substituït.

Articles relacionats