Que URI PKCS#11 o OpenConnect precisa para um token?

Um cartão inteligente que já contém a chave correta ainda tem de ser informado de qual objeto nele usar. O OpenConnect não quer um ficheiro .key copiado nessa situação; quer um URI PKCS#11 que nomeie o certificado e, quando a pesquisa automática não consegue terminar o trabalho, a chave privada ao lado. A parte incómoda é que um URI sintaticamente válido não prova nada. Tem de nomear o registo em que o gateway já confia, não apenas um objeto que o cartão esteja disposto a abrir.

O que o cliente quer em vez de uma chave exportada

A opção -c costuma receber um caminho de ficheiro, mas quando o valor é analisado como URI PKCS#11, o OpenConnect trata-o como uma referência a um objeto dentro do token e não a um ficheiro no disco. A opção -k comporta-se da mesma forma para a chave privada. Nada é exportado e a chave nunca abandona a proteção que o cartão oferece. O que o cliente precisa de si é um nome em que o módulo do token, o arquivo de certificados e o registo no gateway concordem.

É nessa última restrição que a maioria das tentativas encrava. Um URI pode estar perfeitamente bem formado e ainda assim selecionar um certificado que o gateway vai rejeitar, porque validade e relevância são perguntas separadas. A verificação que vale a pena é uma comparação com o registo de inscrição, não uma pesquisa do primeiro objeto que se abre por acaso.

Dois URI, dois trabalhos diferentes

O URI do certificado responde a que identidade está a reclamar. Aponta para um objeto de certificado cuja chave pública e linha de assunto coincidem com o perfil de conta ou de dispositivo emitido pelo administrador de VPN. O mesmo certificado chega habitualmente com um objeto de chave privada guardado ao lado, e é esse par que o handshake TLS realmente precisa.

O URI da chave responde a onde vive o material privado correspondente quando o OpenConnect não o consegue inferir. Com apenas -c definido, o cliente constrói uma pesquisa de chave a partir das propriedades do certificado; fornecer -k substitui a suposição por uma referência explícita a um objeto. O PIN do token é uma terceira entrada, sem relação: desbloqueia o cartão para a operação e nunca identifica um objeto.

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

Tudo nessa cadeia entre aspas são dados. Os pontos e vírgulas separam os atributos do URI e as sequências de escape percentuais codificam caracteres que, de outro modo, quebrariam a análise, pelo que todo o argumento tem de sobreviver intacto à shell.

Encontrar o URI que corresponde ao seu registo

O GnuTLS inclui o p11tool, que lista aquilo a que o utilizador atual consegue realmente chegar através do p11-kit. Comece com p11tool --list-tokens e depois liste os objetos de certificado no token que lhe interessa. Acrescente --login quando os objetos só aparecem depois de um PIN, e compare o assunto e o emissor com o registo de inscrição em vez de escolher o que aparecer primeiro.

Se o token não aparecer de todo, o problema está abaixo do OpenConnect: o p11-kit não tem nenhum módulo registado para esse middleware, ou o módulo está registado para outra conta. O registo à escala do sistema vive em /etc/pkcs11/modules, e um diretório por utilizador pode conter o mesmo sem tocar na cópia do sistema. Verifique se o caminho do fornecedor no ficheiro do módulo aponta para uma biblioteca que o software do leitor instalou realmente.

Quando copiar o URI da lista, mantenha as aspas à volta. Pontos e vírgulas sem aspas truncam o argumento no primeiro atributo e o cliente relata então um objeto que não consegue encontrar.

Quando a pesquisa automática da chave desiste

O OpenConnect pode derivar uma pesquisa de chave do URI do certificado, mas a correspondência exata que efetua depende da versão, e o tratamento do tipo de objeto e da etiqueta mudou ao longo do tempo. O conselho de encurtar o URI até funcionar descreve um contorno antigo, não um requisito. Se a pesquisa derivada falhar, nomeie a chave explicitamente com -k em vez de transformar o URI do certificado em algo mais vago.

Confirme que a chave existe e é visível com p11tool --list-keys antes de culpar o cliente. Depois verifique se o objeto está marcado como utilizável para assinatura ou decifragem, porque uma chave gerada com atributos errados não consegue completar um handshake, por muito correto que seja o URI. Não transfira um valor pkcs11-id serializado de um perfil OpenVPN para uma opção do OpenConnect; os dois clientes usam formatos de identificador diferentes mesmo quando falam com o mesmo cartão.

Se o URI se resolver e o PIN for aceite mas a autenticação continuar a falhar, pare de afinar o URI. Leia o erro do próprio gateway, porque a falha seguinte está acima do token.

Falhas que só parecem problemas de URI

Um gateway que fala outro protocolo falhará de forma idêntica quer o seu URI esteja correto quer não. O OpenConnect substituiu o antigo cliente vpnc por uma razão, e o suporte de cartões não torna compatível um protocolo de gateway incompatível. Confirme o protocolo esperado do servidor e a disposição da autenticação antes de gastar mais uma hora em atributos do objeto.

A validação da identidade do servidor é também uma camada separada. O cliente verifica o certificado do gateway contra o seu arquivo de confiança, e essa verificação corre depois de o cartão já ter feito a sua parte. Permissões do leitor e um serviço pcscd parado produzem o mesmo sintoma externo, um token ilegível, com uma correção muito mais simples.

Trabalhe do objeto para fora: o p11tool vê o token, vê o certificado e a chave, o OpenConnect aceita o URI, e só então pergunte se o gateway aceita a identidade. Cada passo tem a sua própria mensagem de erro, e cada um é mais barato de testar do que o seguinte.