En OpenVPN-profil har tre certifikatblock: vilket är hemligt?

Du öppnar en .ovpn-fil för att ändra en rad och hittar tre block base64 som alla ser ut som inloggningsuppgifter. Ett är säkert att publicera, ett är lika känsligt som ett lösenord, och ett är en offentlig nyckel som inte betyder något om inte något annat signerats med dess par. Folk klistrar in hela filen i en supporttråd eftersom blocken ser utbytbara ut, och så hamnar en klientnyckel i ett offentligt arkiv. Att reda ut vilket block som gör vad förklarar det mesta av förvirringen kring dessa profiler, och det säger dig också vilka fel du själv måste åtgärda.

En fil, tre block, olika uppgifter

En typisk profil bäddar in ett ca-block, ett cert-block och ett key-block mellan BEGIN- och END-markörerna, eller pekar på samma tre som separata filer. Vissa profiler lägger till ett fjärde block för en tls-auth- eller tls-crypt-nyckel, som är en delad hemlighet och inte ett certifikat. Klienten läser varje block enligt det direktiv som namnger det, så etiketterna spelar större roll än ordningen de förekommer i.

Behandla den sammansatta profilen som känslig tills du faktiskt har tittat inuti den. Ett offentligt certifikat och en privat nyckel kan ligga några rader ifrån varandra i samma fil, och en skärmbild som tar med rubriken kan innehålla båda. Att maska den synliga base64 för hand är inte heller tillförlitligt, eftersom ett delvis block fortfarande läcker certifikatets metadata som namnger din driftsättning. Att kopiera de tre direktiven utan deras värden räcker oftast för att ställa en användbar fråga.

Direktiven runt blocken avgör hur de används. Ändra ca och klienten litar på en annan myndighet; ändra cert utan att ändra key och handskakningen misslyckas med en avvikelse som inte har något med förtroende att göra.

CA-blocket är offentligt, CA-nyckeln aldrig

En certifikatmyndighet signerar certifikat som binder en offentlig nyckel till en identitet, och dess eget certifikat är det ankare en klient använder för att avgöra om en kedja är pålitlig. Det certifikatet är offentligt av design: att skicka det inuti varje profil är normalt, och det är därför en självsignerad driftsättning kan fungera utan en kommersiell myndighet.

Det som aldrig får förekomma i en klientprofil är myndighetens privata signeringsnyckel. Klienten behöver den inte för att validera något, och dess närvaro innebär att den som har profilen kan skapa nya identiteter för hela driftsättningen.

Att lita på en myndighet är också smalare än det låter. En klient som accepterar vilket certifikat som helst signerat av CA:n accepterar fortfarande ett certifikat som utfärdats för en annan tjänst på samma CA. Alternativ som fäster den förväntade serverrollen eller -namnet stänger det gapet, och TLS-alternativreferensen listar de verifieringsdirektiv som gör det.

Server- och klientcertifikat pekar i motsatta riktningar

Serverns certifikat är det klienten granskar för att bekräfta att den nådde rätt slutpunkt. Ditt klientcertifikat går åt andra hållet: servern använder det för att avgöra att den här enheten eller användaren är en som den har registrerat. Samma format, motsatt förtroenderiktning.

En adress är inte en identitet. Att nå rätt IP bevisar ingenting om vem som svarade, därför hör kontroll av värdnamn eller certifikatnamn fortfarande hemma i profilen. Ett kontolösenord ersätter inte heller tyst ett krävt klientcertifikat, eftersom båda kontrolleras i olika skeden och en driftsättning kan kräva båda.

Klientens privata nyckel är den del som måste förbli privat. Om den kan ha röjts ändrar radering av filen på din laptop ingenting på servern, som fortsätter att acceptera motsvarande certifikat tills operatören återkallar det. Att be operatören ersätta eller återkalla den identiteten är den enda åtgärd som följer med dig.

Två förfrågningar som ser identiska ut och inte är det

En nyckel som lagras krypterad ber om en lösenfras innan klienten kan använda den. VPN-tjänsten kan separat be om ett kontolösenord, och de två förfrågningarna kan dyka upp sekunder isär med nästan samma ordalydelse. Lösenfrasen skyddar en fil på din disk; lösenordet bevisar ett konto för en server. Att blanda ihop dem skickar folk till återställningar som omöjligt kan hjälpa.

Läs förfrågan innan du återställer något. En återställning av kontolösenordet gör ingenting för en glömd nyckellösenfras, ett återkallat eller ett utgånget certifikat, och att återställa lösenordet när felet är certifikatvalidering gör en tvåminutersfix till ett supportärende. Om klagomålet nämner giltighetsdatum, kontrollera enhetens klocka först och sedan det namngivna certifikatets eget fönster.

När certifikatet verkligen har gått ut måste ersättningen komma från den som utfärdade det. En nyckel som tillhör någon annan är inte en förnyelseväg, och det är inte heller att låna en fungerande profil av en kollega.

Vad en ren handskakning bevisar och vad den inte bevisar

Att nå en slutförd TLS-handskakning betyder att den konfigurerade identitetsrelationen höll: serverns certifikat kedjades till din CA och ditt certifikat accepterades. Det säger ingenting om operatörens loggningspolicy, och ingenting om huruvida dina program fungerar när tunneln är uppe.

Rutter och DNS är senare skeden av anslutningen, så en oåtkomlig intranätvärd efter en lyckad inloggning är ett anslutningsproblem och inte ett certifikatproblem. Arbeta på det lagret i stället för att byta inloggningsuppgifter, och håll profilens ursprung, dess privata material och dess identitetskontroller tillsammans när du ger den till någon.