¿Revocaste el certificado VPN equivocado? Opciones de recuperación y límites

Alguien revocó un certificado en la consola de la CA y ahora un usuario no puede conectarse. El primer instinto es buscar el deshacer, y para la mayoría de las PKI no existe: la revocación es un hecho declarado sobre un número de serie, y el camino de vuelta admitido es un certificado nuevo, no un registro invertido. Recorre las comprobaciones siguientes en orden, porque qué reparación se te permite usar depende del código de motivo y de si la clave llegó a exponerse.

Identifica el certificado, no a la persona

Los nombres comunes se repiten. Un usuario que se volvió a inscribir el trimestre pasado puede tener dos certificados con el mismo CN y números de serie distintos, y revocar uno deja el otro funcionando. Establece primero el objeto exacto:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

Anota el número de serie, el emisor, la fecha de revocación y el motivo registrado en la CRL. Después confirma qué dispositivos presentan ese número de serie, porque un certificado revocado puede seguir instalado en un portátil, un teléfono y un router de repuesto, y un reemplazo que solo llega a uno de ellos genera un segundo incidente.

Una comprobación rápida de comportamiento confirma el estado sin cambiar nada:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

Si informa que el certificado está revocado, la CRL y el cliente coinciden; si verifica limpiamente, el cliente que tienes no es el revocado, y la búsqueda continúa.

Comprueba si la CA usó retención o revocación permanente

La RFC 5280 define certificateHold como un estado temporal y removeFromCRL como la señal que lo libera. Ese ciclo de vida es real, pero no es un botón de deshacer general. Leer el código de motivo te dice si el emisor pretendió alguna vez admitir la liberación.

La trampa es suponer que una intención temporal implica un registro temporal. Si la entrada de la CA lleva keyCompromise o cessationOfOperation, el certificado está revocado de forma permanente, haga lo que haga la persona que pulsó el botón. A la inversa, una entrada marcada certificateHold en una CA que no implementa la liberación de retención es permanente en la práctica, porque nada publicará nunca la liberación.

Las CA basadas en OpenSSL ilustran el límite. La orden ca acepta valores de -crl_reason, incluidos certificateHold y removeFromCRL, pero no genera CRL delta — la documentación de OpenSSL CA señala esa limitación para su salida de CRL. Una CRL completa que simplemente omite el número de serie es un modelo de publicación distinto de una delta que dice "esta entrada está liberada", así que pegar removeFromCRL en una CA VPN basada en OpenSSL no produce la liberación definida por las normas.

Si la clave puede haberse expuesto, sustitúyela

Un certificado revocado es una declaración de que esta clave ya no puede ser confiable. Si la revocación era correcta en esencia — portátil perdido, clave copiada a un disco compartido, clave privada pegada en un ticket — restaurar el mismo certificado invierte una decisión de seguridad que funcionaba como debía.

Emite un par de claves nuevo mediante el proceso de inscripción, distribuye el perfil nuevo y deja el número de serie antiguo revocado durante toda su vida. Actualiza todo lo que fija la identidad por número de serie o huella, incluidas listas de admisión, inventarios de dispositivos y monitorización que espera un certificado concreto.

El argumento de comodidad para restaurar el antiguo es real, pero debe responderse explícitamente y no en voz baja. "El usuario necesita acceso hoy" es una razón para acelerar la emisión, no para desrevocar una clave de la que no puedes dar cuenta.

Si fue un error administrativo, sustituye bajo control

Cuando la revocación era simplemente errónea y la clave nunca se expuso, la reparación sigue siendo una sustitución controlada y no una edición. Usa el proceso admitido del emisor, mantén el número de serie y el historial de emisión intactos, y evita los dos atajos tentadores: girar el carácter de estado en index.txt de R a V, y borrar la fila de emisión para que un certificado nuevo pueda reutilizar el número de serie.

En una CA OpenSSL la base de datos está separada por tabuladores y es fácil de leer mal, lo que hace atractiva la edición manual:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

Léela, no la escribas. Editar el archivo cambia la siguiente CRL sin ningún rastro de auditoría, y cualquier segunda instancia de CA o copia de seguridad que aún conserve la fila original discrepará de ella más adelante.

Después de emitir el reemplazo, publica una CRL nueva mediante el mecanismo habitual y deja que los clientes la recojan. Quitar una CRL, acortar su vida hasta nada o desactivar la comprobación de revocación en el perfil del cliente arregla a un usuario debilitando todas las demás revocaciones que la CA haya publicado nunca.

Confirma una admisión nueva y conserva el registro

Prueba con una conexión nueva, no con la sesión que ya estaba abierta. Un túnel activo puede no volver a ejecutar las comprobaciones de admisión que hace un handshake nuevo, y las cachés de CRL hacen que un cliente pueda seguir conectándose hasta que se refresque. Desconecta, vuelve a conectar y confirma en el registro del servidor qué número de serie fue admitido.

Registra lo que ocurrió mientras aún está fresco: qué número de serie se revocó, por quién, con qué motivo, qué reemplazo se emitió y cuándo se republicó la CRL. Ese registro es lo que hace posible la siguiente revisión de revocación, y también es la prueba de que el error se gestionó en lugar de ocultarse.

Para suspensiones breves en el futuro, usa un mecanismo de pausa de admisión si el despliegue tiene uno — una cuenta desactivada en la capa de identidad, una pertenencia a grupo eliminada, un perfil de cliente retenido. Eso mantiene una decisión de política temporal separada de la cuestión de si un certificado emitido sigue siendo fiable, y es exactamente la distinción que se perdió la primera vez.