Gatewayer bytter sertifikater, og en klient som var tilkoblet i går begynner å stoppe ved den første TLS-utvekslingen. Meldingen oppgir en verifiseringsårsak i stedet for en nettverksfeil, og selve maskinen er ikke endret, som er det nyttige sporet. Det som gikk i stykker, er forholdet mellom sertifikatet som nå presenteres og røttene klienten er villig til å vurdere. Å reparere det er en tillitsbeslutning, så ta den beslutningen før du skriver inn et alternativ.

Les feilen før du endrer noen tillitsinnstilling

En feil av typen manglende signatar betyr at kjeden ender på noe klienten ikke godtar. Det kan være et fornyet sertifikat fra en intern myndighet, en erstatning fra en offentlig, eller en enhet i midten som presenterer sitt eget sertifikat. Bare ordlyden kan ikke skille disse tilfellene, så se på utstederen før du bestemmer deg.

Kjør tilkoblingen én gang i forgrunnen og la den feile, fordi den interaktive utskriften bærer servernavnet, utstederkjeden og fingeravtrykket klienten beregnet. Sammenlign den utstederen med en myndighet organisasjonen din faktisk drifter. Hvis fingeravtrykket endret seg mens utstederen ikke gjorde det, behandl det som mistenkelig til en fornyelse er bekreftet gjennom en kanal du allerede stoler på. Å gjette på dette punktet er hvordan en person ender med å feste nøkkelen til en avlytter.

Noter klientversjonen i samme notat. En god del av feilene som ser ut som tillitsproblemer, kommer fra en eldre klient som møter en nyere gatewayutveksling.

Velg mellom å stole på utstederen og å feste én nøkkel

Begge alternativene får tilkoblingen til å lykkes. De bryter sammen senere på motsatte måter, så valget hører til feilen du kan tåle.

ApproachGood fitWhat breaks it
Trust the issuing CA with --cafileInternal PKI you can obtain over an already trusted channelCA rotation, or a client that still falls back to public roots
Pin one key with --servercertNo CA relationship, or exactly one key should ever be acceptedAny reissue that generates a new key pair

Grip til CA-filen når sertifikatet kommer fra en myndighet du kan verifisere uavhengig, fordi fornyelser da fortsetter å virke uten å røre klientargumentene. Par den med bryteren som deaktiverer systemrøtter, ellers kan en offentlig myndighet oppfylle kontrollen på dine vegne. Fest i stedet når gatewayen ikke har en CA du kan skaffe, eller når den smaleste mulige unntaket er målet. Ingen av veiene er sikrere i abstrakt forstand: CA-en skalerer gjennom fornyelser, festingen er lettere å gjennomgå.

Uansett hva du velger, må den betrodde verdien komme gjennom en kanal som var betrodd før endringen skjedde. En administrator, en konsolløkt på gatewayen eller en kopi tatt på forhånd kvalifiserer alle. Å kopiere fingeravtrykket ledeteksten viser, er praktisk og er også nøyaktig det en avlytter håper på.

Sett verdien i kommandoen du faktisk starter

Festeinformasjonen reiser i et server-sertifikatalternativ, og prefikset bestemmer kodingen: heksadesimale offentlige nøkkelsammendrag under sha1 eller sha256, og base64 nøkkelfesting under pin-sha256. Å oppgi den deaktiverer også systemtillit for den kjøringen, så den festede nøkkelen blir hele beslutningen.

sudo openconnect --protocol=gp vpn.example.com --user alice \
  --servercert pin-sha256:AbCdEf...   # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust

Klienten matcher et avkortet sammendrag og godtar så lite som fire tegn etter prefikset, noe som er en felle snarere enn en bekvemmelighet. En forkortet verdi passerer lokalt og identifiserer fortsatt ikke gatewayen du hadde til hensikt. Kopier hele strengen klienten skrev ut ved første forsøk, i stedet for å skrive den inn på nytt fra en melding. Flytt deretter det ferdige alternativet inn i innpakningsskriptet, enhetsfilen eller profilen som starter tilkoblingen, slik at tillitsbeslutningen kan gjennomgås og senere endringer er bevisste.

Skrivebordsstartere og NetworkManager-tillegget lagrer sin egen kopi av tilkoblingsargumentene. Et skript som er redigert på disken, når ikke en profil som ble importert tidligere, så den lagrede verdien vinner fortsatt.

Håndter en utskifting uten å låse deg selv ute

Alternativet kan gis mer enn én gang, så en planlagt endring kan godta både den utgående og den innkommende nøkkelen. Legg til den nye festingen før gatewayen bytter, hold begge oppført mens øktene migrerer, og fjern den pensjonerte når den gamle nøkkelen er borte. Det vinduet trenger en eier, siden en glemt dobbeltfesting lar en nøkkel være betrodd uten at noen ser etter den. En gjenoppbygging som gir et nytt nøkkelpar, bryter en ren festing, og gjenoppretting er samme prosedyre i motsatt retning.

Skriv endringsdatoen ved siden av festingen. En festing uten gjennomgangsdato er et framtidig avbrudd med en forvirrende feilmelding.

Utelukk klientversjonen før du redigerer tillit

En utdatert klient kan feile mens den parser et autentiseringssvar gatewayen siden har endret, og overflatemeldingen snakker fortsatt om tilkoblingen i stedet for parseren. Sammenlign den installerte versjonen med det gatewayen dokumenterer, og test en gjeldende pakke i en engangsprofil før du endrer noen tillitsinnstilling.

openconnect --version

Etter reparasjonen, bekreft to ting i stedet for én: portalen lastes gjennom tunnelen, og en vanlig intern adresse svarer. Et fullført håndtrykk beviser bare at tillitsbeslutningen ble godtatt.

Relaterte artikler