Què comprova el vostre client VPN abans de confiar en un certificat

El vostre client VPN diu que el certificat no s’ha pogut verificar, i el diàleg s’atura aquí. El fitxer hi és, el servidor funciona, i el mateix perfil va funcionar en un altre portàtil el mes passat. Sota aquest avís d’una línia, el client va fer passar el certificat del parell per quatre portes: una autoritat de certificació que heu configurat avala el camí de la signatura, aquest camí arriba a l’autoritat, el nom del parell és el que vau demanar, i el certificat és utilitzable ara per a aquest propòsit. Trobeu la porta que s’ha tancat i la reparació sol ser un fitxer; salteu aquest pas i reimportareu paquets tot el dia.

Llegiu el diàleg abans d’editar el perfil

Els errors de certificat els redacta la biblioteca de sota, no el producte VPN que heu instal·lat, així que la cadena exacta és la vostra primera prova. «No es pot obtenir el certificat de l’emissor local» apunta al camí o a l’àncora de confiança. «El certificat ha caducat o encara no és vàlid» apunta al temps. «Propòsit del certificat no suportat» apunta a l’ús estès de la clau. Un desajust de nom us diu quin nom volia. Cap de les quatre coses no es repara reinstal·lant el client.

Pugeu el nivell de registre abans de canviar res. OpenVPN informa del fall de verificació al voltant de l’apretada de mans quan l’executeu amb --verb 4, i strongSwan escriu les seves decisions d’identitat i de cadena al registre charon. Després confirmeu quin certificat esteu inspeccionant, perquè la gent sol provar el fitxer al disc mentre el perfil incrusta una còpia més antiga. Quan el perfil incrusta blocs PEM, el certificat incrustat és el que es prova.

Una autoritat de certificació signa identitats, no permisos

L’autoritat té un nom i una clau de signatura. Emet certificats que lliguen una clau pública a aquest nom segons la seva pròpia política, amb una finestra de validesa i restriccions d’ús adjuntes. El vostre client només necessita el certificat de l’autoritat per reconèixer l’emissor; mai no necessita la clau de signatura, i enviar aquesta clau als clients els donaria la capacitat de fabricar qualsevol identitat en què confiï el desplegament.

Confiar en una autoritat fa que cada certificat que ha signat sigui un candidat, no el parell correcte. Un certificat de servidor web de la mateixa CA interna també és un candidat. Per això existeixen les portes de nom i propòsit, i per això una clau de CA compromesa importa més que qualsevol servidor individual: arriba a cada identitat que l’autoritat ha emès mai. Repartiu certificats de client per dispositiu, perquè un portàtil perdut sigui una revocació i no una regeneració de claus per a tot el desplegament.

Reconstruïu el camí que el client intenta construir

El camí va del certificat del parell, per zero o més intermedis, fins a una arrel al vostre magatzem de confiança. Un intermedi que falta és la fallada de cadena més habitual, i des del costat del client sembla idèntic a una arrel no confiable. Llegiu primer el full, i després deixeu que OpenSSL construeixi el camí amb el material que penseu enviar.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Un estat de sortida zero vol dir que el camí s’ha construït amb aquests fitxers; un fall nomena el certificat que no ha pogut assolir. Si openssl verify té èxit mentre el client encara refusa, la diferència és en el que el servidor envia realment o en quin fitxer de confiança carrega el perfil. A OpenVPN, els intermedis poden viatjar amb el fitxer del certificat del servidor o lliurar-se a part amb --extra-certs, i un paquet amb dues arrels escrites sota el mateix nom de subjecte enviarà un dels vostres clients a la branca equivocada.

El nom i el propòsit són portes separades

La construcció de la cadena no pregunta mai si el nom és vostre. OpenVPN només ho comprova quan el perfil defineix --verify-x509-name, i el costum antic d’encertar només el nom comú es trenca amb certificats les identitats dels quals viuen a subjectAltName. Els desplegaments IKEv2 encaixen la identitat configurada amb les entrades SAN o amb el nom distingit, segons el client, i un valor comodí o %any desactiva silenciosament la comparació que creieu tenir.

Després vénen el temps i el propòsit. Un portàtil amb el rellotge unes hores avançat rebutja un certificat que encara no és vàlid, i un intermedi caducat fa fallar el camí mentre el full és vigent. Els falls de propòsit vénen d’un certificat sense serverAuth a l’ús estès de la clau, o amb un keyUsage que no permet la signatura de l’apretada de mans, que OpenSSL informa com a propòsit de certificat no suportat. Reemetiu des de la plantilla correcta; res en aquest missatge no és motiu per desactivar la verificació.

La revocació només funciona si algú l’ha configurada

Un CRL o una resposta OCSP no es consulten automàticament. En un servidor OpenVPN, els certificats de client es comproven contra una llista només quan --crl-verify n’apunta una. La comprovació del certificat del servidor pel costat del client depèn de la implementació i sovint és absent. strongSwan necessita el seu connector de revocació i una política abans de mirar un CRL per a un parell.

Això explica el tiquet que acabareu rebent: un certificat de client revocat encara es connecta, i tothom conclou que la revocació està trencada. Res no comprovava. Publiqueu i refresqueu el CRL, o manteniu els certificats de client prou curts perquè una revocació caducada importi breument, i assageu el camí de revocació amb un certificat de laboratori abans que el necessiteu durant un incident.

Un ordre de reparació que manté la verificació engegada

Ordeneu per símptoma abans de tocar fitxers, perquè cada fila de la taula us envia a un objecte diferent.

Feu la llista d’una passada: confirmeu el fitxer que carrega el perfil, construïu el camí vosaltres mateixos, comproveu que el servidor envia l’intermedi, compareu el rellotge, llegiu el SAN, llegiu l’EKU, i després reconecteu i mireu com la mateixa línia de registre desapareix. Si a un dispositiu no se li pot donar cap CA, el pinatge és l’alternativa honesta, perquè OpenVPN 2.6 accepta --peer-fingerprint i redueix la confiança a una clau en lloc de suprimir la comprovació. RFC 5280 és la referència de què significa cadascun d’aquests camps.