¿Qué URI de PKCS#11 necesita OpenConnect para un token?

Una tarjeta inteligente que ya contiene la clave correcta todavía tiene que recibir la indicación de qué objeto usar en ella. OpenConnect no quiere un archivo .key copiado en esa situación; quiere un URI de PKCS#11 que nombre el certificado y, cuando la búsqueda automática no puede terminar la tarea, la clave privada que está al lado. La parte incómoda es que un URI sintácticamente válido no demuestra nada. Tiene que nombrar el alta en la que la puerta de enlace ya confía, no simplemente un objeto que la tarjeta esté dispuesta a abrir.

Qué quiere el cliente en lugar de una clave exportada

La opción -c normalmente toma una ruta de archivo, pero cuando el valor se analiza como un URI de PKCS#11, OpenConnect lo trata como una referencia a un objeto dentro del token y no a un archivo en el disco. La opción -k se comporta igual con la clave privada. No se exporta nada y la clave nunca abandona la protección que ofrece la tarjeta. Lo que el cliente necesita de usted es un nombre en el que coincidan el módulo del token, el almacén de certificados y el alta de la puerta de enlace.

En esa última restricción es donde se atascan la mayoría de los intentos. Un URI puede estar perfectamente bien formado y aun así seleccionar un certificado que la puerta de enlace rechazará, porque validez y relevancia son preguntas separadas. La comprobación que merece la pena es una comparación con el registro del alta, no un escaneo del primer objeto que se abra por casualidad.

Dos URI, dos trabajos distintos

El URI del certificado responde qué identidad está reclamando. Apunta a un objeto de certificado cuya clave pública y línea de asunto coinciden con el perfil de cuenta o de dispositivo que emitió el administrador de VPN. Ese mismo certificado suele llegar con un objeto de clave privada almacenado junto a él, y ese par es lo que el saludo TLS necesita realmente.

El URI de la clave responde dónde vive el material privado correspondiente cuando OpenConnect no puede inferirlo. Con solo -c definido, el cliente construye una búsqueda de clave a partir de las propiedades del certificado; proporcionar -k sustituye la conjetura por una referencia explícita a un objeto. El PIN del token es una tercera entrada no relacionada: desbloquea la tarjeta para la operación y nunca identifica un objeto.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

Todo lo que hay en esa cadena entre comillas son datos. Los puntos y coma separan los atributos del URI y los escapes de porcentaje codifican caracteres que, de otro modo, romperían el análisis, así que todo el argumento tiene que sobrevivir intacto al shell.

Encontrar el URI que coincide con su alta

GnuTLS incluye p11tool, que enumera a qué puede llegar realmente el usuario actual a través de p11-kit. Empiece con p11tool --list-tokens y luego enumere los objetos de certificado del token que le interesa. Añada --login cuando los objetos solo aparecen tras un PIN, y compare el sujeto y el emisor con el registro del alta en lugar de elegir lo que aparezca primero.

Si el token no aparece en absoluto, el problema está por debajo de OpenConnect: p11-kit no tiene ningún módulo registrado para ese middleware, o el módulo está registrado para otra cuenta. El registro en todo el sistema vive en /etc/pkcs11/modules, y un directorio por usuario puede contener lo mismo sin tocar la copia del sistema. Compruebe que la ruta del proveedor en el archivo del módulo apunte a una biblioteca que el software del lector haya instalado realmente.

Cuando copie el URI de la lista, mantenga las comillas a su alrededor. Los puntos y coma sin comillas truncan el argumento en el primer atributo y el cliente informa entonces de un objeto que no puede encontrar.

Cuando la búsqueda automática de la clave se rinde

OpenConnect puede derivar una búsqueda de clave del URI del certificado, pero la coincidencia exacta que realiza depende de la versión, y el tratamiento del tipo de objeto y de la etiqueta ha cambiado con el tiempo. El consejo de acortar el URI hasta que funcione describe un rodeo antiguo, no un requisito. Si la búsqueda derivada falla, nombre la clave explícitamente con -k en lugar de convertir el URI del certificado en algo más vago.

Confirme que la clave existe y es visible con p11tool --list-keys antes de culpar al cliente. Después compruebe que el objeto está marcado como utilizable para firma o descifrado, porque una clave generada con atributos incorrectos no puede completar un saludo por correcto que sea el URI. No trasplante un valor pkcs11-id serializado de un perfil de OpenVPN a una opción de OpenConnect; los dos clientes usan formatos de identificador distintos incluso cuando hablan con la misma tarjeta.

Si el URI se resuelve y el PIN se acepta pero la autenticación sigue fallando, deje de ajustar el URI. Lea el error de la propia puerta de enlace, porque el siguiente fallo está por encima del token.

Fallos que solo parecen problemas de URI

Una puerta de enlace que habla otro protocolo fallará igual tanto si su URI es correcto como si no. OpenConnect sustituyó al cliente vpnc heredado por alguna razón, y el soporte de tarjetas no hace compatible un protocolo de puerta de enlace incompatible. Confirme el protocolo esperado del servidor y la disposición de autenticación antes de gastar otra hora en atributos del objeto.

La validación de la identidad del servidor también es una capa aparte. El cliente verifica el certificado de la puerta de enlace contra su almacén de confianza, y esa comprobación se ejecuta después de que la tarjeta ya haya hecho su parte. Los permisos del lector y un servicio pcscd detenido producen el mismo síntoma externo, un token ilegible, con una solución mucho más sencilla.

Trabaje de dentro hacia fuera desde el objeto: si p11tool ve el token, si ve el certificado y la clave, si OpenConnect acepta el URI, y solo entonces pregunte si la puerta de enlace acepta la identidad. Cada paso tiene su propio mensaje de error, y cada uno es más barato de probar que el siguiente.