Emites un certificado distinto para cada portátil, así que supones que la VPN puede distinguirlos. No puede. Un certificado de cliente demuestra que quien se conecta tiene la clave privada correspondiente, y un perfil copiado también la tiene.

El certificado por dispositivo sigue siendo una buena idea. Solo hace un trabajo distinto del que la mayoría espera.

Qué demuestra realmente un certificado de cliente

Durante el protocolo de enlace, el cliente firma con la clave privada que corresponde a su certificado, y el servidor verifica esa firma contra la CA en la que confía. Nada en ese intercambio describe la máquina. Cualquier dispositivo que tenga el certificado y la clave produce una firma idéntica, así que un perfil copiado a un segundo portátil se ve exactamente como el original. El certificado nombra una identidad; no nombra hardware.

La unicidad por dispositivo sigue valiendo la pena, porque hace precisa la revocación. Es una propiedad administrativa, no un candado técnico.

Tres niveles de almacenamiento de la clave

El primer nivel es un archivo de clave en el disco. Es portátil por diseño, y allí viven la mayoría de los perfiles de OpenVPN.

El segundo nivel es una clave que el sistema operativo marca como no exportable. Windows puede generar una clave de dispositivo en su almacén de certificados y negar la exportación normal, lo que frena la copia casual. No está respaldada por hardware, y con suficiente acceso a la máquina esas claves se pueden recuperar, así que eleva el esfuerzo en lugar de levantar un muro.

El tercer nivel es una clave generada dentro de hardware de seguridad: un TPM, una tarjeta inteligente, una SIM o un token PIV. Esos módulos carecen de la circuitería para exportar la clave que generaron, y la firma ocurre dentro del módulo. La clave nunca se convierte en un archivo que alguien pueda copiar.

Where the key livesCopyableWhat it buys you
Key file inside the profileTriviallyRevocation granularity, nothing more
OS non-exportable key storeHard, not impossibleStops casual profile sharing
TPM or PIV tokenNoBinding the server can rely on

Esa tabla es todo el argumento en tres filas.

Qué puede y qué no puede hacer easy-rsa

Emitir certificados por dispositivo es sencillo. Crea un nombre común distinto por dispositivo contra la misma CA, por ejemplo ./easyrsa build-client-full laptop-a nopass, y repítelo para cada dispositivo. Anota qué nombre común pertenece a qué persona y máquina.

La revocación es igual de directa: ./easyrsa revoke laptop-a, regenera la CRL con ./easyrsa gen-crl y asegúrate de que el servidor realmente la lea mediante crl-verify.

Lo que la CA no puede hacer es verificar dónde vive después la clave privada. Si generas la clave en el host de la CA y la copias al dispositivo, creaste una segunda copia en el momento de la emisión. Una clave no exportable tiene que generarse en el dispositivo, o importarse a hardware que no la libere.

Controles que sobreviven a un perfil copiado

Supón que el perfil se puede copiar y diseña en consecuencia. Vincula la cuenta a un segundo factor para que un certificado por sí solo no baste. Da a cada dispositivo su propia política para que el alcance de una identidad siga limitado. Y vigila el mismo nombre común conectado desde dos direcciones a la vez, que es como se ve un perfil compartido en un registro de conexiones.

La revocación rápida y documentada es el control que sigue funcionando después de que se haya producido una copia. Todo lo demás es prevención.

La afirmación con la que el servidor realmente puede contar

La unicidad viene de la CA. La vinculación al dispositivo viene del almacenamiento de la clave. Solo el hardware que no puede exportar su clave convierte un certificado por dispositivo en una afirmación que el servidor impone, en lugar de una política que todos aceptan seguir.

Artículos relacionados