AnyConnect-varsel om en ikke-klarert server: godta eller importere?
AnyConnect-varselet om en ikke-klarert server har tre former og to svar. Import av gateway-sertifikatet er en varig endring av tilliten, ikke en sesjonsretting.
Du limer inn vertsnavnet til gatewayen i AnyConnect, vinduet blir rødt eller hvitt, og en dialog spør om du vil stole på en server som klienten ikke kan verifisere sertifikatet til. Den naturlige bevegelsen er å klikke seg gjennom og komme i gang, og det er nettopp den feil refleksen. Svaret skrives inn i innstillingene til klienten på den maskinen og gjelder for senere tilkoblinger, så dialogen er en konfigurasjonsbeslutning i kostyme av et engangsvarsel. Her er løpet jeg tar, i den rekkefølgen klienten viser det.
Start med varselet du faktisk ser
Rødt og hvitt er ikke kosmetiske varianter. Det røde varselet betyr at profilen eller innstillingen er satt til å blokkere ikke-klarerte servere, så klienten nekter å fortsette til den innstillingen endres; det hvite varselet betyr at den lar deg fortsette så snart du svarer eksplisitt. Det finnes et tredje tilfelle som ser likt ut og oppfører seg annerledes: et utløpt sertifikat, som klienten ikke vil tilby å importere i det hele tatt, fordi import ikke ville gjøre det gyldig. Å skille de tre tar et sekund og avgjør alt som følger.
Bak alle sammen står en kort liste med årsaker: et selvsignert gateway-sertifikat, en privat CA som endepunktet ikke stoler på, eller et vertsnavn som mangler i sertifikatets subject alternative names. Hver av de tre gir samme dialog og krever en annen rettelse.
Les sertifikatet før du svarer på dialogen
Åpne sertifikatdetaljene fra varselet og se på tre felt før du berører en knapp. Subject og SAN skal navngi gatewayen du faktisk ville nå, utstederen skal være CA-en organisasjonen din driver, og gyldighetsdatoene skal dekke i dag. Sammenlign deretter SHA-256-avtrykket med en kopi du har fått et annet sted enn gjennom denne tilkoblingen, en intern dokumentasjonsside eller en sak, fordi et avtrykk lest fra samme dialog beviser ingenting som helst. Finner du ikke en uavhengig kopi, har du ikke grunnlag for å godta unntaket.
Dette er trinnet som skiller et laboratorium fra en produksjonsgateway. På en testmaskin med et selvsignert sertifikat du genererte i går, er gjennomklikking rimelig. På en bedriftsgateway der brukerne deretter skriver inn påloggingsinformasjon, er et sertifikat du ikke kan verifisere et sannsynlig avlyttningsopplegg, og klienten er den eneste komponenten som fortsatt stiller spørsmålet.
Vit hva hvert svar skriver til tillitslageret
Å svare ja på importspørsmålet legger gatewayens sertifikat til klientens klarerte lager på den maskinen. Det er ikke et unntak per sesjon: senere tilkoblinger kan fullføres uten samme ledetekst, noe som er poenget og også risikoen, fordi ingenting på skjermen minner noen på at unntaket finnes. Å svare nei fortsetter påloggingen bare for denne sesjonen. Begge veier kobler deg til, og bare én av dem endrer maskinen.
Er du på den røde veien, er det første forsøket ikke en pålogging i det hele tatt. Den dokumenterte inndatasekvensen er en connect-linje etterfulgt av to bekreftelser, som endrer innstillingen og avslutter; et skript som ser på det som suksess, har lagret en innstilling og aldri autentisert. Spørsmålet om sertifikatimport dukker først opp ved neste forsøk, og derfor konkluderer folk med at ledeteksten er periodisk.
Den rekkefølgen betyr noe for automatisering, ikke bare for fingre. Et skriptet svar som alltid sier ja, fortsetter å virke etter at gatewayen byttes, og fortsetter å stole på hvilket som helst sertifikat som dukker opp.
Skriv svarene i den rekkefølgen klienten spør
Når klienten varer men tillater tilkoblingen, kommer svarene i fast rekkefølge: connect, ja for å fortsette, deretter importspørsmålet, deretter gruppen, brukernavnet og passordet. Skriv dem som separate linjer i inndatafilen i stedet for å gjette på timingen til ledetekstene. Å avslå importen er en enkelt tegnendring i samme fil, og det er den tryggere standarden for alt som kjører uten tilsyn.
connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORDForetrekk å distribuere organisasjonens CA til endepunktene framfor å lære hvert skript å godta et bladsertifikat. Et riktig utstedt sertifikat med riktig SAN fjerner ledeteksten for alle, holder valideringen meningsfull og avhenger ikke av én endepunkts hukommelse om en beslutning. Å installere en rot-CA er en tyngre endring enn å importere et blad, så behandle det som en styrt utrulling og ikke som en snarvei fra brukerstøtten.
Fjern unntakene som lever lenger enn gatewayen sin
AnyConnect lagrer disse innstillingene per maskin, så gamle svar hoper seg opp på bærbare maskiner som har flyttet mellom kontorer. Gå gjennom de lagrede innstillingene og de importerte sertifikatene på styrte endepunkter, og sjekk om et unntak fortsatt nevner et vertsnavn som har skiftet eier. En innstilling som godtar enhver ikke-klarert server er bredere enn sertifikatet den ble opprettet for.
Mønsteret som er verdt å beholde er smalt: et klarert sertifikat for normal bruk, en dokumentert avtrykkskontroll utenfor båndet for et midlertidig unntak, og en navngitt eier som fjerner det når migreringen er over. Finner du en innstilling som godtar enhver server på en maskin du administrerer, behandle det som et funn og ikke som en bekvemmelighet.