remote-cert-tls server: co kontroluje v profilu OpenVPN

Tři různé otázky dostávají odpovědi od tří různých částí profilu OpenVPN a právě jejich spojení vede lidi k tomu, že vypnou kontrolu, která fungovala. Je certifikát protějšku podepsán autoritou, které věřím? Deklaruje tento certifikát roli serveru TLS? Je to právě ten server, kterého jsem chtěl dosáhnout? remote-cert-tls server odpovídá jen na prostřední otázku a dělá to čtením rozšíření uvnitř certifikátu.

Tři kontroly, které lze snadno v mysli spojit

Kořen důvěry žije v direktivě ca. Kontrola role patří remote-cert-tls. Kontrola identity patří verify-x509-name, když ji profil používá, nebo jakékoli kontrole názvu, kterou přidá nasazení.

Pokrývají různé poruchy:

Profil může mít všechny tři a přesto být slabý, pokud je CA sdílená příliš široce, což je otázka správy klíčů, nikoli direktivy.

Co kontrola role čte

Direktiva je makro. Rozbaluje se na požadavek na použití klíče a požadavek na rozšířené použití klíče pojmenovávající roli webového serveru TLS, takže certifikát protějšku musí tento účel skutečně deklarovat. Certifikát vydaný pro autentizaci klienta to nesplňuje, i když oba podepsala stejná autorita.

To je důležité, protože sdílená CA je v malých nasazeních běžná. Jedna autorita podepisuje každého klienta i server a bez kontroly role by kterýkoli z těchto certifikátů mohl dokončit serverskou stranu handshake. Kontrola takový scénář neznemožňuje, ale odstraňuje jeho triviální verzi.

Direktiva je záměrně asymetrická: klienti nesou remote-cert-tls server a servery nesou remote-cert-tls client. Vyměňte je a každé připojení selže s chybou role, která vypadá jako poškozený certifikát.

Starší profily někdy používají ns-cert-type pro stejný účel. Aktuální manuálové stránky považují tuto volbu za nahrazenou, takže profil, který na ni stále spoléhá, stojí za migraci, nikoli za ladění.

Proč vypnutí vypadá jako oprava

Když kontrola role selže, připojení se zastaví s chybou ověření a zjevným krokem je smazat řádek. Připojení se pak zvedne, což vypadá jako pokrok a ve skutečnosti je to režim selhání, kterému má direktiva zabránit. Nyní přijímáte protějšek, jehož certifikát pro tuto roli nikdy nebyl určen.

Místo toho si přečtěte chybu. Pojmenovává kontrolu, která selhala, a certifikát na druhé straně lze prohlédnout, abyste viděli, která rozšíření skutečně nese. Dvě minuty čtení rozhodnou, zda je závada ve vydání, nebo v konfiguraci. Hádání stojí odpoledne a obvykle končí oslabeným profilem. Obnovený serverový certifikát, který ztratil rozšířené použití klíče, je skutečná závada v obnově, ne důvod uvolnit klienta.

Kontrola názvu je samostatná direktiva

Splnění kontroly role říká, že protějšek je nějaký server podepsaný vaší autoritou. Neříká nic o tom který, což je důležité, když stejná CA vydává certifikáty pro několik bran a jedna z nich je kompromitována nebo přeúčelena.

verify-x509-name porovnává subjekt certifikátu s hodnotou, kterou nakonfigurujete, s režimy shody pro přesný subjekt, prefix nebo jediné pole. Použijte pole, které bránu skutečně identifikuje, a počítejte s tím, že je při změně názvu vědomě aktualizujete.

Ani jedna direktiva nenahrazuje dobré zacházení s klíči. Pokud se soubor klientského klíče kopíruje spolu s profilem, identita protějšku je jen tak silná jako distribuční seznam.

Prohlédněte certifikát, než upravíte profil

Přečtěte certifikát protějšku a klientský protokol, v tomto pořadí. Certifikát vám řekne, které role deklaruje; protokol vám řekne, která kontrola jej odmítla.

Tyto příkazy vypíšou rozšíření použití a řádky ověření z podrobného připojení:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

Pokud rozšíření ukazují roli serveru a protokol stále hlásí selhání role, profil pravděpodobně ukazuje na špatný soubor certifikátu, nikoli na špatný certifikát. Pokud rozšíření ukazují pouze autentizaci klienta, přestaňte se dívat na klienta a opravte vydání. V každém případě obnovte kontrolu, než připojení nazvete zdravým, protože úspěšný handshake po odstranění ověření dokazuje méně než chyba, kterou nahradil.