Otevřete soubor .ovpn, abyste změnili jeden řádek, a najdete tři bloky base64, které všechny vypadají jako přihlašovací údaje. Jeden je bezpečné zveřejnit, druhý je citlivý jako heslo a třetí je veřejný klíč, který nic neznamená, dokud jím jeho protějšek něco nepodepíše. Lidé vkládají celý soubor do vlákna podpory, protože bloky vypadají zaměnitelně, a právě tak skončí klientský klíč ve veřejném archivu. Rozlišení, který blok co dělá, vysvětluje většinu zmatení kolem těchto profilů a také vám řekne, které poruchy máte opravit sami.

Jeden soubor, tři bloky, různé úlohy

Typický profil vkládá blok ca, blok cert a blok key mezi značky BEGIN a END, nebo odkazuje na stejné tři jako na samostatné soubory. Některé profily přidávají čtvrtý blok pro klíč tls-auth nebo tls-crypt, což je sdílené tajemství, nikoli certifikát. Klient čte každý blok podle direktivy, která ho pojmenovává, takže označení jsou důležitější než pořadí, v jakém se objevují.

Považujte sestavený profil za citlivý, dokud se do něj skutečně nepodíváte. Veřejný certifikát a soukromý klíč mohou být v témže souboru jen pár řádků od sebe a snímek obrazovky včetně hlavičky může obsahovat obojí. Ruční začernění viditelného base64 je také nespolehlivé, protože i částečný blok prozradí metadata certifikátu, která pojmenovávají vaše nasazení. Zkopírovat tři direktivy bez jejich hodnot obvykle stačí k užitečné otázce.

Direktivy kolem bloků určují, jak se používají. Změňte ca a klient důvěřuje jiné autoritě; změňte cert bez změny key a handshake selže s nesouladem, který s důvěrou nemá nic společného.

Blok CA je veřejný, klíč CA nikdy

Certifikační autorita podepisuje certifikáty, které vážou veřejný klíč k identitě, a její vlastní certifikát je kotva, podle níž se klient rozhoduje, zda je řetěz důvěryhodný. Tento certifikát je veřejný ze záměru: posílat ho uvnitř každého profilu je normální a právě proto může samopodepsané nasazení fungovat bez komerční autority.

To, co se nikdy nesmí objevit v klientském profilu, je soukromý podpisový klíč autority. Klient jej k ničemu nepotřebuje a jeho přítomnost znamená, že kdokoli profil má, může razit nové identity pro celé nasazení.

Důvěřovat autoritě je také užší, než to zní. Klient, který přijme jakýkoli certifikát podepsaný CA, stále přijme certifikát vydaný pro jinou službu na téže CA. Volby, které fixují očekávanou roli nebo jméno serveru, tuto mezeru zavírají, a Přehled voleb TLS vypisuje direktivy ověřování, které to dělají.

Serverový a klientský certifikát míří opačným směrem

Serverový certifikát je to, co klient zkoumá, aby potvrdil, že dorazil na správný koncový bod. Váš klientský certifikát jde opačně: server jej používá, aby rozhodl, že toto zařízení nebo uživatel je ten, koho zapsal. Stejný formát, opačný směr důvěry.

Adresa není identita. Dosažení správné IP nedokazuje nic o tom, kdo odpověděl, a proto kontrola názvu hostitele nebo názvu certifikátu stále patří do profilu. Ani heslo účtu tiše nenahradí vyžadovaný klientský certifikát, protože obojí se ověřuje v jiné fázi a nasazení může vyžadovat obojí.

Soukromý klíč klienta je část, která musí zůstat soukromá. Pokud mohl být odhalen, smazání souboru z vašeho notebooku na serveru nic nezmění, server bude odpovídající certifikát přijímat dál, dokud jej operátor neodvolá. Požádat operátora o výměnu nebo odvolání této identity je jediná oprava, která cestuje s vámi.

Dvě výzvy, které vypadají stejně a stejné nejsou

Klíč uložený v šifrované podobě žádá o přístupovou frázi, než jej klient může použít. Služba VPN může zvlášť žádat heslo účtu a obě výzvy se mohou objevit v rozmezí sekund s téměř stejnou formulací. Přístupová fráze chrání soubor na vašem disku; heslo prokazuje účet serveru. Záměna obojího posílá lidi k resetům hesel, které nemohou nijak pomoci.

Přečtěte si výzvu, než cokoli resetujete. Reset hesla účtu nic neudělá pro zapomenutou přístupovou frázi klíče, odvolaný nebo prošlý certifikát, a reset hesla, když je porucha v ověřování certifikátu, mění dvouminutovou opravu v případ pro podporu. Zmíní-li stížnost data platnosti, zkontrolujte nejprve hodiny zařízení a potom vlastní okno uvedeného certifikátu.

Když certifikát skutečně vypršel, náhrada musí přijít od toho, kdo jej vydal. Klíč, který patří někomu jinému, není cesta k obnově, a vypůjčit si funkční profil od kolegy také ne.

Co čistý handshake dokazuje a co ne

Dosažení dokončeného TLS handshake znamená, že nastavený vztah identit vydržel: certifikát serveru se zřetězil k vaší CA a váš certifikát byl přijat. Nic to neříká o politice protokolování operátora ani o tom, zda vaše aplikace budou po zvednutí tunelu fungovat.

Trasy a DNS jsou pozdější fáze spojení, takže nedostupný hostitel intranetu po úspěšném přihlášení je problém konektivity, ne certifikátu. Pracujte na této vrstvě místo výměny přihlašovacích údajů a při předávání profilu držte pohromadě jeho původ, jeho soukromý materiál a jeho kontroly identity.

Související články