El certificat VPN revocat encara connecta? Comprova l'aplicació de la CRL

Vas revocar el certificat, vas generar una llista nova i el perfil antic encara aixeca un túnel. La revocació en si no està trencada: una CRL és una declaració signada que un número de sèrie ja no és vàlid, i només canvia l'accés quan el component que acaba TLS la carrega, per a l'emissor correcte, abans de prendre la decisió d'acceptació. Aquí hi ha la majoria d'aquests casos, i per això revocació i denegació són dos fets diferents.

Recorre les cinc comprovacions següents en ordre i atura't a la primera que no es compleixi, perquè cada comprovació posterior dona per certes les anteriors.

Comprova quin component pren la decisió d'acceptació

Identifica el procés que valida el certificat del client, perquè només aquest procés pot aplicar una llista. En un servidor OpenVPN és el mateix dimoni, configurat amb crl-verify. En ocserv és la línia crl de ocserv.conf. En strongSwan les entrades són les CRL carregades juntament amb strictcrlpolicy. Un proxy o aparell que acaba TLS davant de la VPN també pot ser el verificador real, i si ho és, el dimoni del darrere no veu mai el certificat del client.

WireGuard pertany a una altra categoria. No té certificats ni llista de revocació; un parell s'admet per la seva clau pública a la configuració, així que tallar l'accés significa eliminar aquesta clau. Si busques una CRL en un desplegament només de WireGuard, aquest mecanisme no existeix.

Vigila també el parany del costat del client. Un client que es nega a connectar perquè no li agrada el certificat del servidor està aplicant la cadena del servidor, no revocant la seva pròpia credencial. Un certificat d'usuari només es revoca on es valida aquest certificat d'usuari, i això gairebé sempre és el costat del servidor.

Comprova per a quin emissor es va signar la llista

Una CRL està limitada a una CA emissora. Amb una arrel i una intermèdia, els certificats fulla vénen de la intermèdia, així que la llista que importa és la CRL de la intermèdia; la llista de l'arrel no diu res d'aquestes fulles. Un verificador apuntat al fitxer equivocat l'analitza ben content, no troba cap entrada coincident i accepta tot.

Confirma l'emparellament abans de tocar el dimoni. L'emissor del certificat ha de coincidir amb el subject de la llista:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Quan tots dos vénen de la mateixa CA, el número de sèrie imprès per al certificat és el valor que ha d'aparèixer a la llista. Si no coincideixen, tens la CRL equivocada o la còpia equivocada.

La validesa pertany a la mateixa comprovació. Un nextUpdate en el passat deixa la llista obsoleta, i un verificador que falla tancat rebutjarà llavors tots els clients en lloc de només el revocat.

Comprova que el número de sèrie sigui a la còpia que va carregar el dimoni

Revocar escriu una entrada a la base de dades de la CA, i regenerar escriu un fitxer nou. Cap de les dues accions arriba a un dimoni en execució que va carregar la còpia antiga a l'arrencada. Aboca la llista i busca el número de sèrie:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Després comprova com recull el fitxer la teva implementació. OpenVPN llegeix una ruta donada a crl-verify una vegada a l'arrencada, així que una llista nova necessita un reinici o un senyal de reinici; la mateixa opció apuntada a un directori es rellegeix a cada connexió, i per això existeix el mode de directori. strongSwan necessita recarregar les seves credencials, per exemple amb swanctl --load-creds. Que el fitxer al disc sigui correcte i que el verificador el faci servir són dos fets diferents.

Comprova la política per a una llista absent o caducada

Aquesta és la decisió que molts desplegaments no prenen mai de manera explícita, i decideix si la revocació et protegeix o deixa tothom fora. Fail-closed significa que cap informació de revocació utilitzable produeix un rebuig; fail-open significa que el verificador continua sense ella. strongSwan exposa l'elecció com strictcrlpolicy. OpenVPN amb crl-verify es nega a arrencar amb un fitxer que no pot llegir o analitzar, i una llista caducada apareix com un error de verificació TLS sobre una CRL caducada en lloc d'una acceptació silenciosa.

Tries la direcció que tries, l'automatització importa més que l'elecció: una tasca que regeneri la CRL abans de nextUpdate i una alerta quan la còpia desplegada envelleixi eviten que qualsevol de les dues polítiques es converteixi en un incident. La comprovació en línia amb OCSP trasllada la frescor a un responedor, però s'aplica la mateixa regla, perquè un verificador que no està configurat per comprovar la resposta no canvia res.

Comprova la sessió activa i després les còpies de la clau

La revocació s'avalua durant la validació del certificat, que passa en connectar i en renegociar. Una sessió establerta continua fins que renegocia, i el valor predeterminat d'OpenVPN és un cop per hora amb reneg-sec 3600. Si la persona ha de sortir de la xarxa ara, acaba la sessió a més de publicar la llista, i després confirma que es rebutja la reconnexió.

Separa la credencial de les seves còpies. Esborrar un perfil en un portàtil no impedeix que una altra còpia de la mateixa clau privada s'autentiqui; la revocació és el que fa inútil cada còpia, i només quan es compleixen les comprovacions anteriors. Dona a un dispositiu de substitució el seu propi certificat per poder revocar un sense tocar l'altre.

Abans de donar-ho per acabat: el component validador està identificat, l'emissor de la llista coincideix amb l'emissor de la fulla, el número de sèrie revocat és a la còpia que el dimoni va carregar realment, la política per a llistes absents o caducades és deliberada i monitorada, i la sessió activa es va acabar en lloc d'esperar. Els formats que hi ha darrere de tot això s'especifiquen a RFC 5280.