Samopodepsaný klientský certifikát? VPN server ho stále odmítá

Operátor pošle adresu a uživatelské jméno a klient si vyžádá soubor CA, certifikát a klíč. Vygenerovat tyto tři lokálně vypadá jako zřejmý další krok. Vznikne certifikát, kterému věří jen váš vlastní stroj. Důvěra serveru je ukotvena v CA, kterou nekontrolujete, takže handshake skončí dřív, než začne.

Důvěra žije na serveru, ne ve vašem profilu

Ověřování certifikátem je srovnání. Klient předloží certifikát; brána zkontroluje, zda jej podepsala některá z CA v její konfiguraci.

Váš profil uvádí soubor CA, který má klient použít k ověření serveru. Nemůže uvést CA, kterou má server použít k ověření vás. Tato polovina konfigurace není vaše.

Vlastnoručně vyrobený certifikát toto srovnání neprojde, i když je technicky bezchybný. Má platný podpis, subjekt i data, ale vydavatelem je CA, o níž brána nikdy neslyšela. Chyba se objeví během handshake, poté co server už o certifikát požádal. Nic v klientském profilu nemůže odpověď změnit.

Proč samopodepsaný certifikát nemůže nahradit

Samopodepsaný certifikát je podepsán vlastním klíčem. Podpis se ověřuje proti stejnému souboru, což jej činí vnitřně konzistentním a nepoužitelným jako pověření pro cizí bránu.

Brána se neptá, zda je certifikát vnitřně konzistentní. Ptá se, zda jej podepsal důvěryhodný vydavatel.

Proto jsou chybové zprávy matoucí. Klient může hlásit selhání ověření, které zní jako problém serveru, zatímco server zaznamenává neznámého vydavatele. Oba popisují stejný nesoulad z opačných stran.

Cesta přes CSR zachová váš soukromý klíč

Většinu práce stále můžete udělat lokálně. Vygenerujte pár klíčů, sestavte žádost o podepsání certifikátu kolem veřejné poloviny a pošlete tuto žádost operátorovi. Z vašeho stroje odchází jen žádost. Soukromá polovina zůstává tam, kde jste ji vytvořili.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

Operátor žádost podepíše svou CA a vrátí certifikát. Váš soukromý klíč nikdy necestoval a výsledek tvoří řetěz ke kotvě, které brána důvěřuje.

Spravované služby často CSR přeskakují a vydají celý balík. To je rozumná výměna, když stejný poskytovatel už ukončuje tunel a drží CA. Úschova klíče se nezlepší tím, že si jej ponecháte, protože poskytovatel může kdykoli vyrazit nový.

Balíky se importují, neinstalují

Dodavatelské balíky s bezpečně znějícími názvy jsou často profily OpenVPN. Obsahují konfiguraci a někdy certifikáty a nic neinstalují. Importujte soubor do klienta, který daný protokol umí, a spojení je nakonfigurováno.

Pravidlo zacházení vyplývá z obsahu. Pokud profil obsahuje soukromý klíč, je to pověření a zaslouží stejnou péči jako heslo: žádný e-mail, žádný repozitář, žádná sdílená složka stahování. Když operátor dodá ca.crt, client.crt a client.key zvlášť, uložte je společně s omezujícími právy a nasměrujte na ně profil.

Přidejte kontroly, které operátor mohl vynechat

Profil vytvořený routerem někdy postrádá ověření protistrany. remote-cert-tls server vyžaduje, aby certifikát protistrany nesl účel ověření serveru, takže klientský certifikát nelze přehrát jako server. Ten jeden řádek je malá změna s jasným odůvodněním.

verify-x509-name jde dál, když operátor může uvést očekávaný subjekt nebo SAN. Obě jsou malá doplnění profilu a obě jsou obhajitelná. Prohlédněte si, co jste dostali, než to importujete.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Nastavení ověřování není oprava přerušeného řetězu. Pokud je vydavatel špatný, odpovědí je certifikát od správné CA, ne přepínač, který ověřování vypne. Vypnutí ověřování mění selhání autentizace na neodhalené.

Požádejte o jeden balík: certifikát autority ve formátu PEM, klientský certifikát podepsaný touto autoritou, klíč, který jste vygenerovali nebo který dorazil kanálem, jemuž důvěřujete, a přesný název serveru, který má certifikát představit. Poznamenejte datum vypršení ve stejné zprávě, protože propadlý certifikát vypadá o měsíce později jako síťová závada.