Aviso de servidor não confiável do AnyConnect: aceitar ou importar?

Você cola o nome do host do gateway no AnyConnect, a janela fica vermelha ou branca e uma caixa de diálogo pergunta se você confia num servidor cujo certificado o cliente não consegue verificar. O movimento natural é clicar e começar a trabalhar, e esse é exatamente o reflexo errado. A resposta é gravada nas preferências do cliente naquela máquina e vale para ligações posteriores, portanto a caixa é uma decisão de configuração disfarçada de aviso único. Aqui está o percurso que faço, na ordem em que o cliente o mostra.

Comece pelo aviso que você realmente vê

Vermelho e branco não são variantes estéticas. O aviso vermelho significa que o perfil ou a preferência está configurado para bloquear servidores não confiáveis, então o cliente recusa continuar até essa definição mudar; o aviso branco significa que ele deixará você continuar assim que responder de forma explícita. Há um terceiro caso que parece igual e se comporta de forma diferente: um certificado expirado, que o cliente não oferecerá para importar de modo algum, porque importá-lo não o tornaria válido. Distinguir os três leva um segundo e decide tudo o que vem depois.

Por trás de todos eles está uma lista curta de causas: um certificado de gateway autoassinado, uma CA privada em que o endpoint não confia, ou um nome de host que falta nos subject alternative names do certificado. Qualquer uma das três produz a mesma caixa e exige uma correção diferente.

Leia o certificado antes de responder à caixa

Abra os detalhes do certificado a partir do aviso e olhe três campos antes de tocar num botão. O subject e o SAN devem nomear o gateway que você realmente pretendia alcançar, o emissor deve ser a CA que a sua organização opera, e as datas de validade devem cobrir hoje. Depois compare a impressão SHA-256 com uma cópia obtida noutro lugar que não por esta ligação, uma página de documentação interna ou um ticket, porque uma impressão lida da mesma caixa não prova absolutamente nada. Se não encontrar uma cópia independente, não tem base para aceitar a exceção.

Este é o passo que separa um laboratório de um gateway de produção. Numa máquina de testes com um certificado autoassinado que gerou ontem, clicar é razoável. Num gateway corporativo onde os utilizadores escrevem credenciais a seguir, um certificado que não consegue verificar é um cenário de interceção plausível, e o cliente é o único componente que ainda faz a pergunta.

Saiba o que cada resposta escreve no armazém de confiança

Responder sim à pergunta de importação acrescenta o certificado do gateway ao armazém de confiança do cliente naquela máquina. Não é uma exceção por sessão: as ligações posteriores podem concluir-se sem o mesmo pedido, o que é o objetivo e também o risco, porque nada no ecrã lembra a ninguém que a exceção existe. Responder não continua o início de sessão apenas para esta sessão. Ambos os caminhos o ligam, e só um deles altera a máquina.

Se está no caminho vermelho, a primeira tentativa não é de todo um início de sessão. A sequência de entrada documentada é uma linha connect seguida de duas confirmações, que altera a preferência e sai; um script que trate isso como sucesso guardou uma definição e nunca se autenticou. A pergunta da importação do certificado só aparece na tentativa seguinte, e é por isso que as pessoas concluem que o pedido é intermitente.

Essa ordem importa para a automação, não apenas para os dedos. Uma resposta escrita que diz sempre sim continua a funcionar depois de o gateway mudar, e continua a confiar em qualquer certificado que apareça a seguir.

Escreva as respostas na ordem em que o cliente as pede

Quando o cliente avisa mas permite a ligação, as respostas chegam numa ordem fixa: connect, sim para continuar, depois a pergunta de importação, depois o grupo, o nome de utilizador e a palavra-passe. Escreva-as como linhas separadas no ficheiro de entrada em vez de adivinhar o momento dos pedidos. Recusar a importação é uma alteração de um único caractere no mesmo ficheiro, e é o valor predefinido mais seguro para tudo o que corre sem supervisão.

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

Prefira distribuir a CA da organização pelos endpoints a ensinar cada script a aceitar um certificado folha. Um certificado emitido corretamente com o SAN certo remove o pedido para todos, mantém a validação com sentido e não depende da memória de um único endpoint sobre uma decisão. Instalar uma CA raiz é uma mudança mais pesada do que importar uma folha, por isso trate-o como uma implementação gerida e não como um atalho do serviço de assistência.

Remova as exceções que sobrevivem ao seu gateway

O AnyConnect guarda estas preferências por máquina, por isso as respostas antigas acumulam-se em portáteis que mudaram de escritório. Reveja as preferências guardadas e os certificados importados nos endpoints geridos, e verifique se uma exceção ainda nomeia um host que mudou de proprietário. Uma preferência que aceita qualquer servidor não confiável é mais ampla do que o certificado para o qual foi criada.

O padrão que vale a pena manter é estreito: um certificado de confiança para uso normal, uma verificação de impressão fora de banda documentada para uma exceção temporária e um proprietário nomeado que a remove quando a migração termina. Se encontrar numa máquina que gere uma definição que aceita qualquer servidor, trate-a como uma constatação e não como uma comodidade.