Início de sessão VPN com certificado no Mac: identidade, uso da chave ou confiança no gateway?

Os inícios de sessão VPN baseados em certificado pedem ao Mac algo mais estreito do que uma palavra-passe: usar esta chave privada específica, neste contexto de execução, para provar uma identidade a esse gateway. Quando falha, a mensagem costuma descrever apenas a última coisa que correu mal, e essa raramente é a causa. Percorrer as três decisões pela ordem em que o sistema as toma mantém o diagnóstico honesto e impede que um problema de permissões local seja tratado como uma falha de validação da cadeia.

Percorra o início de sessão pela ordem que o Mac segue

Primeiro o cliente escolhe uma identidade: um certificado emparelhado com uma chave privada utilizável, disponível através do armazenamento ou do fornecedor de credenciais suportado. Depois o componente VPN pede que se realize uma operação criptográfica com essa chave, e o modelo de autorização local responde. Só depois de ambos terem êxito ocorre o aperto de mão remoto, onde o Mac avalia o gateway e o gateway avalia a prova do cliente.

Leia a tabela de cima para baixo e pare na primeira linha que falhar. Tudo o que está abaixo de uma falha não está provado, e é por isso que «o certificado não é fidedigno» é uma conclusão tão comum e tão pouco fiável.

O que a permissão local abrange realmente

No modelo de porta-chaves do macOS, os itens protegidos transportam regras de acesso específicas da operação e uma lista de aplicações fidedignas. Assinar com uma chave privada é uma dessas operações, e as regras aplicam-se ao executável que a realiza, não ao certificado enquanto documento. A referência de controlo de acesso da Apple também traça uma linha entre este modelo e o porta-chaves iCloud e os esquemas de grupos de acesso, pelo que um conselho escrito para um não se transfere para o outro.

Seguem-se duas consequências. Um certificado público visível numa lista não prova que o componente em segundo plano da VPN consiga sequer chegar a essa chave. E uma permissão concedida a uma aplicação frontal não diz nada sobre um auxiliar ou uma extensão de rede separados, porque são código diferente com identidades diferentes.

Identifique a implementação real e o mecanismo suportado de partilha de credenciais em vez de copiar um caminho de executável de um cliente antigo. Confirme primeiro que identidade o sistema irá oferecer:

security find-identity -v -p ssl-client

Ler errSecInteractionNotAllowed

Esse estado comunica uma interação não permitida com o Security Server e não diz nada sobre cadeias de certificados. Leia-o em conjunto com a operação que o produziu: um pedido de assinatura emitido a partir de um contexto que não consegue mostrar um diálogo falha desta forma mesmo quando a chave e o certificado são ambos perfeitamente válidos. O ponto de partida é a operação que o registou, não o armazenamento de certificados. Tudo o que alterar nas âncoras de confiança deixará o erro exatamente onde estava.

Trate, portanto, o código como motivo para examinar o contexto de execução e a autorização. Tratá-lo como prova de que a AC do gateway não é fidedigna envia-o para a metade errada do problema, e a alteração que fizer aí não afetará o erro de todo.

Repare de forma estreita, não ampla

Comece pelas instruções de inscrição ou importação do proprietário da ligação. Registe a versão do cliente, o âmbito do perfil, a identidade escolhida e o primeiro erro local relevante, porque são esses quatro factos que uma transferência para o suporte precisa e dos quais depende uma comparação posterior. Um perfil gerido ou uma identidade suportada por hardware pode exigir que o administrador ou o fornecedor repare a transferência, e nenhuma quantidade de cliques locais substitui isso.

Onde o produto espera uma aprovação do utilizador, confirme que componente a pede e aprove apenas esse acesso através do fluxo suportado. Onde o componente não tem forma de levantar um pedido no contexto em que corre, o aprovisionamento tem de seguir o caminho documentado pelo fornecedor, e não um diálogo arrancado a outra janela de terminal.

Duas alterações são agrupadas em conselhos mais antigos, e ambas são demasiado amplas. Conceder a todas as aplicações acesso à chave privada alarga o uso local da chave muito para além do requisito, e definir o certificado como Always Trust altera a avaliação de certificados para tudo na máquina. Nenhuma delas exprime «esta implementação VPN aprovada, a usar esta identidade pretendida».

Verifique localmente antes de ler o gateway

Após uma reparação, confirme que a operação local tem êxito antes de interpretar qualquer resposta do outro lado. Se a assinatura agora funcionar, uma rejeição posterior de nome, cadeia ou admissão de cliente é um resultado novo e não uma recorrência, e pertence a outra decisão com outro responsável.

Uma transferência útil indica qual das três decisões falhou e pára aí. Nunca inclui a chave privada, e nunca repõe itens do porta-chaves alheios na esperança de que uma folha limpa ajude. Estabeleça esses dois hábitos antes do incidente e não durante, quando a tentação de tentar tudo ao mesmo tempo é mais forte. Um ticket que diz «porta-chaves reconstruído» quase nada diz ao leitor seguinte sobre a avaria original.