Varför avvisar OpenConnect gatewayen efter ett certifikatbyte?

Gatewayer byter certifikat, och en klient som anslöt i går börjar stanna vid det första TLS-utbytet. Meddelandet anger en verifieringsorsak i stället för ett nätverksfel, och själva maskinen har inte ändrats, vilket är den användbara ledtråden. Det som gick sönder är förhållandet mellan certifikatet som nu presenteras och de rötter klienten är villig att överväga. Att reparera det är ett förtroendebeslut, så fatta det beslutet innan du skriver in ett alternativ.

Läs felet innan du ändrar någon förtroendeinställning

Ett fel av typen saknad undertecknare betyder att kedjan slutar på något klienten inte accepterar. Det kan vara ett förnyat certifikat från en intern myndighet, en ersättning från en offentlig, eller en enhet i mitten som presenterar sitt eget certifikat. Bara formuleringen kan inte skilja dessa fall, så titta på utfärdaren innan du bestämmer dig.

Kör anslutningen en gång i förgrunden och låt den misslyckas, eftersom den interaktiva utskriften bär servernamnet, utfärdarkedjan och det fingeravtryck klienten beräknade. Jämför den utfärdaren med en myndighet som din organisation faktiskt driver. Om fingeravtrycket ändrades men utfärdaren inte gjorde det, behandla det som misstänkt tills en förnyelse bekräftas via en kanal du redan litar på. Att gissa här är hur en person till slut fäster en avlyssnares nyckel.

Anteckna klientversionen i samma anteckning. En stor del av de fel som ser ut som förtroendeproblem kommer från en äldre klient som möter ett nyare gateway-utbyte.

Välj mellan att lita på utfärdaren och att fästa en nyckel

Båda alternativen får anslutningen att lyckas. De går sönder senare på motsatta sätt, så valet hör till det fel du kan tolerera.

Ta CA-filen när certifikatet kommer från en myndighet du kan verifiera självständigt, eftersom förnyelser då fortsätter att fungera utan att röra klientargumenten. Para den med strömbrytaren som inaktiverar systemrötter, annars kan en offentlig myndighet uppfylla kontrollen åt dig. Fäst i stället när gatewayen inte har någon CA du kan skaffa, eller när det smalaste möjliga undantaget är målet. Ingen av vägarna är säkrare i abstrakt mening: CA:n skalar genom förnyelser, fästningen är lättare att granska.

Vilken du än väljer måste det betrodda värdet komma via en kanal som var betrodd innan ändringen skedde. En administratör, en konsolsession på gatewayen eller en kopia tagen i förväg kvalificerar alla. Att kopiera det fingeravtryck prompten visar är bekvämt och är precis vad en avlyssnare hoppas på.

Sätt värdet i kommandot du faktiskt startar

Fästet reser i ett servercertifikatalternativ, och dess prefix avgör kodningen: hexadecimala offentliga nyckelssammanfattningar under sha1 eller sha256, och base64-nyckelfästet under pin-sha256. Att ange det inaktiverar också systemförtroendet för den körningen, så den fästa nyckeln blir hela beslutet.

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 matchar en avkortad sammanfattning och accepterar så lite som fyra tecken efter prefixet, vilket är en fälla snarare än en bekvämlighet. Ett förkortat värde passerar lokalt och identifierar fortfarande inte gatewayen du avsåg. Kopiera hela strängen klienten skrev ut vid första försöket i stället för att skriva om den från ett meddelande. Flytta sedan det färdiga alternativet till omslagsskriptet, enhetsfilen eller profilen som startar anslutningen, så att förtroendebeslutet kan granskas och senare ändringar är avsiktliga.

Skrivbordsstartare och NetworkManager-tillägget lagrar sin egen kopia av anslutningsargumenten. Ett skript som redigerats på disken når inte en profil som importerades tidigare, så det lagrade värdet vinner fortfarande.

Hantera en rotation utan att låsa dig ute

Alternativet kan ges mer än en gång, så en planerad ändring kan acceptera både den utgående och den inkommande nyckeln. Lägg till det nya fästet innan gatewayen byter, håll båda listade medan sessionerna migrerar, och ta bort den pensionerade när den gamla nyckeln är borta. Det fönstret behöver en ägare, eftersom ett glömt dubbelfäste lämnar en nyckel betrodd utan att någon ser efter den. En ombyggnad som ger ett nytt nyckelpar bryter ett rent fäste, och återställningen är samma procedur i motsatt riktning.

Skriv ändringsdatumet bredvid fästet. Ett fäste utan granskningsdatum är ett framtida avbrott med ett förvirrande felmeddelande.

Uteslut klientversionen innan du redigerar förtroende

En föråldrad klient kan misslyckas när den tolkar ett autentiseringssvar som gatewayen sedan dess ändrat, och ytmeddelandet talar fortfarande om anslutningen i stället för tolken. Jämför den installerade versionen med vad gatewayen dokumenterar, och testa ett aktuellt paket i en engångsprofil innan du ändrar någon förtroendeinställning.

openconnect --version

Efter reparationen, verifiera två saker i stället för en: portalen laddas genom tunneln, och en vanlig intern adress svarar. Ett slutfört handslag bevisar bara att förtroendebeslutet accepterades.