Por qué las claves del servidor y las credenciales de usuario necesitan dueños separados

La clave que demuestra que tu puerta de enlace es ella misma y la credencial que dice que una persona puede unirse son ambos secretos, y ahí termina el parecido. Uno identifica un servicio ante cada cliente; el otro identifica a un usuario ante ese servicio. Mezclarlos ahorra un paso durante la instalación y cuesta una tarde durante un incidente, porque la recuperación de cada uno no es la misma operación. La separación es aburrida de configurar y memorable de omitir.

Dos secretos, dos dueños distintos

La puerta de enlace guarda una clave privada o un certificado cuya única tarea es demostrar su identidad durante el protocolo de enlace. Los clientes necesitan el material público correspondiente para verificarla, y nunca necesitan la mitad privada. Esa asimetría es lo que hace posible la autenticación del servidor sin dar a cada usuario la capacidad de suplantar al servidor.

El material de usuario va en la otra dirección. Una clave privada de cliente, un certificado de cliente o una contraseña demuestran que a esta persona o dispositivo concreto se le concedió acceso. Se espera que se distribuya, se copie entre dispositivos y finalmente se revoque.

WireGuard hace obvia la separación porque cada participante tiene un par de claves: la clave privada del servidor se queda en el servidor, y un archivo de configuración que entregas a un usuario contiene su propia clave privada más la clave pública del servidor. Un perfil que contiene la clave privada del servidor no es un atajo, es un compromiso esperando un recurso compartido.

Tres preguntas que deciden la separación

Pregunta quién debe poder leer el secreto, qué permitiría hacer a un atacante una exposición y si la solución es una revocación o una reconstrucción del servicio.

Si un usuario puede leerlo y demuestra la identidad de la puerta de enlace, la respuesta a la segunda pregunta es que el atacante puede suplantar tu servidor ante cada cliente — el peor resultado, porque los clientes están diseñados para confiar en esa identidad. Si solo demuestra a un usuario, la exposición concede el acceso de ese usuario a un par, y la revocación es una operación rutinaria. Si es una clave de autoridad de certificación, la exposición es peor que ambas, ya que el atacante puede acuñar identidades en las que confía cada extremo.

Esas tres respuestas producen la regla de almacenamiento: la clave de CA vive fuera de línea o en una caja fuerte, la clave de la puerta de enlace vive en la puerta de enlace, y las claves de usuario viven con los usuarios. Cualquier disposición que ponga las tres en un solo directorio por comodidad ha convertido una decisión en un accidente.

Lo que un cliente realmente necesita

Un cliente necesita el certificado público o la clave pública del par, el material de CA o la huella en la que debe confiar, su propia clave privada y los detalles del extremo. Esa lista no contiene nada que pertenezca a la identidad privada de la puerta de enlace.

La documentación es donde esto se filtra. Una guía que dice copia el directorio del servidor y borra lo que no necesites ya ha enseñado el modelo equivocado, porque el archivo que queda tras el paso de borrado rara vez lo revisa alguien.

Revoca a un usuario sin tocar la puerta de enlace

Como las identidades de usuario se emiten por separado, pueden retirarse por separado. Un despliegue basado en certificados revoca el certificado de cliente y publica una lista de revocación actualizada; un despliegue de WireGuard elimina la entrada del par de la configuración del servidor. Ninguna de esas operaciones cambia la clave propia de la puerta de enlace.

Conserva el registro de emisión, o no sabrás qué identidad retirar. Una hoja de cálculo basta, siempre que nombre a la persona, el dispositivo, el número de serie o la clave pública y la fecha, y siempre que alguien se encargue de ella después de que se marche la persona que la construyó.

Los comandos siguientes inspeccionan un certificado de cliente y luego lo revocan mediante una autoridad al estilo de OpenSSL, que es el flujo que easy-rsa envuelve:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Publica la nueva lista donde los clientes la comprueban, o la revocación es una nota en un archivo que no cambia nada. Si tu puerta de enlace acepta certificados de cliente sin consultar una lista de revocación, dilo explícitamente en lugar de insinuar que la revocación funciona.

Mantén las copias de seguridad tan separadas como los secretos

Un archivo de reconstrucción contiene legítimamente la clave de la puerta de enlace y el material de CA, porque sin ellos una restauración no puede reproducir el servicio. Un paquete de configuración de cliente no debe, y los dos no deben guardarse juntos. Etiqueta cada archivo por quién puede guardarlo, no por la fecha en que se hizo. Esa etiqueta es lo que lee un administrador cansado a las dos de la madrugada.

Esa distinción también fija quién puede recuperar cada uno. Administrar la puerta de enlace, emitir identidades de usuario y leer copias de seguridad son tres poderes distintos, y quien necesita uno no necesita automáticamente los otros. Escribe esos permisos y luego compruébalos contra lo que tu almacenamiento permite realmente, porque la herencia de directorios concede en silencio más de lo que la política pretende.