Avviso di server non attendibile di AnyConnect: accettare o importare?
L'avviso di server non attendibile di AnyConnect ha tre forme e due risposte. Importare il certificato del gateway è un cambiamento duraturo della fiducia, non una correzione di sessione.
Incollate il nome host del gateway in AnyConnect, la finestra diventa rossa o bianca e una finestra di dialogo chiede se fidarsi di un server il cui certificato il client non può verificare. Il gesto naturale è fare clic e mettersi al lavoro, ed è esattamente il riflesso sbagliato. La risposta viene scritta nelle preferenze del client su quella macchina e vale per le connessioni successive, quindi la finestra è una decisione di configurazione travestita da avviso una tantum. Ecco il percorso che seguo, nell'ordine in cui il client lo mostra.
Partite dall'avviso che vedete davvero
Rosso e bianco non sono varianti estetiche. L'avviso rosso significa che il profilo o la preferenza è impostato per bloccare i server non attendibili, quindi il client rifiuta di proseguire finché quell'impostazione non cambia; l'avviso bianco significa che vi lascerà proseguire non appena risponderete in modo esplicito. C'è un terzo caso che sembra uguale e si comporta diversamente: un certificato scaduto, che il client non proporrà affatto di importare, perché importarlo non lo renderebbe valido. Distinguere i tre richiede un secondo e decide tutto ciò che segue.
Dietro tutti c'è un breve elenco di cause: un certificato del gateway autofirmato, una CA privata di cui l'endpoint non si fida, o un nome host assente dai subject alternative names del certificato. Ognuna delle tre produce la stessa finestra e richiede una correzione diversa.
Leggete il certificato prima di rispondere alla finestra
Aprite i dettagli del certificato dall'avviso e guardate tre campi prima di toccare un pulsante. Il subject e il SAN devono indicare il gateway che volevate davvero raggiungere, l'emittente deve essere la CA gestita dalla vostra organizzazione e le date di validità devono coprire oggi. Poi confrontate l'impronta SHA-256 con una copia ottenuta altrove e non attraverso questa connessione, una pagina di documentazione interna o un ticket, perché un'impronta letta dalla stessa finestra non dimostra assolutamente nulla. Se non trovate una copia indipendente, non avete alcun fondamento per accettare l'eccezione.
Questo è il passo che separa un laboratorio da un gateway di produzione. Su una macchina di prova con un certificato autofirmato generato ieri, fare clic è ragionevole. Su un gateway aziendale dove gli utenti digitano poi le credenziali, un certificato che non potete verificare è un plausibile dispositivo di intercettazione, e il client è l'unico componente che pone ancora la domanda.
Sappiate cosa scrive ogni risposta nell'archivio di fiducia
Rispondere sì alla domanda di importazione aggiunge il certificato del gateway all'archivio attendibile del client su quella macchina. Non è un'eccezione per sessione: le connessioni successive possono completarsi senza la stessa richiesta, che è lo scopo e anche il rischio, perché nulla sullo schermo ricorda a qualcuno che l'eccezione esiste. Rispondere no prosegue l'accesso solo per questa sessione. Entrambi i percorsi vi connettono, e solo uno dei due cambia la macchina.
Se siete sul percorso rosso, il primo tentativo non è affatto un accesso. La sequenza di input documentata è una riga connect seguita da due conferme, che cambia la preferenza ed esce; uno script che lo considera un successo ha salvato un'impostazione e non si è mai autenticato. La domanda sull'importazione del certificato appare solo al tentativo successivo, ed è per questo che le persone concludono che la richiesta è intermittente.
Quest'ordine conta per l'automazione, non solo per le dita. Una risposta scriptata che dice sempre sì continua a funzionare dopo un cambio di gateway, e continua a fidarsi di qualunque certificato compaia dopo.
Scrivete le risposte nell'ordine in cui il client le chiede
Quando il client avvisa ma consente la connessione, le risposte arrivano in un ordine fisso: connect, sì per continuare, poi la domanda di importazione, poi il gruppo, il nome utente e la password. Scrivetele come righe separate nel file di input invece di indovinare la temporizzazione delle richieste. Rifiutare l'importazione è un cambiamento di un solo carattere nello stesso file, ed è l'impostazione predefinita più sicura per tutto ciò che gira senza supervisione.
connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORDPreferite distribuire la CA dell'organizzazione agli endpoint invece di insegnare a ogni script ad accettare un certificato foglia. Un certificato emesso correttamente con il SAN giusto elimina la richiesta per tutti, mantiene utile la validazione e non dipende dalla memoria di un solo endpoint su una decisione. Installare una CA radice è un cambiamento più pesante dell'importare una foglia, quindi trattatelo come un rilascio gestito e non come una scorciatoia del servizio di assistenza.
Rimuovete le eccezioni che sopravvivono al loro gateway
AnyConnect salva queste preferenze per macchina, quindi le vecchie risposte si accumulano su portatili che hanno cambiato ufficio. Rivedete le preferenze salvate e i certificati importati sugli endpoint gestiti, e controllate se un'eccezione nomina ancora un host che ha cambiato proprietario. Una preferenza che accetta qualunque server non attendibile è più ampia del certificato per cui è stata creata.
Il modello da conservare è stretto: un certificato attendibile per l'uso normale, una verifica dell'impronta fuori banda documentata per un'eccezione temporanea e un proprietario nominato che la rimuove quando la migrazione finisce. Se trovate su una macchina che gestite un'impostazione che accetta qualunque server, trattatela come una constatazione e non come una comodità.