Por que o OpenConnect rejeita o gateway após uma troca de certificado?

Gateways substituem certificados, e um cliente que se conectava ontem começa a parar no primeiro intercâmbio TLS. A mensagem indica um motivo de verificação e não uma falha de rede, e a própria máquina não mudou, que é a pista útil. O que quebrou é a relação entre o certificado agora apresentado e as raízes que o cliente aceita considerar. Reparar isso é uma decisão de confiança, então tome essa decisão antes de digitar uma opção.

Leia a falha antes de alterar qualquer configuração de confiança

Um erro do tipo signatário ausente significa que a cadeia termina em algo que o cliente não aceita. Pode ser um certificado renovado de uma autoridade interna, uma substituição de uma pública, ou um dispositivo no meio apresentando o próprio certificado. Só a redação não consegue distinguir esses casos, então olhe o emissor antes de decidir.

Execute a conexão uma vez em primeiro plano e deixe-a falhar, porque a saída interativa traz o nome do servidor, a cadeia de emissores e a impressão digital que o cliente calculou. Compare esse emissor com uma autoridade que sua organização realmente opera. Se a impressão digital mudou e o emissor não, trate como suspeito até que uma renovação seja confirmada por um canal em que você já confia. Adivinhar neste ponto é como alguém acaba fixando a chave de um interceptador.

Anote a versão do cliente na mesma nota. Boa parte das falhas que parecem problemas de confiança vem de um cliente mais antigo encontrando um intercâmbio de gateway mais novo.

Escolha entre confiar no emissor e fixar uma chave

As duas opções fazem a conexão funcionar. Elas quebram depois de maneiras opostas, então a escolha pertence à falha que você consegue tolerar.

Recorra ao arquivo de CA quando o certificado vier de uma autoridade que você pode verificar de forma independente, porque as renovações continuam funcionando sem tocar nos argumentos do cliente. Pareie-o com o interruptor que desativa as raízes do sistema, senão uma autoridade pública pode satisfazer a checagem em seu nome. Em vez disso, fixe quando o gateway não tiver uma CA que você possa obter ou quando a exceção mais estreita possível for o objetivo. Nenhum caminho é mais seguro no abstrato: a CA escala ao longo das renovações, a fixação é mais fácil de revisar.

Qualquer que seja sua escolha, o valor confiável precisa chegar por um canal que era confiável antes da mudança acontecer. Um administrador, uma sessão de console no gateway ou uma cópia tirada com antecedência todos qualificam. Copiar qualquer impressão digital que o prompt mostre é conveniente e é exatamente o que um interceptador espera.

Coloque o valor no comando que você realmente executa

A fixação viaja em uma opção de certificado de servidor, e seu prefixo decide a codificação: resumos hexadecimais de chave pública sob sha1 ou sha256, e a fixação de chave em base64 sob pin-sha256. Fornecê-la também desativa a confiança do sistema para essa execução, então a chave fixada se torna a decisão inteira.

sudo openconnect --protocol=gp vpn.example.com --user alice \
  --servercert pin-sha256:AbCdEf...   # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust

O cliente combina um resumo truncado, aceitando apenas quatro caracteres após o prefixo, o que é uma armadilha e não uma conveniência. Um valor encurtado passa localmente e ainda não identifica o gateway que você pretendia. Copie a string completa que o cliente imprimiu na primeira tentativa em vez de digitá-la de novo a partir de uma mensagem. Depois mova a opção finalizada para o script wrapper, o arquivo de unidade ou o perfil que inicia a conexão, para que a decisão de confiança seja revisável e as edições posteriores sejam deliberadas.

Lançadores de desktop e o plugin do NetworkManager guardam a própria cópia dos argumentos de conexão. Um script editado no disco não alcança um perfil importado antes, então o valor armazenado continua vencendo.

Lide com uma rotação sem se trancar do lado de fora

A opção pode ser dada mais de uma vez, então uma mudança planejada pode aceitar a chave de saída e a de entrada juntas. Adicione a nova fixação antes de o gateway trocar, mantenha as duas listadas enquanto as sessões migram, e remova a aposentada quando a chave antiga sumir. Essa janela precisa de um responsável, já que uma fixação dupla esquecida deixa uma chave confiável sem ninguém vigiando. Uma reconstrução que produz um novo par de chaves quebra uma fixação pura, e a recuperação é o mesmo procedimento na direção oposta.

Escreva a data da mudança ao lado da fixação. Uma fixação sem data de revisão é uma indisponibilidade futura carregando uma mensagem de erro confusa.

Descarte a versão do cliente antes de editar a confiança

Um cliente antigo pode falhar ao analisar uma resposta de autenticação que o gateway alterou desde então, e a mensagem superficial ainda fala da conexão e não do analisador. Compare a versão instalada com o que o gateway documenta, e teste um pacote atual em um perfil descartável antes de mudar qualquer configuração de confiança.

openconnect --version

Depois do reparo, verifique duas coisas em vez de uma: o portal carrega através do túnel, e um endereço interno comum responde. Um handshake concluído prova apenas que a decisão de confiança foi aceita.