O certificado VPN revogado segue conectando? Comproba a aplicación da CRL

Revogaches o certificado, xeraches unha lista nova e o perfil antigo segue levantando un túnel. A revogación en si non está rota: unha CRL é unha declaración asinada de que un número de serie xa non é válido, e só cambia o acceso cando o compoñente que termina TLS a carga, para o emisor correcto, antes de tomar a decisión de aceptación. Aí está a maioría destes casos, e por iso revogación e denegación son dous feitos distintos.

Percorre as cinco comprobacións seguintes en orde e detente na primeira que non se cumpra, porque cada comprobación posterior dá por certas as anteriores.

Comproba que compoñente toma a decisión de aceptación

Identifica o proceso que valida o certificado do cliente, porque só ese proceso pode aplicar unha lista. Nun servidor OpenVPN é o propio daemon, configurado con crl-verify. En ocserv é a liña crl de ocserv.conf. En strongSwan as entradas son as CRL cargadas xunto con strictcrlpolicy. Un proxy ou dispositivo que termina TLS diante da VPN tamén pode ser o verificador real, e se o é, o daemon que está detrás nunca ve o certificado do cliente.

WireGuard pertence a outra categoría. Non ten certificados nin lista de revogación; un par admítese pola súa clave pública na configuración, así que cortar o acceso significa eliminar esa clave. Se buscas unha CRL nun despregamento só de WireGuard, ese mecanismo non existe.

Ollo tamén coa trampa do lado do cliente. Un cliente que se nega a conectar porque non lle gusta o certificado do servidor está aplicando a cadea do servidor, non revogando a súa propia credencial. Un certificado de usuario só se revoga onde se valida ese certificado de usuario, e iso case sempre é o lado do servidor.

Comproba para que emisor se asinou a lista

Unha CRL está limitada a unha CA emisora. Cunha raíz e unha intermedia, os certificados folla veñen da intermedia, así que a lista que importa é a CRL da intermedia; a lista da raíz non di nada desas follas. Un verificador apuntado ao ficheiro equivocado analízaa moi contento, non atopa ningunha entrada coincidente e acepta todo.

Confirma o emparellamento antes de tocar o daemon. O emisor do certificado debe coincidir co subject da lista:

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

Cando ambos veñen da mesma CA, o número de serie impreso para o certificado é o valor que debe aparecer na lista. Se non coinciden, tes a CRL equivocada ou a copia equivocada dela.

A validez pertence á mesma comprobación. Un nextUpdate no pasado deixa a lista obsoleta, e un verificador que falla pechado rexeitará entón todos os clientes en lugar de só o revogado.

Comproba que o número de serie está na copia que cargou o daemon

Revogar escribe unha entrada na base de datos da CA, e xerar de novo escribe un ficheiro novo. Ningunha das dúas accións chega a un daemon en execución que cargou a copia antiga no arranque. Volca a lista e busca o número de serie:

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

Despois comproba como recolle o ficheiro a túa implementación. OpenVPN le unha ruta dada a crl-verify unha vez no arranque, así que unha lista nova necesita un reinicio ou un sinal de reinicio; a mesma opción apuntada a un directorio relése en cada conexión, e por iso existe o modo de directorio. strongSwan necesita recargar as súas credenciais, por exemplo con swanctl --load-creds. Que o ficheiro no disco sexa correcto e que o verificador o use son dous feitos distintos.

Comproba a política para unha lista ausente ou caducada

Esta é a decisión que moitos despregamentos nunca toman de forma explícita, e decide se a revogación te protexe ou deixa a todos fóra. Fail-closed significa que ningunha información de revogación utilizable produce un rexeitamento; fail-open significa que o verificador continúa sen ela. strongSwan expón a escolla como strictcrlpolicy. OpenVPN con crl-verify négase a arrancar cun ficheiro que non pode ler ou analizar, e unha lista caducada aparece como un erro de verificación TLS sobre unha CRL caducada en lugar de como unha aceptación silenciosa.

Escollas a dirección que escollas, a automatización importa máis ca a escolla: unha tarefa que volva xerar a CRL antes de nextUpdate e unha alerta cando a copia despregada envelleza evitan que calquera das dúas políticas se converta nun incidente. A comprobación en liña con OCSP traslada a frescura a un respondedor, pero aplícase a mesma regra, porque un verificador que non está configurado para comprobar a resposta non cambia nada.

Comproba a sesión activa e despois as copias da chave

A revogación avalíase durante a validación do certificado, que ocorre ao conectar e ao renegociar. Unha sesión establecida segue funcionando ata que renegocia, e o valor predeterminado de OpenVPN é unha vez por hora con reneg-sec 3600. Se a persoa ten que saír da rede agora, termina a sesión ademais de publicar a lista, e despois confirma que se rexeita a reconexión.

Separa a credencial das súas copias. Borrar un perfil nun portátil non impide que outra copia da mesma chave privada se autentique; a revogación é o que fai inútil cada copia, e só cando se cumpren as comprobacións anteriores. Dálle a un dispositivo de substitución o seu propio certificado para poder revogar un sen tocar o outro.

Antes de dalo por terminado: o compoñente validador está identificado, o emisor da lista coincide co emisor da folla, o número de serie revogado está na copia que o daemon cargou realmente, a política para listas ausentes ou caducadas é deliberada e está monitorizada, e a sesión activa terminouse en lugar de esperar. Os formatos que hai detrás de todo isto especifícanse en RFC 5280.