Quin URI de PKCS#11 necessita OpenConnect per a un testimoni?

Una targeta intel·ligent que ja conté la clau correcta encara ha de rebre l’ordre de quin objecte hi ha d’utilitzar. OpenConnect no vol un fitxer .key copiat en aquesta situació; vol un URI de PKCS#11 que anomeni el certificat i, quan la cerca automàtica no pot acabar la feina, la clau privada del costat. La part incòmoda és que un URI sintàcticament vàlid no demostra res. Ha de anomenar l’enregistrament en què la passarel·la ja confia, no tan sols un objecte que la targeta estigui disposada a obrir.

Què vol el client en lloc d’una clau exportada

L’opció -c normalment accepta un camí de fitxer, però quan el valor s’analitza com un URI de PKCS#11, OpenConnect el tracta com una referència a un objecte dins del testimoni i no a un fitxer al disc. L’opció -k es comporta igual per a la clau privada. No s’exporta res i la clau no surt mai de la protecció que ofereix la targeta. El que el client necessita de vosaltres és un nom amb què coincideixin el mòdul del testimoni, el magatzem de certificats i l’enregistrament de la passarel·la.

És en aquesta darrera restricció on s’encallen la majoria d’intents. Un URI pot estar perfectament ben format i tot i així seleccionar un certificat que la passarel·la rebutjarà, perquè validesa i rellevància són qüestions separades. La comprovació que val la pena és una comparació amb el registre d’enregistrament, no una cerca del primer objecte que s’obre per casualitat.

Dos URI, dues feines diferents

L’URI del certificat respon quina identitat reivindiqueu. Apunta a un objecte de certificat la clau pública i la línia de subjecte del qual coincideixen amb el perfil de compte o dispositiu que va emetre l’administrador de VPN. Aquest mateix certificat sol arribar amb un objecte de clau privada desat al costat, i aquesta parella és el que la negociació TLS necessita realment.

L’URI de la clau respon on viu el material privat corresponent quan OpenConnect no el pot inferir. Amb només -c definit, el client construeix una cerca de clau a partir de les propietats del certificat; proporcionar -k substitueix l’endevinalla per una referència explícita a un objecte. El PIN del testimoni és una tercera entrada no relacionada: desbloqueja la targeta per a l’operació i mai no identifica cap objecte.

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

Tot el que hi ha en aquesta cadena entre cometes són dades. Els punts i coma separen els atributs de l’URI i els escapaments percentuals codifiquen caràcters que d’una altra manera trencarien l’anàlisi, així que tot l’argument ha de sobreviure intacte a l’intèrpret d’ordres.

Trobar l’URI que coincideix amb el vostre enregistrament

GnuTLS inclou p11tool, que llista què pot assolir realment l’usuari actual a través de p11-kit. Comenceu amb p11tool --list-tokens i després llisteu els objectes de certificat del testimoni que us interessa. Afegiu --login quan els objectes només apareixen després d’un PIN, i compareu el subjecte i l’emissor amb el registre d’enregistrament en lloc de triar el que aparegui primer.

Si el testimoni no apareix gens, el problema és per sota d’OpenConnect: p11-kit no té cap mòdul registrat per a aquest middleware, o el mòdul està registrat per a un altre compte. El registre a tot el sistema viu a /etc/pkcs11/modules, i un directori per usuari pot contenir el mateix sense tocar la còpia del sistema. Comproveu que el camí del proveïdor al fitxer del mòdul apunti a una biblioteca que el programari del lector hagi instal·lat realment.

Quan copieu l’URI de la llista, manteniu les cometes al seu voltant. Els punts i coma sense cometes trunquen l’argument al primer atribut i el client informa aleshores d’un objecte que no troba.

Quan la cerca automàtica de la clau es rendeix

OpenConnect pot derivar una cerca de clau de l’URI del certificat, però la coincidència exacta que fa depèn de la versió, i el tractament del tipus d’objecte i de l’etiqueta ha canviat amb el temps. El consell que us diu d’escurçar l’URI fins que funcioni descriu una solució antiga, no un requisit. Si la cerca derivada falla, anomeneu la clau explícitament amb -k en lloc d’editar l’URI del certificat cap a una cosa més vaga.

Confirmeu que la clau existeix i és visible amb p11tool --list-keys abans de culpar el client. Després comproveu que l’objecte està marcat com a utilitzable per a signatura o desxifrat, ja que una clau generada amb atributs incorrectes no pot completar una negociació per correcte que sigui l’URI. No trasplanteu un valor pkcs11-id serialitzat d’un perfil d’OpenVPN a una opció d’OpenConnect; els dos clients fan servir formats d’identificador diferents fins i tot quan parlen amb la mateixa targeta.

Si l’URI es resol i el PIN s’accepta però l’autenticació encara falla, deixeu d’ajustar l’URI. Llegiu l’error de la mateixa passarel·la, perquè la fallada següent és per sobre del testimoni.

Fallades que només semblen problemes d’URI

Una passarel·la que parla un protocol diferent fallarà igual tant si el vostre URI és correcte com si és incorrecte. OpenConnect va substituir el client vpnc antic per una raó, i el suport de targetes no fa compatible un protocol de passarel·la incompatible. Confirmeu el protocol esperat del servidor i la disposició d’autenticació abans de gastar una altra hora en els atributs de l’objecte.

La validació de la identitat del servidor també és una capa separada. El client verifica el certificat de la passarel·la contra el seu magatzem de confiança, i aquesta comprovació s’executa després que la targeta ja hagi fet la seva part. Els permisos del lector i un servei pcscd aturat produeixen el mateix símptoma extern, un testimoni il·legible, amb una solució molt més senzilla.

Treballeu de l’objecte cap enfora: p11tool veu el testimoni, veu el certificat i la clau, OpenConnect accepta l’URI, i només aleshores pregunteu si la passarel·la accepta la identitat. Cada pas té el seu propi missatge d’error, i cadascun és més barat de provar que el següent.