AnyConnect-waarskuwing oor onvertroude bediener: aanvaar of invoer?

Jy plak die gateway-gasheernaam in AnyConnect, die venster word rooi of wit, en 'n dialoogvak vra of jy 'n bediener moet vertrou wie se sertifikaat die kliënt nie kan verifieer nie. Die natuurlike beweging is om deur te klik en aan die werk te gaan, en dit is juis die verkeerde refleks. Die antwoord word in die kliënt se voorkeure op daardie masjien geskryf en geld vir latere verbindings, so die dialoog is 'n konfigurasiebesluit wat die kostuum van 'n eenmalige waarskuwing dra. Hier is die gang wat ek maak, in die orde waarin die kliënt dit wys.

Begin by die waarskuwing wat jy werklik sien

Rooi en wit is nie kosmetiese variante nie. Die rooi waarskuwing beteken die profiel of voorkeur is gestel om onvertroude bedieners te blokkeer, so die kliënt weier om voort te gaan tot daardie instelling verander; die wit waarskuwing beteken dit sal jou laat voortgaan sodra jy eksplisiet antwoord. 'n Derde geval lyk soortgelyk en gedra hom anders: 'n vervalde sertifikaat, wat die kliënt glad nie sal aanbied om in te voer nie, want om dit in te voer sou dit nie geldig maak nie. Om die drie te sorteer neem 'n sekonde en bepaal alles wat volg.

Agter almal sit een kort lys oorsake: 'n selfondertekende gateway-sertifikaat, 'n private CA wat die eindpunt nie vertrou nie, of 'n gasheernaam wat in die sertifikaat se subject alternative names ontbreek. Enige van die drie lewer dieselfde dialoog en het 'n ander oplossing nodig.

Lees die sertifikaat voordat jy die dialoog antwoord

Maak die sertifikaatbesonderhede van die waarskuwing oop en kyk na drie velde voordat jy aan 'n knoppie raak. Die subject en SAN moet die gateway noem wat jy werklik wou bereik, die uitreiker moet die CA wees wat jou organisasie bestuur, en die geldigheidsdatums moet vandag dek. Vergelyk dan die SHA-256-vingerafdruk met 'n kopie wat jy elders as op hierdie verbinding gekry het, 'n interne dokumentasiebladsy of 'n kaartjie, want 'n vingerafdruk wat uit dieselfde dialoog gelees word, bewys heeltemal niks. As jy nie 'n onafhanklike kopie kan kry nie, het jy geen basis om die uitsondering te aanvaar nie.

Dit is die stap wat 'n laboratorium van 'n produksie-gateway skei. Op 'n toetsmasjien met 'n selfondertekende sertifikaat wat jy gister geskep het, is deurklik redelik. Op 'n korporatiewe gateway waar gebruikers volgende aanmeldingsgegewens intik, is 'n sertifikaat wat jy nie kan verifieer nie 'n waarskynlike onderskep-opstelling, en die kliënt is die enigste komponent wat nog die vraag vra.

Weet wat elke antwoord in die vertrouensberg skryf

Om ja te antwoord op die invoervraag voeg die gateway se sertifikaat by die kliënt se vertroude berg op daardie masjien. Dit is nie 'n uitsondering per sessie nie: latere verbindings kan sonder dieselfde opdrag voltooi, wat die punt en ook die risiko is, want niks op die skerm herinner enigiemand daaraan dat die uitsondering bestaan nie. Om nee te antwoord, laat die aanmelding net vir hierdie sessie voortduur. Albei paaie kry jou gekonnekteer, en net een van hulle verander die masjien.

As jy op die rooi pad is, is die eerste poging glad nie 'n aanmelding nie. Die gedokumenteerde invoervolgorde is 'n connect-lyn gevolg deur twee bevestigings, wat die voorkeur verander en verlaat; 'n script wat dit as sukses beskou, het 'n instelling gestoor en nooit geauthentiseer nie. Die sertifikaat-invoervraag verskyn eers by die volgende poging, en daarom meen mense die opdrag is ongereeld.

Daardie orde maak saak vir outomatisering, nie net vir vingers nie. 'n Geskrepte antwoord wat altyd ja sê, hou aan werk nadat die gateway verander, en hou aan om enige sertifikaat te vertrou wat volgende verskyn.

Skryf die antwoorde in die orde wat die kliënt vra

Wanneer die kliënt waarsku maar die verbinding toelaat, kom die antwoorde in 'n vaste orde: connect, ja om voort te gaan, dan die invoervraag, dan die groep, die gebruikersnaam en die wagwoord. Skryf dit as aparte lyne in die invoerlêer eerder as om die tydsberekening van die opdrag te raai. Om die invoer te weier is 'n enkele karakterverandering in dieselfde lêer, en dit is die veiliger verstek vir enigiets wat onbewaak loop.

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

Verkies om die organisasie se CA na die eindpunte te versprei eerder as om elke script te leer om 'n bladsertifikaat te aanvaar. 'n Behoorlik uitgereikte sertifikaat met die regte SAN verwyder die opdrag vir almal, hou validering betekenisvol, en hang nie af van een eindpunt se geheue van 'n besluit nie. Om 'n root CA te installeer is 'n swaarder verandering as om 'n blad in te voer, so behandel dit as 'n bestuurde uitrol eerder as 'n kortpad by die helpbank.

Verwyder die uitsonderings wat hul gateway oorleef

AnyConnect stoor hierdie voorkeure per masjien, so ou antwoorde hoop op op skootrekenaars wat tussen kantore beweeg het. Hersien die gestoorde voorkeure en die ingevoerde sertifikate op bestuurde eindpunte, en kyk of 'n uitsondering nog 'n gasheernaam noem wat van eienaar verander het. 'n Voorkeur wat enige onvertroude bediener aanvaar, is wyer as die sertifikaat waarvoor dit geskep is.

Die patroon wat die moeite werd is om te hou, is smal: 'n vertroude sertifikaat vir normale gebruik, 'n gedokumenteerde buite-band vingerafdruk-kontrole vir 'n tydelike uitsondering, en 'n genoemde eienaar wat dit verwyder wanneer die migrasie eindig. As jy 'n omvattende instelling vind wat enige bediener aanvaar op 'n masjien wat jy bestuur, behandel dit as 'n bevinding eerder as 'n gerief.