De ce respinge OpenConnect gateway-ul după o schimbare de certificat?

Gateway-urile înlocuiesc certificate, iar un client care ieri se conecta începe să se oprească la primul schimb TLS. Mesajul numește un motiv de verificare și nu o defecțiune de rețea, iar mașina în sine nu s-a schimbat, ceea ce este indiciul util. Ce s-a rupt este relația dintre certificatul prezentat acum și rădăcinile pe care clientul este dispus să le ia în considerare. Repararea acestui lucru este o decizie de încredere, așa că luați-o înainte de a tasta o opțiune.

Citiți eroarea înainte de a schimba orice setare de încredere

O eroare de tip semnatar lipsă înseamnă că lanțul se termină la ceva ce clientul nu acceptă. Poate fi un certificat reînnoit de la o autoritate internă, o înlocuire de la una publică, sau un dispozitiv la mijloc care își prezintă propriul certificat. Doar formularea nu poate distinge aceste cazuri, așa că priviți emitentul înainte de a decide.

Rulați conexiunea o dată în prim-plan și lăsați-o să eșueze, pentru că ieșirea interactivă poartă numele serverului, lanțul emitentului și amprenta calculată de client. Comparați acel emitent cu o autoritate pe care organizația dumneavoastră o operează cu adevărat. Dacă amprenta s-a schimbat, iar emitentul nu, tratați-o ca suspectă până când o reînnoire este confirmată printr-un canal în care aveți deja încredere. Să ghiciți în acest moment este felul în care cineva ajunge să fixeze cheia unui interceptator.

Notați versiunea clientului în aceeași notă. O bună parte din eșecurile care arată ca probleme de încredere vin de la un client mai vechi care întâlnește un schimb de gateway mai nou.

Alegeți între a avea încredere în emitent și a fixa o singură cheie

Ambele opțiuni fac conexiunea să reușească. Se strică mai târziu în moduri opuse, așa că alegerea aparține eșecului pe care îl puteți tolera.

Apelați la fișierul CA atunci când certificatul vine de la o autoritate pe care o puteți verifica independent, pentru că reînnoirile continuă să funcționeze fără a atinge argumentele clientului. Împerecheați-l cu comutatorul care dezactivează rădăcinile sistemului, altfel o autoritate publică poate îndeplini verificarea în numele dumneavoastră. Fixați în schimb când gateway-ul nu are un CA pe care îl puteți obține sau când excepția cea mai îngustă posibilă este scopul. Niciuna dintre căi nu este mai sigură în abstract: CA se scalează peste reînnoiri, fixarea este mai ușor de revizuit.

Orice ați alege, valoarea de încredere trebuie să sosească printr-un canal care era de încredere înainte de schimbare. Un administrator, o sesiune de consolă pe gateway sau o copie luată dinainte se califică toate. Copierea oricărei amprente afișate de prompt este comodă și este exact ceea ce speră un interceptator.

Puneți valoarea în comanda pe care o lansați cu adevărat

Fixarea călătorește într-o opțiune de certificat de server, iar prefixul decide codificarea: rezumate hexazecimale de cheie publică sub sha1 sau sha256, și fixarea cheii base64 sub pin-sha256. Furnizarea ei dezactivează și încrederea sistemului pentru acea execuție, așa că cheia fixată devine întreaga decizie.

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

Clientul potrivește un rezumat trunchiat, acceptând doar patru caractere după prefix, ceea ce este o capcană, nu o comoditate. O valoare scurtată trece local și tot nu identifică gateway-ul pe care îl intenționați. Copiați șirul complet tipărit de client la prima încercare, în loc să îl rescrieți dintr-un mesaj. Apoi mutați opțiunea finalizată în scriptul wrapper, fișierul unit sau profilul care lansează conexiunea, astfel încât decizia de încredere să poată fi revizuită, iar modificările ulterioare să fie deliberate.

Lansatoarele de desktop și pluginul NetworkManager păstrează propria copie a argumentelor de conexiune. Un script editat pe disc nu ajunge la un profil importat mai devreme, așa că valoarea stocată continuă să câștige.

Gestionați o rotație fără a vă încuia afară

Opțiunea poate fi dată de mai multe ori, așa că o schimbare planificată poate accepta cheia de ieșire și cea de intrare împreună. Adăugați noua fixare înainte ca gateway-ul să comute, păstrați ambele listate cât timp sesiunile migrează și eliminați-o pe cea retrasă după ce cheia veche dispare. Acea fereastră are nevoie de un proprietar, deoarece o fixare dublă uitată lasă o cheie de încredere fără nimeni care să o supravegheze. O reconstrucție care produce o pereche de chei nouă rupe o fixare pură, iar recuperarea este aceeași procedură în direcția opusă.

Scrieți data schimbării lângă fixare. O fixare fără dată de revizuire este o întrerupere viitoare cu un mesaj de eroare confuz.

Excludeți versiunea clientului înainte de a edita încrederea

Un client învechit poate eșua în timp ce analizează un răspuns de autentificare pe care gateway-ul l-a modificat între timp, iar mesajul de suprafață vorbește în continuare despre conexiune, nu despre parser. Comparați versiunea instalată cu ceea ce documentează gateway-ul și testați un pachet actual într-un profil de unică folosință înainte de a schimba orice setare de încredere.

openconnect --version

După reparație, verificați două lucruri în loc de unul: portalul se încarcă prin tunel și o adresă internă obișnuită răspunde. O strângere de mână finalizată dovedește doar că decizia de încredere a fost acceptată.