Os novos accesos VPN fallan mentres os certificados son válidos: revise a CRL

Certificados aos que lles quedan meses e accesos que fallan de inmediato apuntan a dous obxectos distintos con dous reloxos distintos. O servidor rexeita conexións porque a lista de certificados revogados que consulta superou a súa propia data de caducidade, non porque os certificados dos usuarios quedasen obsoletos. Renovar un certificado de usuario non fai nada por esa lista.

Separar os dous calendarios é todo o diagnóstico, e cambia como ten que ser a solución.

Dous reloxos, e só un deles é o certificado

Un certificado leva unha xanela de validez. Unha lista de revocación de certificados leva a súa propia xanela, ademais dun emisor e unha sinatura, e os verificadores néganse a confiar nunha lista cuxa hora de próxima actualización xa pasou. Cando iso ocorre, o cliente presenta un certificado perfectamente válido e o servidor aínda así corta a conexión cunha mensaxe sobre a lista. Os usuarios len esa mensaxe como «o certificado caducou», o que envía a solicitude de renovación ao lugar equivocado.

Os dous obxectos tamén teñen propietarios distintos: o certificado procede da CA que o emitiu, mentres que a lista xérase segundo un calendario por quen opera esa CA. Un usuario non pode refrescala, e reemitir certificados non pode prolongala.

Lea a lista que o servizo carga realmente

Comece pola configuración en execución en lugar de polo ficheiro que espera. A ruta de crl-verify pode ser absoluta, relativa ao perfil ou unha copia incrustada nunha imaxe, e o verificador le esa copia. Inspecciónea no seu sitio con openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate e compare as datas co reloxo do servidor.

Despois confirme que o ficheiro é realmente o que se usa: comprobe a súa sinatura con openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, que informa dun resultado de verificación en lugar de imprimir os campos en silencio. Unha lista asinada por outra CA, ou unha copia antiga deixada nun segundo directorio, falla exactamente igual que unha caducada.

Volva xerar desde a base de datos de revocación, non desde cero

A lista nova ten que vir da base de datos de revocación actual da CA, mediante o proceso de sinatura aprobado. Xerar unha lista baleira, ou rexerala desde unha copia de seguranza antiga do índice, desfai en silencio a revocación de cada identidade engadida desde esa copia. Iso converte unha caída de acceso nunha regresión de seguridade, e ninguén o nota porque o síntoma desaparece.

Manteña o paso de xeración baixo control de versións xunto co resto das ferramentas da CA, para que o intervalo e a clave de sinatura queden documentados en lugar de recordados. Abonda unha entrada de runbook que nomee o comando, o asinante e o destino de publicación. Así calquera de garda pode rexerar sen adiviñar que ficheiro de índice é o autoritativo. Garde o número de serie da lista e a hora de próxima actualización xunto co rexistro de despregamento.

Despregue onde mira o verificador

Copie a lista nova á ruta que le o servizo, axuste a propiedade e o modo para que a conta do servizo poida lela pero outros non, e recargue ou reinicie segundo o comportamento documentado. Se o daemon almacena a lista ao arrincar, substituír o ficheiro sen recargar non cambia nada que o proceso en execución vaia notar. Confirme a marca de tempo que o proceso informa tras a recarga.

Se varios servizos verifican clientes, despregue en cada un deles. Actualizar un extremo e deixar outro coa copia antiga produce un fallo que só aparece nos usuarios que aterran no segundo. Manteña unha lista curta deses extremos no mesmo runbook. Despois do despregamento, comprobe a data de lista informada por cada un en lugar de supoñer que a copia chegou.

Faga visible o próximo prazo antes de que pase

Un intervalo de publicación máis longo reduce a frecuencia deste incidente sen crear un proceso. Escolla o intervalo segundo a política do operador e logo alerte sobre o campo de próxima actualización da lista despregada con suficiente antelación para rexerar e despregar. Alerte sobre a copia despregada, non sobre o host da CA, porque a copia despregada é a que falla.

Tras o despregamento, verifique ambas as direccións: un usuario permitido conéctase e unha identidade revocada coñecida segue fallando. A segunda comprobación é a que atrapa unha rexeración incompleta, e require un só comando contra un perfil de proba que vostede mantén xustamente para este propósito.