¿Puedes compartir una clave pública de VPN? Revisa estas tres cosas

Puedes entregar tu clave pública de VPN a un par, a un proveedor o a un foro, y el túnel sigue funcionando. La clave privada no puedes entregarla, ni siquiera al personal de soporte, sin entregar la identidad que esa clave demuestra. La decisión rara vez queda tan limpia, porque la gente confunde qué mitad del par está mirando y porque algunos despliegues tratan el valor público como un nombre. Tres comprobaciones lo resuelven: qué mitad tienes, a qué la vincula el despliegue y cuánto cuesta sustituirla.

Comprobación uno: qué mitad del par está en tu portapapeles

Las claves asimétricas van en parejas, y la dirección de la derivación es todo el asunto. En WireGuard la clave privada son 32 bytes aleatorios y la clave pública se calcula a partir de ella; no puedes ir en la dirección contraria. wg genkey escribe el valor privado, wg pubkey deriva el público, y solo el segundo pertenece a un mensaje dirigido a un par.

wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt

El mundo de los certificados usa la misma división con más piezas móviles. Un certificado de servidor lleva una clave pública y nombres, y lo firma una clave privada de la CA que nunca sale de la CA. Un cliente que verifica ese servidor necesita el certificado de la CA, que es público, y no tiene ningún uso para la clave privada de firma de la CA.

Si no estás seguro de qué valor tienes, busca el marcador en lugar del nombre del archivo. Un bloque PEM que empieza por -----BEGIN PRIVATE KEY-----, o la forma más antigua BEGIN RSA PRIVATE KEY, es la mitad secreta. Un valor que puedes pegar sin ese marcador es candidato a compartirse, sujeto a las dos comprobaciones siguientes.

Comprobación dos: a qué vincula el despliegue ese valor público

La seguridad criptográfica y el anonimato son propiedades distintas. La clave pública de un par de WireGuard es un identificador estable dentro del despliegue: la configuración del servidor la lista, el handshake la nombra y un administrador que lee registros ve la misma cadena cada vez que ese par se conecta. Publica la clave junto a una pregunta sobre tu instalación y habrás vinculado esa cadena con todo lo demás de la publicación.

Los certificados filtran identidad por diseño. Los campos Subject y subject alternative name son legibles, y en los certificados TLS de confianza pública el propio certificado se publica en los registros Certificate Transparency, que son consultables. Nada de eso expone una clave privada, y todo ello expone una relación.

Aquí es donde los despliegues difieren, y eso decide la respuesta. Un par de prueba desechable en un servidor de laboratorio es un objeto distinto de la clave que identifica el extremo entre sedes de una empresa, aunque los bytes parezcan idénticos.

Comprobación tres: qué puedes revocar y con qué rapidez

La tercera comprobación separa las dos mitades por completo. Una clave pública que se ha publicado puede sustituirse según tu calendario. Una clave privada que se ha publicado no puede retirarse: borrar tu copia no toca las copias ya tomadas, y cada par que confiaba en ella ahora confía en algo que tiene un extraño.

La revocación es una acción de configuración, no una acción criptográfica. WireGuard no incluye ninguna lista de revocación, así que quitas el par:

wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart

OpenVPN los despliegues basados en certificados revocan el certificado y publican una CRL que el servidor comprueba de verdad mediante crl-verify. Sin esa directiva, la lista de revocación es decoración. En cualquier caso la secuencia es la misma: emite una sustitución, distribúyela por el canal admitido y después retira la identidad antigua.

Los errores que vienen de fundir las tres comprobaciones

La mayoría de las filtraciones reales no son una persona que decide publicar una clave privada. Son un perfil entero pegado en un foro: un .conf de WireGuard con una línea PrivateKey, o un paquete .ovpn con un bloque de clave incrustado, o una captura de una ventana de cliente que incluye por casualidad el campo de la clave. El valor público probablemente estaba bien; viajó con la parte que no lo estaba.

Los flujos de trabajo de soporte son la segunda fuente. Ningún paso de verificación legítimo necesita tu clave privada, porque la otra parte deriva de la mitad pública lo que necesita. Cuando un formulario o una persona pide el valor privado, la respuesta correcta es el público más el comando local que lo produce.

Los registros y las capturas de pantalla pertenecen a la misma categoría. La salida de diagnóstico puede llevar material de claves, identificadores de sesión y direcciones internas, y publicarlo todo para obtener respuesta a una pregunta cambia una pequeña comodidad por una exposición mayor.

Cuando se filtra un valor privado, retira la identidad

Si un valor privado se ha escapado, trata esa identidad como retirada. Genera un par nuevo, instala la mitad pública donde los pares la esperan, quita el par antiguo o revoca el certificado antiguo y revisa los lugares donde lo publicaste. No puedes borrar copias que no controlas, así que la retirada va del futuro, no del pasado.

Después escribe la distribución: qué clave pertenece a qué dispositivo, quién tiene una copia, cómo se entrega una sustitución y quién retira un par retirado. Esas son las partes que la gente olvida, y deciden cuánto tiempo una filtración sigue siendo útil.