AnyConnect-Warnung vor nicht vertrauenswürdigem Server: akzeptieren oder importieren?

Sie fügen den Hostnamen des Gateways in AnyConnect ein, das Fenster wird rot oder weiß, und ein Dialog fragt, ob Sie einem Server vertrauen möchten, dessen Zertifikat der Client nicht prüfen kann. Der natürliche Reflex ist, durchzuklicken und weiterzuarbeiten, und genau das ist falsch. Die Antwort wird in den Einstellungen des Clients auf diesem Rechner gespeichert und gilt für spätere Verbindungen, sodass der Dialog eine Konfigurationsentscheidung im Kostüm einer einmaligen Warnung ist. Hier ist der Ablauf, den ich gehe, in der Reihenfolge, in der der Client ihn zeigt.

Beginnen Sie bei der Warnung, die Sie tatsächlich sehen

Rot und Weiß sind keine kosmetischen Varianten. Die rote Warnung bedeutet, dass Profil oder Einstellung so gesetzt ist, dass nicht vertrauenswürdige Server blockiert werden, weshalb der Client die Fortsetzung verweigert, bis diese Einstellung geändert wird; die weiße Warnung bedeutet, dass er Sie fortfahren lässt, sobald Sie ausdrücklich antworten. Ein dritter Fall sieht ähnlich aus und verhält sich anders: ein abgelaufenes Zertifikat, das der Client gar nicht zum Import anbietet, weil der Import es nicht gültig machen würde. Diese drei zu sortieren dauert eine Sekunde und entscheidet alles Folgende.

Hinter allen steht eine kurze Liste von Ursachen: ein selbstsigniertes Gateway-Zertifikat, eine private CA, der der Endpunkt nicht vertraut, oder ein Hostname, der in den subject alternative names des Zertifikats fehlt. Jede der drei erzeugt denselben Dialog und verlangt eine andere Lösung.

Lesen Sie das Zertifikat, bevor Sie den Dialog beantworten

Öffnen Sie die Zertifikatsdetails aus der Warnung und sehen Sie sich drei Felder an, bevor Sie eine Schaltfläche berühren. Subject und SAN sollten das Gateway benennen, das Sie wirklich erreichen wollten, der Aussteller sollte die CA sein, die Ihre Organisation betreibt, und die Gültigkeitsdaten sollten heute abdecken. Vergleichen Sie dann den SHA-256-Fingerabdruck mit einer Kopie, die Sie woanders als über diese Verbindung bezogen haben, einer internen Dokumentationsseite oder einem Ticket, denn ein aus demselben Dialog abgelesener Fingerabdruck beweist überhaupt nichts. Finden Sie keine unabhängige Kopie, haben Sie keine Grundlage, die Ausnahme zu akzeptieren.

Das ist der Schritt, der ein Labor von einem Produktions-Gateway trennt. Auf einer Testmaschine mit einem gestern erzeugten selbstsignierten Zertifikat ist Durchklicken vernünftig. Auf einem Firmen-Gateway, an dem Nutzer als Nächstes Anmeldedaten eingeben, ist ein Zertifikat, das Sie nicht prüfen können, ein plausibles Abhörszenario, und der Client ist die einzige Komponente, die die Frage noch stellt.

Wissen Sie, was jede Antwort in den Vertrauensspeicher schreibt

Ein Ja auf die Importfrage fügt das Gateway-Zertifikat dem vertrauenswürdigen Speicher des Clients auf diesem Rechner hinzu. Es ist keine Ausnahme pro Sitzung: spätere Verbindungen können ohne dieselbe Abfrage zustande kommen, was der Zweck und zugleich das Risiko ist, weil nichts auf dem Bildschirm jemanden daran erinnert, dass die Ausnahme existiert. Ein Nein setzt die Anmeldung nur für diese Sitzung fort. Beide Wege verbinden Sie, und nur einer davon verändert den Rechner.

Sind Sie auf dem roten Weg, ist der erste Versuch überhaupt keine Anmeldung. Die dokumentierte Eingabefolge ist eine connect-Zeile, gefolgt von zwei Bestätigungen, die die Einstellung ändern und beenden; ein Skript, das das als Erfolg wertet, hat eine Einstellung gespeichert und sich nie authentifiziert. Die Frage nach dem Zertifikatsimport erscheint erst beim nächsten Versuch, weshalb Leute schließen, die Abfrage sei unregelmäßig.

Diese Reihenfolge zählt für die Automatisierung, nicht nur für Finger. Eine geskriptete Antwort, die immer Ja sagt, funktioniert nach einem Gateway-Wechsel weiter und vertraut weiter jedem Zertifikat, das als Nächstes auftaucht.

Skripten Sie die Antworten in der Reihenfolge, in der der Client fragt

Warnt der Client, erlaubt aber die Verbindung, kommen die Antworten in fester Reihenfolge: connect, Ja zum Fortfahren, dann die Importfrage, dann die Gruppe, der Benutzername und das Passwort. Schreiben Sie diese als separate Zeilen in die Eingabedatei, statt das Timing der Abfragen zu raten. Den Import abzulehnen ist eine Änderung um ein Zeichen in derselben Datei und die sicherere Voreinstellung für alles, was unbeaufsichtigt läuft.

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

Verteilen Sie lieber die CA der Organisation an die Endpunkte, als jedem Skript beizubringen, ein Blattzertifikat zu akzeptieren. Ein ordnungsgemäß ausgestelltes Zertifikat mit dem richtigen SAN beseitigt die Abfrage für alle, hält die Validierung bedeutsam und hängt nicht vom Gedächtnis eines einzelnen Endpunkts für eine Entscheidung ab. Eine Root-CA zu installieren ist eine schwerere Änderung als ein Blatt zu importieren, behandeln Sie es daher als verwalteten Rollout und nicht als Abkürzung des Helpdesks.

Entfernen Sie die Ausnahmen, die ihr Gateway überleben

AnyConnect speichert diese Einstellungen pro Rechner, sodass sich alte Antworten auf Laptops ansammeln, die zwischen Büros gewechselt sind. Überprüfen Sie die gespeicherten Einstellungen und die importierten Zertifikate auf verwalteten Endpunkten und prüfen Sie, ob eine Ausnahme noch einen Hostnamen nennt, der den Besitzer gewechselt hat. Eine Einstellung, die jeden nicht vertrauenswürdigen Server akzeptiert, ist weiter als das Zertifikat, für das sie angelegt wurde.

Das Muster, das es zu bewahren gilt, ist eng: ein vertrauenswürdiges Zertifikat für den Normalbetrieb, eine dokumentierte Fingerabdruckprüfung außerhalb des Bandes für eine vorübergehende Ausnahme und ein benannter Eigentümer, der sie entfernt, wenn die Migration endet. Finden Sie auf einem Rechner, den Sie verwalten, eine pauschale Einstellung, die jeden Server akzeptiert, behandeln Sie sie als Befund und nicht als Bequemlichkeit.