Hvorfor afviser OpenConnect gatewayen efter en certifikatudskiftning?

Gateways udskifter certifikater, og en klient, der var forbundet i går, begynder at stoppe ved den første TLS-udveksling. Meddelelsen angiver en verifikationsårsag frem for en netværksfejl, og selve maskinen er ikke ændret, hvilket er det nyttige spor. Det, der gik i stykker, er forholdet mellem det certifikat, der nu præsenteres, og de rødder, klienten er villig til at overveje. At reparere det er en tillidsbeslutning, så træf den, før du skriver en mulighed.

Læs fejlen, før du ændrer nogen tillidsindstilling

En fejl af typen manglende underskriver betyder, at kæden ender ved noget, klienten ikke accepterer. Det kan være et fornyet certifikat fra en intern myndighed, en erstatning fra en offentlig, eller en enhed i midten, der præsenterer sit eget certifikat. Alene ordlyden kan ikke skelne de tilfælde, så se på udstederen, før du beslutter dig.

Kør forbindelsen én gang i forgrunden og lad den fejle, fordi den interaktive udskrift bærer servernavnet, udstederskæden og det fingeraftryk, klienten har beregnet. Sammenlign den udsteder med en myndighed, din organisation faktisk driver. Hvis fingeraftrykket ændrede sig, mens udstederen ikke gjorde, skal du behandle det som mistænkeligt, indtil en fornyelse bekræftes ad en kanal, du allerede stoler på. At gætte på dette tidspunkt er, hvordan en person ender med at fastgøre en aflytteres nøgle.

Notér klientversionen i samme note. En god del af de fejl, der ligner tillidsproblemer, kommer fra en ældre klient, der møder en nyere gatewayudveksling.

Vælg mellem at stole på udstederen og at fastgøre én nøgle

Begge muligheder får forbindelsen til at lykkes. De brækker senere på modsatte måder, så valget hører til den fejl, du kan tåle.

Grib fat i CA-filen, når certifikatet kommer fra en myndighed, du kan verificere uafhængigt, fordi fornyelser så bliver ved med at virke uden at røre klientargumenterne. Par den med kontakten, der deaktiverer systemrødder, ellers kan en offentlig myndighed opfylde kontrollen på dine vegne. Fastgør i stedet, når gatewayen ikke har en CA, du kan skaffe, eller når den snævrest mulige undtagelse er målet. Ingen af vejene er sikrere i abstrakt forstand: CA'en skalerer gennem fornyelser, fastgørelsen er lettere at gennemgå.

Uanset hvad du vælger, skal den betroede værdi ankomme ad en kanal, der var betroet, før ændringen skete. En administrator, en konsolsession på gatewayen eller en kopi taget på forhånd kvalificerer alle. At kopiere det fingeraftryk, prompten viser, er bekvemt og er også præcis, hvad en aflytter håber på.

Sæt værdien i den kommando, du faktisk starter

Fastgørelsen rejser i en servercertifikatmulighed, og dens præfiks bestemmer kodningen: hexadecimale offentlige nøgledigester under sha1 eller sha256, og base64-nøglefastgørelsen under pin-sha256. At angive den deaktiverer også systemtillid for den kørsel, så den fastgjorte nøgle bliver 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 afkortet digest og accepterer så lidt som fire tegn efter præfikset, hvilket er en fælde snarere end en bekvemmelighed. En forkortet værdi går igennem lokalt og identificerer stadig ikke den gateway, du havde til hensigt. Kopier hele den streng, klienten udskrev ved det første forsøg, i stedet for at skrive den igen fra en meddelelse. Flyt derefter den færdige mulighed ind i wrapper-scriptet, unit-filen eller profilen, der starter forbindelsen, så tillidsbeslutningen kan gennemgås, og senere ændringer er bevidste.

Skrivebordsstartere og NetworkManager-pluginet gemmer deres egen kopi af forbindelsesargumenterne. Et script, der er redigeret på disken, når ikke en profil, der blev importeret tidligere, så den gemte værdi vinder fortsat.

Håndtér en udskiftning uden at låse dig selv ude

Muligheden kan angives mere end én gang, så en planlagt ændring kan acceptere den udgående og indgående nøgle sammen. Tilføj den nye fastgørelse, før gatewayen skifter, behold begge på listen, mens sessioner migrerer, og fjern den pensionerede, når den gamle nøgle er væk. Det vindue kræver en ejer, da en glemt dobbelt fastgørelse efterlader en nøgle betroet uden nogen til at holde øje med den. En genopbygning, der frembringer et nyt nøglepar, brækker en ren fastgørelse, og gendannelsen er samme fremgangsmåde i den anden retning.

Skriv ændringsdatoen ved siden af fastgørelsen. En fastgørelse uden revisionsdato er et fremtidigt udfald med en forvirrende fejlmeddelelse.

Udeluk klientversionen, før du redigerer tillid

En forældet klient kan fejle, mens den parser et godkendelsessvar, som gatewayen siden har ændret, og overfladens meddelelse taler stadig om forbindelsen snarere end parseren. Sammenlign den installerede version med det, gatewayen dokumenterer, og test en aktuel pakke i en engangsprofil, før du ændrer nogen tillidsindstilling.

openconnect --version

Efter reparationen skal du bekræfte to ting i stedet for én: portalen indlæses gennem tunnelen, og en almindelig intern adresse svarer. Et gennemført håndtryk beviser kun, at tillidsbeslutningen blev accepteret.