Que URI de PKCS#11 necesita OpenConnect para un token?

Unha tarxeta intelixente que xa contén a clave correcta ten que recibir a indicación de que obxecto usar nela. OpenConnect non quere un ficheiro .key copiado nesa situación; quere un URI de PKCS#11 que nomee o certificado e, cando a busca automática non pode rematar a tarefa, a clave privada que está ao lado. A parte incómoda é que un URI sintacticamente válido non demostra nada. Ten que nomear a inscrición na que a pasarela xa confía, non simplemente un obxecto que a tarxeta estea disposta a abrir.

Que quere o cliente no canto dunha clave exportada

A opción -c adoita tomar unha ruta de ficheiro, pero cando o valor se analiza como un URI de PKCS#11, OpenConnect trátao como unha referencia a un obxecto dentro do token e non a un ficheiro no disco. A opción -k compórtase igual coa clave privada. Non se exporta nada e a clave nunca abandona a protección que ofrece a tarxeta. O que o cliente necesita de vós é un nome no que coincidan o módulo do token, o almacén de certificados e a inscrición da pasarela.

Nesa última restrición é onde se atascan a maioría dos intentos. Un URI pode estar perfectamente ben formado e aínda así seleccionar un certificado que a pasarela rexeitará, porque validez e relevancia son preguntas separadas. A comprobación que paga a pena é unha comparación co rexistro da inscrición, non un exame do primeiro obxecto que se abra por casualidade.

Dous URI, dous traballos distintos

O URI do certificado responde que identidade está a reclamar. Apunta a un obxecto de certificado cuxa clave pública e liña de asunto coinciden co perfil de conta ou de dispositivo que emitiu o administrador de VPN. Ese mesmo certificado adoita chegar cun obxecto de clave privada almacenado ao lado, e ese par é o que o saúdo TLS necesita realmente.

O URI da clave responde onde vive o material privado correspondente cando OpenConnect non pode inferilo. Co só -c definido, o cliente constrúe unha busca de clave a partir das propiedades do certificado; proporcionar -k substitúe a conxectura por unha referencia explícita a un obxecto. O PIN do token é unha terceira entrada non relacionada: desbloquea a tarxeta para a operación e nunca identifica un obxecto.

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

Todo o que hai nesa cadea entre comiñas son datos. Os puntos e coma separan os atributos do URI e os escapes de porcentaxe codifican caracteres que, doutro xeito, romperían a análise, así que todo o argumento ten que sobrevivir intacto á shell.

Atopar o URI que coincide coa vosa inscrición

GnuTLS inclúe p11tool, que enumera a que pode chegar realmente o usuario actual a través de p11-kit. Comezade con p11tool --list-tokens e despois enumerade os obxectos de certificado do token que vos interesa. Engadide --login cando os obxectos só aparecen tras un PIN, e comparade o asunto e o emisor co rexistro da inscrición en lugar de escoller o que apareza primeiro.

Se o token non aparece en absoluto, o problema está por baixo de OpenConnect: p11-kit non ten ningún módulo rexistrado para ese middleware, ou o módulo está rexistrado para outra conta. O rexistro en todo o sistema vive en /etc/pkcs11/modules, e un directorio por usuario pode conter o mesmo sen tocar a copia do sistema. Comprobade que a ruta do provedor no ficheiro do módulo apunte a unha biblioteca que o software do lector instalase realmente.

Cando copiedes o URI da lista, mantede as comiñas ao seu redor. Os puntos e coma sen comiñas truncan o argumento no primeiro atributo e o cliente informa entón dun obxecto que non pode atopar.

Cando a busca automática da clave se rende

OpenConnect pode derivar unha busca de clave do URI do certificado, pero a coincidencia exacta que realiza depende da versión, e o tratamento do tipo de obxecto e da etiqueta cambiou co tempo. O consello de acurtar o URI ata que funcione describe unha volta antiga, non un requisito. Se a busca derivada falla, nomeade a clave explicitamente con -k en lugar de converter o URI do certificado en algo máis vago.

Confirmade que a clave existe e é visible con p11tool --list-keys antes de culpar o cliente. Despois comprobade que o obxecto está marcado como utilizábel para sinatura ou descifrado, porque unha clave xerada con atributos incorrectos non pode completar un saúdo por correcto que sexa o URI. Non trasladedes un valor pkcs11-id serializado dun perfil de OpenVPN a unha opción de OpenConnect; os dous clientes usan formatos de identificador distintos mesmo cando falan coa mesma tarxeta.

Se o URI se resolve e o PIN se acepta pero a autenticación segue fallando, deixade de axustar o URI. Lede o erro da propia pasarela, porque o seguinte fallo está por riba do token.

Fallos que só parecen problemas de URI

Unha pasarela que fala outro protocolo fallará igual tanto se o voso URI é correcto como se non. OpenConnect substituíu o cliente vpnc heredado por algunha razón, e o soporte de tarxetas non fai compatible un protocolo de pasarela incompatible. Confirmade o protocolo esperado do servidor e a disposición de autenticación antes de gastar outra hora en atributos do obxecto.

A validación da identidade do servidor tamén é unha capa aparte. O cliente verifica o certificado da pasarela contra o seu almacén de confianza, e esa comprobación execútase despois de que a tarxeta xa fixo a súa parte. Os permisos do lector e un servizo pcscd detido producen o mesmo síntoma externo, un token ilexible, cunha solución moito máis sinxela.

Traballade de dentro cara a fóra desde o obxecto: se p11tool ve o token, se ve o certificado e a clave, se OpenConnect acepta o URI, e só entón preguntade se a pasarela acepta a identidade. Cada paso ten a súa propia mensaxe de erro, e cada un é máis barato de probar ca o seguinte.