AnyConnect-varning om ej betrodd server: acceptera eller importera?

Du klistrar in gatewayens värdnamn i AnyConnect, fönstret blir rött eller vitt och en dialog frågar om du vill lita på en server vars certifikat klienten inte kan verifiera. Den naturliga rörelsen är att klicka sig igenom och börja arbeta, och det är precis den felaktiga reflexen. Svaret skrivs in i klientens inställningar på den maskinen och gäller för senare anslutningar, så dialogen är ett konfigurationsbeslut i kostym av en engångsvarning. Här är vägen jag tar, i den ordning klienten visar den.

Börja med varningen du faktiskt ser

Rött och vitt är inte kosmetiska varianter. Den röda varningen betyder att profilen eller inställningen är satt att blockera ej betrodda servrar, så klienten vägrar fortsätta tills den inställningen ändras; den vita varningen betyder att den låter dig fortsätta så snart du svarar uttryckligen. Det finns ett tredje fall som ser likadant ut och beter sig annorlunda: ett utgånget certifikat, som klienten inte alls erbjuder att importera, eftersom import inte skulle göra det giltigt. Att skilja de tre tar en sekund och avgör allt som följer.

Bakom alla står en kort lista av orsaker: ett självsignerat gatewaycertifikat, en privat CA som slutpunkten inte litar på, eller ett värdnamn som saknas i certifikatets subject alternative names. Var och en av de tre ger samma dialog och kräver en annan åtgärd.

Läs certifikatet innan du svarar i dialogen

Öppna certifikatuppgifterna från varningen och titta på tre fält innan du rör en knapp. Subject och SAN ska namnge den gateway du faktiskt ville nå, utfärdaren ska vara den CA som din organisation driver, och giltighetsdatumen ska täcka i dag. Jämför sedan SHA-256-avtrycket med en kopia du fått någon annanstans än via den här anslutningen, en intern dokumentationssida eller ett ärende, eftersom ett avtryck som läses från samma dialog inte bevisar någonting alls. Hittar du ingen oberoende kopia har du ingen grund att acceptera undantaget.

Det här är steget som skiljer ett labb från en produktionsgateway. På en testmaskin med ett självsignerat certifikat du skapade i går är genomklickning rimlig. På en företagsgateway där användarna sedan skriver in inloggningsuppgifter är ett certifikat du inte kan verifiera ett troligt avlyssningsarrangemang, och klienten är den enda komponenten som fortfarande ställer frågan.

Vet vad varje svar skriver till förtroendelagret

Att svara ja på importfrågan lägger gatewayens certifikat till klientens betrodda lager på den maskinen. Det är inte ett undantag per session: senare anslutningar kan slutföras utan samma fråga, vilket är poängen och också risken, eftersom ingenting på skärmen påminner någon om att undantaget finns. Att svara nej fortsätter inloggningen bara för den här sessionen. Båda vägarna ansluter dig, och bara en av dem ändrar maskinen.

Är du på den röda vägen är det första försöket inte en inloggning alls. Den dokumenterade inmatningssekvensen är en connect-rad följd av två bekräftelser, som ändrar inställningen och avslutar; ett skript som ser det som framgång har sparat en inställning och aldrig autentiserat. Frågan om certifikatimport dyker först upp vid nästa försök, och därför drar folk slutsatsen att frågan är intermittent.

Den ordningen spelar roll för automatisering, inte bara för fingrar. Ett skriptat svar som alltid säger ja fortsätter att fungera efter att gatewayen byts och fortsätter att lita på vilket certifikat som helst som dyker upp.

Skriv svaren i den ordning klienten frågar

När klienten varnar men tillåter anslutningen kommer svaren i fast ordning: connect, ja för att fortsätta, sedan importfrågan, sedan gruppen, användarnamnet och lösenordet. Skriv dem som separata rader i indatafilen i stället för att gissa frågornas timing. Att avböja importen är en ändring av ett enda tecken i samma fil, och det är den säkrare standarden för allt som körs utan tillsyn.

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

Föredra att distribuera organisationens CA till slutpunkterna framför att lära varje skript att acceptera ett bladcertifikat. Ett korrekt utfärdat certifikat med rätt SAN tar bort frågan för alla, håller valideringen meningsfull och beror inte på en slutpunkts minne av ett beslut. Att installera en rot-CA är en tyngre ändring än att importera ett blad, så behandla det som en hanterad utrullning och inte som en genväg från supporten.

Ta bort undantagen som lever längre än sin gateway

AnyConnect sparar dessa inställningar per maskin, så gamla svar samlas på bärbara datorer som flyttat mellan kontor. Gå igenom de sparade inställningarna och de importerade certifikaten på hanterade slutpunkter och kontrollera om ett undantag fortfarande anger ett värdnamn som bytt ägare. En inställning som accepterar vilken ej betrodd server som helst är bredare än det certifikat den skapades för.

Mönstret som är värt att behålla är smalt: ett betrott certifikat för normal användning, en dokumenterad avtryckskontroll utanför bandet för ett tillfälligt undantag och en namngiven ägare som tar bort det när migreringen är över. Hittar du en inställning som accepterar vilken server som helst på en maskin du hanterar, behandla det som ett fynd och inte som en bekvämlighet.