Een OpenVPN-profiel bevat drie certificaatblokken: welke is geheim?

U opent een .ovpn-bestand om één regel te wijzigen en vindt drie blokken base64 die allemaal op inloggegevens lijken. Eén is veilig om te publiceren, één is zo gevoelig als een wachtwoord, en één is een openbare sleutel die niets betekent tenzij iets anders met de bijbehorende sleutel is ondertekend. Mensen plakken het hele bestand in een supportthread omdat de blokken uitwisselbaar lijken, en zo belandt een clientsleutel in een openbaar archief. Uitzoeken welk blok wat doet verklaart het grootste deel van de verwarring rond deze profielen, en het vertelt u ook welke storingen u zelf moet oplossen.

Eén bestand, drie blokken, verschillende taken

Een typisch profiel sluit een ca-blok, een cert-blok en een key-blok in tussen de markeringen BEGIN en END, of verwijst naar dezelfde drie als aparte bestanden. Sommige profielen voegen een vierde blok toe voor een tls-auth- of tls-crypt-sleutel, dat een gedeeld geheim is en geen certificaat. De client leest elk blok volgens de richtlijn die het benoemt, dus de labels tellen zwaarder dan de volgorde waarin ze verschijnen.

Behandel het samengestelde profiel als gevoelig totdat u er echt in heeft gekeken. Een openbaar certificaat en een privésleutel kunnen enkele regels van elkaar in hetzelfde bestand staan, en een schermafbeelding met de kop erin kan beide bevatten. Het zichtbare base64 met de hand afdekken is ook onbetrouwbaar, omdat een gedeeltelijk blok nog steeds de certificaatmetadata lekt die uw uitrol benoemen. De drie richtlijnen zonder hun waarden kopiëren is meestal genoeg om een nuttige vraag te stellen.

De richtlijnen rond de blokken bepalen hoe ze worden gebruikt. Wijzig ca en de client vertrouwt een andere autoriteit; wijzig cert zonder key te wijzigen en de handshake mislukt met een mismatch die niets met vertrouwen te maken heeft.

Het CA-blok is openbaar, de CA-sleutel nooit

Een certificaatautoriteit ondertekent certificaten die een openbare sleutel aan een identiteit binden, en haar eigen certificaat is het anker waarmee een client bepaalt of een keten betrouwbaar is. Dat certificaat is openbaar van ontwerp: het in elk profiel meesturen is normaal, en daarom kan een zelfondertekende uitrol zonder commerciële autoriteit werken.

Wat nooit in een clientprofiel mag staan, is de persoonlijke ondertekeningssleutel van de autoriteit. De client heeft die nergens voor nodig, en de aanwezigheid ervan betekent dat wie het profiel heeft nieuwe identiteiten kan maken voor de hele uitrol.

Een autoriteit vertrouwen is ook smaller dan het klinkt. Een client die elk door de CA ondertekend certificaat accepteert, accepteert nog steeds een certificaat dat voor een andere dienst op dezelfde CA is uitgegeven. Opties die de verwachte serverrol of -naam vastzetten, dichten dat gat, en de TLS-optiereferentie noemt de verificatierichtlijnen die dat doen.

Server- en clientcertificaten wijzen in tegengestelde richtingen

Het certificaat van de server is wat de client controleert om te bevestigen dat hij het juiste eindpunt heeft bereikt. Uw clientcertificaat werkt de andere kant op: de server gebruikt het om te bepalen dat dit apparaat of deze gebruiker er een is die hij heeft ingeschreven. Hetzelfde formaat, tegengestelde vertrouwensrichting.

Een adres is geen identiteit. Het juiste IP bereiken bewijst niets over wie antwoordde, daarom blijft controle van hostnaam of certificaatnaam bij het profiel horen. Een accountwachtwoord vervangt ook niet stilzwijgend een vereist clientcertificaat, omdat beide in verschillende fasen worden gecontroleerd en een uitrol beide kan eisen.

De persoonlijke sleutel van de client is het deel dat privé moet blijven. Als hij kan zijn blootgelegd, verandert het verwijderen van het bestand van uw laptop niets op de server, die het bijbehorende certificaat blijft accepteren tot de operator het intrekt. De operator vragen die identiteit te vervangen of in te trekken is de enige oplossing die met u meereist.

Twee vragen die identiek lijken en het niet zijn

Een sleutel die versleuteld is opgeslagen, vraagt om een wachtwoordzin voordat de client hem kan gebruiken. De VPN-dienst kan apart om een accountwachtwoord vragen, en de twee vragen kunnen seconden na elkaar verschijnen met bijna dezelfde formulering. De wachtwoordzin beschermt een bestand op uw schijf; het wachtwoord bewijst een account bij een server. Ze door elkaar halen stuurt mensen naar wachtwoordresets die onmogelijk kunnen helpen.

Lees de vraag voordat u iets reset. Een accountwachtwoordreset doet niets voor een vergeten sleutelwachtwoordzin, een ingetrokken of een verlopen certificaat, en het wachtwoord resetten wanneer de storing certificaatvalidatie is, maakt van een oplossing van twee minuten een supportgeval. Als de klacht geldigheidsdatums noemt, controleer dan eerst de klok van het apparaat en daarna het eigen venster van het genoemde certificaat.

Wanneer het certificaat echt verlopen is, moet de vervanging komen van wie het heeft uitgegeven. Een sleutel die bij iemand anders hoort is geen vernieuwingspad, en een werkend profiel lenen bij een collega ook niet.

Wat een schone handshake bewijst en wat niet

Een voltooide TLS-handshake bereiken betekent dat de ingestelde identiteitsrelatie standhield: het servercertificaat ketende aan uw CA en uw certificaat werd geaccepteerd. Het zegt niets over het logbeleid van de operator, en niets over of uw toepassingen werken zodra de tunnel staat.

Routes en DNS zijn latere fasen van de verbinding, dus een onbereikbare intranethost na een geslaagde aanmelding is een verbindingsprobleem en geen certificaatprobleem. Werk aan die laag in plaats van inloggegevens te wisselen, en houd de herkomst van het profiel, het privémateriaal en de identiteitscontroles bij elkaar wanneer u het aan iemand geeft.