Els nous inicis de sessió VPN fallen mentre els certificats són vàlids: reviseu la CRL

Certificats amb mesos per davant i inicis de sessió que fallen immediatament apunten a dos objectes diferents amb dos rellotges diferents. El servidor rebutja les connexions perquè la llista de certificats revocats que consulta ha superat la seva pròpia data de caducitat, no pas perquè els certificats dels usuaris hagin caducat. Renovar un certificat d’usuari no fa res per a aquesta llista.

Separar els dos calendaris és tot el diagnòstic, i canvia com ha de ser la solució.

Dos rellotges, i només un d’ells és el certificat

Un certificat porta una finestra de validesa. Una llista de revocació de certificats porta la seva pròpia finestra, a més d’un emissor i una signatura, i els verificadors es neguen a confiar en una llista el moment de la propera actualització de la qual ja ha passat. Quan això passa, el client presenta un certificat perfectament vàlid i el servidor igualment talla la connexió amb un missatge sobre la llista. Els usuaris llegeixen aquest missatge com a 'el certificat ha caducat', cosa que envia la sol·licitud de renovació al lloc equivocat.

Els dos objectes també tenen propietaris diferents: el certificat prové de la CA que el va emetre, mentre que la llista es genera segons un calendari per qui opera aquella CA. Un usuari no la pot refrescar, i reemetre certificats no la pot allargar.

Llegiu la llista que el servei carrega realment

Comenceu per la configuració en execució més que pel fitxer que espereu. El camí de crl-verify pot ser absolut, relatiu al perfil o una còpia incrustada en una imatge, i el verificador llegeix aquella còpia. Inspeccioneu-lo al seu lloc amb openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate i compareu les dates amb el rellotge del servidor.

Després confirmeu que el fitxer és realment el que s’utilitza: comproveu-ne la signatura amb openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, que informa d’un resultat de verificació en lloc d’imprimir els camps en silenci. Una llista signada per una altra CA, o una còpia antiga deixada en un segon directori, falla exactament com una de caducada.

Torneu a generar des de la base de dades de revocació, no des de zero

La llista nova ha de venir de la base de dades de revocació actual de la CA, a través del procés de signatura aprovat. Generar una llista buida, o tornar a generar-la a partir d’una còpia de seguretat antiga de l’índex, desfà silenciosament la revocació de cada identitat afegida des d’aquella còpia. Això converteix una caiguda d’inici de sessió en una regressió de seguretat, i ningú no se n’adona perquè el símptoma desapareix.

Manteniu el pas de generació sota control de versions amb la resta d’eines de la CA, perquè l’interval i la clau de signatura quedin documentats en lloc de recordats. Una entrada de runbook que anomeni l’ordre, el signant i l’objectiu de publicació és suficient. Així qualsevol persona de guàrdia pot tornar a generar sense endevinar quin fitxer d’índex és l’autoritatiu. Guardeu el número de sèrie de la llista i el moment de la propera actualització amb el registre de desplegament.

Desplegueu on mira el verificador

Copieu la llista nova al camí que el servei llegeix, fixeu la propietat i el mode perquè el compte de servei la pugui llegir però els altres no, i recarregueu o reinicieu segons el comportament documentat. Si el dimoni emmagatzema la llista a l’inici, substituir el fitxer sense recarregar no canvia res que el procés en execució noti. Confirmeu la marca temporal que el procés informa després de la recàrrega.

Si diversos serveis verifiquen clients, desplegueu a cadascun d’ells. Actualitzar un extrem i deixar-ne un altre amb la còpia antiga produeix un error que només apareix als usuaris que arriben al segon. Manteniu una llista curta d’aquests extrems al mateix runbook. Després del desplegament, comproveu la data de llista informada per cadascun en lloc de suposar que la còpia ha arribat.

Feu visible la propera data límit abans que passi

Un interval de publicació més llarg redueix la freqüència d’aquest incident sense crear un procés. Trieu l’interval segons la política de l’operador i després alerta sobre el camp de propera actualització de la llista desplegada amb prou marge per tornar a generar i desplegar. Alerta sobre la còpia desplegada, no sobre l’amfitrió de la CA, perquè la còpia desplegada és la que falla.

Després del desplegament, verifiqueu les dues direccions: un usuari permès es connecta i una identitat revocada coneguda encara falla. La segona comprovació és la que atrapa una regeneració incompleta, i només necessita una ordre contra un perfil de prova que manteniu precisament per a això.