Waarom weigert OpenConnect de gateway na een certificaatwissel?

Gateways vervangen certificaten, en een client die gisteren nog verbond, begint bij de eerste TLS-uitwisseling te stoppen. Het bericht noemt een verificatieredenen in plaats van een netwerkstoring, en de machine zelf is niet veranderd, wat de nuttige aanwijzing is. Wat gebroken is, is de relatie tussen het certificaat dat nu wordt aangeboden en de wortels die de client bereid is te overwegen. Dat repareren is een vertrouwensbeslissing, dus neem die beslissing voordat je een optie typt.

Lees de fout voordat je een vertrouwensinstelling wijzigt

Een fout van het type ontbrekende ondertekenaar betekent dat de keten eindigt bij iets wat de client niet accepteert. Dat kan een vernieuwd certificaat van een interne autoriteit zijn, een vervanging door een publieke, of een apparaat in het midden dat zijn eigen certificaat presenteert. Alleen de formulering kan die gevallen niet onderscheiden, dus kijk naar de uitgever voordat je beslist.

Voer de verbinding één keer op de voorgrond uit en laat haar mislukken, want de interactieve uitvoer bevat de servernaam, de uitgeversketen en de vingerafdruk die de client berekende. Vergelijk die uitgever met een autoriteit die jouw organisatie werkelijk beheert. Als de vingerafdruk veranderde terwijl de uitgever dat niet deed, behandel het dan als verdacht tot een vernieuwing is bevestigd via een kanaal dat je al vertrouwt. Gokken op dit punt is hoe iemand uiteindelijk de sleutel van een afluisteraar vastpint.

Noteer de clientversie in dezelfde notitie. Een groot deel van de fouten die op vertrouwensproblemen lijken, komt van een oudere client die een nieuwere gateway-uitwisseling tegenkomt.

Kies tussen de uitgever vertrouwen en één sleutel vastpinnen

Beide opties laten de verbinding slagen. Ze breken later op tegengestelde manieren, dus de keuze hoort bij de fout die je kunt verdragen.

Grijp naar het CA-bestand wanneer het certificaat van een autoriteit komt die je onafhankelijk kunt verifiëren, want vernieuwingen blijven dan werken zonder clientargumenten aan te raken. Koppel het aan de schakelaar die systeemwortels uitschakelt, anders kan een publieke autoriteit de controle namens jou vervullen. Pin in plaats daarvan wanneer de gateway geen CA heeft die je kunt verkrijgen of wanneer de smalst mogelijke uitzondering het doel is. Geen van beide wegen is abstract veiliger: de CA schaalt over vernieuwingen, het vastpinnen is eenvoudiger te beoordelen.

Welke je ook kiest, de vertrouwde waarde moet binnenkomen via een kanaal dat vertrouwd was voordat de wijziging plaatsvond. Een beheerder, een consolesessie op de gateway of een vooraf genomen kopie kwalificeren allemaal. De vingerafdruk kopiëren die de prompt toont, is handig en is precies wat een afluisteraar hoopt.

Zet de waarde in de opdracht die je werkelijk start

Het vastpinnen reist in een servercertificaat-optie, en het voorvoegsel bepaalt de codering: hexadecimale openbare-sleutel-digests onder sha1 of sha256, en het base64-sleutelvastpinnen onder pin-sha256. Het opgeven ervan schakelt ook het systeemvertrouwen voor die run uit, dus de vastgepinde sleutel wordt de hele beslissing.

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

De client vergelijkt een afgekorte digest en accepteert al vier tekens na het voorvoegsel, wat een valkuil is en geen gemak. Een verkorte waarde komt lokaal door en identificeert nog steeds niet de gateway die je bedoelde. Kopieer de volledige tekenreeks die de client bij de eerste poging afdrukte, in plaats van haar uit een bericht over te typen. Verplaats daarna de voltooide optie naar het wrapperscript, het unit-bestand of het profiel dat de verbinding start, zodat de vertrouwensbeslissing beoordeelbaar is en latere wijzigingen bewust zijn.

Bureaubladstarters en de NetworkManager-invoegtoepassing bewaren hun eigen kopie van de verbindingsargumenten. Een script dat op schijf is bewerkt, bereikt geen eerder geïmporteerd profiel, dus de opgeslagen waarde blijft winnen.

Behandel een omschakeling zonder jezelf buiten te sluiten

De optie mag meer dan eens worden gegeven, dus een geplande wijziging kan de uitgaande en inkomende sleutel samen accepteren. Voeg het nieuwe vastpinnen toe voordat de gateway omschakelt, houd beide vermeld terwijl sessies migreren, en laat de uitgefaseerde vallen zodra de oude sleutel weg is. Dat venster heeft een eigenaar nodig, want een vergeten dubbele pin laat een sleutel vertrouwd achter zonder dat iemand erop let. Een herbouw die een nieuw sleutelpaar oplevert, breekt een zuivere pin, en herstel is dezelfde procedure in de andere richting.

Schrijf de wijzigingsdatum naast het vastpinnen. Een pin zonder beoordelingsdatum is een toekomstige storing met een verwarrende foutmelding.

Sluit de clientversie uit voordat je vertrouwen bewerkt

Een verouderde client kan falen bij het parseren van een authenticatieantwoord dat de gateway sindsdien heeft gewijzigd, en het oppervlakkige bericht spreekt nog van de verbinding in plaats van de parser. Vergelijk de geïnstalleerde versie met wat de gateway documenteert, en test een actueel pakket in een wegwerpprofiel voordat je een vertrouwensinstelling wijzigt.

openconnect --version

Controleer na de reparatie twee dingen in plaats van één: de portal laadt door de tunnel, en een gewoon intern adres antwoordt. Een voltooide handshake bewijst alleen dat de vertrouwensbeslissing is aanvaard.