Recorreu quatre preguntes en ordre i el diàleg de CA deixa de ser ambigu. Quin material va emetre realment l’operador, què ja conté el perfil, quin camp pregunta i què passa després que es carregui el fitxer? Atureu-vos a la primera pregunta que no pugueu respondre amb les instruccions de l’operador mateix, perquè endevinar més enllà és com un certificat CA públic acaba aparellat amb una clau privada que no hauria d’haver sortit mai del servidor.

L’ordre importa: les dues últimes preguntes només tenen sentit quan sabeu quin material ha d’existir.

Comenceu per allò que el perfil ja porta

Obriu el perfil en un editor de text i busqueu un bloc ca abans de buscar un fitxer. Un bloc ca incrustat que conté el CA públic de l’operador vol dir que el perfil és autosuficient, i un client que encara demana un fitxer CA potser llegeix un altre perfil o una importació incompleta. Si el perfil té en canvi una línia ca que apunta a un camí, aquest camí és relatiu al directori de treball del client en algunes integracions i absolut en d’altres. Anoteu quina forma teniu abans de canviar res.

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

Reviseu el paquet lliurat pels fitxers a què fa referència el perfil: un certificat CA, de vegades un certificat de client i una clau separats, i possiblement un fitxer tls-auth o tls-crypt. Un perfil que fa referència a quatre fitxers i arriba amb dos és incomplet, i cap quantitat d’assenyalar camps ho arregla. Demaneu a l’operador la peça que falta en lloc de substituir-la per un certificat que tingueu per casualitat.

Separeu quatre tipus de material

El certificat CA és material públic que serveix per verificar la identitat del servidor. Un certificat de client identifica l’usuari o el dispositiu davant del servidor. Una clau privada és la meitat secreta d’aquest certificat de client, i no ha de ser mai la clau de signatura del CA ni una clau de servidor. El material tls-auth o tls-crypt és un secret compartit a part que protegeix el canal de control. Aquests quatre no són intercanviables, i apuntar el camp CA a un certificat de client produeix un error de verificació que sembla un problema de confiança.

Autenticació només amb contrasenya canvia quin dels quatre necessiteu, no què signifiquen. Amb auth-user-pass i remote-cert-tls server el client encara verifica el servidor contra un CA, i per això el camp CA apareix fins i tot quan no existeix cap certificat de client. La política de l’operador decideix si també cal un certificat de client, i cap diàleg no us ho pot dir.

Apunteu el client al fitxer de confiança

Seleccioneu el fitxer de certificat CA mateix, no la carpeta que el conté ni un paquet .p12 que porta una identitat de client. A Windows la sintaxi del camí i el selector de fitxers es comporten de manera diferent dels exemples de Linux de la majoria de guies, així que feu servir el que accepti el client instal·lat i confirmeu que el compte que el fa córrer pot llegir el fitxer. Un problema de permisos i un fitxer que falta es veuen igual al diàleg però produeixen línies de registre diferents. Després de seleccionar, torneu a obrir la configuració del perfil per confirmar que el client ha conservat l’elecció.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

Si el client admet blocs incrustats, preferiu el perfil incrustat de l’operador a un de muntat a mà. El material incrustat viatja amb el perfil i sobreviu a la reimportació, mentre que un camí absolut es trenca en el moment que el perfil es mou a una altra màquina.

Llegiu l’error següent, no el mateix

El sentit de proporcionar el CA correcte és canviar l’error, no fer-lo desaparèixer. Un error d’identitat del servidor després de carregar el CA vol dir que el certificat no coincidia amb el nom esperat o amb l’expectativa remote-cert-tls, que és una reparació diferent d’un rebuig de contrasenya. Un rebuig de contrasenya vol dir que la capa TLS ha tingut èxit i que la credencial és incorrecta. Quedeu-vos amb el primer missatge nou; és el que és útil.

Un client que es connecta però no arriba enlloc ha passat del tot la confiança i ara s’enfronta a una qüestió d’encaminament o DNS.

No desactiveu mai la verificació per passar aquest diàleg. Un client que accepta qualsevol certificat no té cap motiu per demanar un CA, i el túnel que construeix no és el que l’operador pretenia.

Articles relacionats