¿Esa clave OpenVPN publicada es una CA, una clave de par o tls-auth?

Alguien informa de que la clave VPN es pública, y esa frase esconde tres situaciones completamente distintas. Puede ser un certificado de CA que todo cliente debería tener, una clave de identidad privada que nunca debería haber salido de una máquina, o bien un secreto compartido del canal de control que ambos extremos deben conservar. La reparación, la urgencia y el alcance del daño difieren en cada caso, así que la primera tarea es la clasificación y no la acción. Si te equivocas de categoría, cada paso posterior es esfuerzo desperdiciado.

Empieza por la directiva, no por el nombre del archivo

Lee la configuración activa y averigua qué directiva apunta al material en cuestión. Las opciones TLS de OpenVPN usan ca para material de certificado de confianza, cert para el certificado del par local y key para la clave privada que le corresponde.

Los nombres de archivo no demuestran nada. Un archivo llamado key.pem puede contener un certificado, y un bloque incrustado en el perfil puede contener exactamente el mismo objeto que un archivo aparte en el disco. Abre el archivo y mira su cabecera en lugar de fiarte del nombre. Esa única comprobación elimina la mayor parte de la ambigüedad del informe.

Si el perfil es un paquete PKCS#12, descomprímelo en un lugar controlado para ver qué contiene realmente. Un solo paquete puede llevar un certificado, su cadena y una clave privada, lo que significa que una filtración del paquete es una filtración de los tres.

Escribe la clasificación antes de que nadie cambie un archivo: objeto, directiva, qué pares lo tienen y quién puede leerlo. De esa frase depende el resto de la respuesta.

Un certificado de CA está diseñado para compartirse

Un certificado de CA público es material de confianza. Los clientes lo necesitan para verificar el servidor, y distribuirlo es el caso normal y no un incidente. Publicarlo no publica la clave privada de firma de la CA, que es el objeto que permitiría a un atacante crear identidades nuevas.

Esa distinción merece decirse explícitamente en el ticket, porque las dos cosas se confunden constantemente. La pregunta que hay que responder es si el archivo filtrado es el certificado o la clave de firma, y un vistazo rápido al contenido del archivo lo resuelve. Un certificado lleva una clave pública y una firma; la clave de firma no aparece en él en absoluto.

La distribución sigue mereciendo cuidado. Los clientes deberían obtener el certificado por la vía aprobada de entrega de perfiles, no de un sitio de pegado, y un certificado que llega por una ruta no fiable puede ser sustituido en tránsito.

Una clave de par y un secreto tls-auth no son

La clave privada de un par es material de identidad. Una vez copiada, el servidor ya no puede distinguir el dispositivo previsto de cualquiera que tenga la copia, porque la posesión exclusiva era la propiedad que se demostraba. Continuar la autorización y la sustitución son decisiones del propietario del VPN, no de quien encontró el archivo.

Un secreto tls-auth es una tercera cosa. Añade autenticación HMAC alrededor de los paquetes del canal de control para que los autenticados incorrectamente se descarten antes de un intercambio TLS, y no es ni la clave privada del par ni la clave que cifra los datos de la aplicación.

Si ese secreto compartido es público, la barrera que ofrecía ha desaparecido para todos los que lo tienen. No se sigue que cada poseedor supere las comprobaciones de certificado y de usuario que hay detrás, y por eso la clasificación importa más que el nivel de alarma. Di qué barrera cayó y di cuáles quedan.

Repara el rol que se filtró, no uno vecino

Un secreto compartido no puede volver a hacerse privado renombrando el archivo u ocultando el enlace de descarga. Sustituir significa generar un valor nuevo y distribuirlo a cada par en un cambio coordinado, y sustituir solo un lado rompe el acuerdo para todos los que aún tienen el valor antiguo.

Si se expuso la identidad de un par, usa el proceso de revocación y re-registro del operador para esa identidad. Cambiar la contraseña de una cuenta no relacionada no invalida un certificado copiado, y cambiar el archivo tls-auth tampoco.

Confirma qué aplica realmente el servidor desplegado antes de fiarte de cualquiera de estas cosas. Una lista de revocación que no se actualiza, o una comprobación de rol que se desactivó durante una caída, cambian del todo la respuesta. Lee la configuración en ejecución y no la copia del repositorio.

Juzga el tráfico pasado con sus propios términos

Un archivo expuesto no dice por sí solo si las sesiones capturadas anteriormente pueden descifrarse. Eso depende del método de establecimiento de claves, del material expuesto y de qué registros existan, y tanto «se ha perdido todo el tráfico» como «no ha pasado nada» son conjeturas sin esos datos.

No publiques otra copia de la credencial mientras preguntas a qué categoría pertenece. Comparte en cambio los nombres de las directivas y los metadatos no secretos por la vía de soporte aprobada.

La conclusión útil nombra el objeto, su rol, la protección que se perdió y la acción coordinada necesaria. Cualquier cosa más corta es un titular y no una evaluación.