Použijte svou stávající podnikovou CA pro peery OpenVPN

Nic v OpenVPN nevyžaduje, aby certifikát pocházel z Easy-RSA, a flotila, která už má organizační PKI, obvykle nemá stavět druhou. Skutečná práce není výběr nástroje, ale rozhodnutí, co vydané identity znamenají, které peery tunel přijímá a jak se obnova a odvolání dostanou k ověřovateli. Projděte níže uvedených pět kroků v pořadí, protože pozdější krok nemůže napravit rozhodnutí o roli učiněné v prvním.

Vydávejte dvě role místo jedné sdílené identity

Každý peer potřebuje vlastní certifikát a odpovídající soukromý klíč. Požádejte tým PKI o identitu serveru nesoucí serverové použití a samostatné identity klientů nesoucí klientské použití, aby tunel při handshake rozeznal obě.

Odolejte zkratkám, které se objevují pod tlakem termínů. Zkopírovaný klíč webového serveru na notebooky smaže rozdíl, na kterém závisí kontrola role, a podpisový klíč CA nainstalovaný na koncovém bodu VPN promění jeden kompromitovaný host v kompromitovanou hierarchii. Balík PKCS12 může nést klíč koncového bodu a jeho řetěz, ale nikdy nedává svolení znovu použít tuto identitu v jiné roli.

Zapojte vstupy důvěry na každé straně

Klient i server potřebují každý svůj kořen důvěry, vlastní identitu a výslovné očekávání role. Fragment klienta, který uvádí všechny tři, vypadá takto.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

Strana serveru to zrcadlí pomocí remote-cert-tls client a vlastního certifikátu, a právě to brání tomu, aby byl klientský certifikát přijat jako server. Kontrola názvu je samostatné rozhodnutí od kontroly role. Přečtěte si nasazenou konfiguraci, abyste viděli, které pole se porovnává, místo abyste předpokládali shodu názvu hostitele ve stylu prohlížeče. Obě strany by také měly být výslovné v tom, kterému vydavateli důvěřují, protože sdílená cesta k souboru napříč flotilou není totéž jako sdílená zásada.

Doručujte zprostředkující certifikáty bez rozšiřování důvěry

Obě strany nemusí sdílet jeden vydavatelský řetěz. Když peer předloží certifikát podepsaný zprostředkujícím certifikátem, ověřující strana potřebuje tento zprostředkující certifikát k dispozici, a OpenVPN rozlišuje vstup kořene důvěry od dodatečných certifikátů použitých k dokončení lokálně předloženého řetězu. Reference voleb TLS pro OpenVPN 2.6 dokumentuje obojí.

Zprostředkující CA není sama o sobě problém, ale široký podnikový kořen vhozený do svazku důvěry ano. Čím širší je kořen, tím více certifikátů projde testem řetězu, a kontrola role z toho neudělá seznam oprávněných zaměstnanců. Zúžte kořen na vydavatele, který skutečně podepisuje identity VPN, kde to hierarchie dovoluje. Pokud ne, zdokumentujte širší kořen jako vědomě přijaté riziko, místo abyste ho nechali implicitní.

Dohodněte se s týmem PKI, jak se obnova a odvolání dostanou k ověřovatelům VPN, včetně toho, kteří vydavatelé jsou důležití a kdo zveřejňuje seznam. Distribuční bod CRL vložený do certifikátu je pokyn, ne důkaz, že ho něco stáhlo.

Rozhodněte, jak odvolání skutečně dorazí

crl-verify nutí ověřovatele nahlédnout do souboru nebo koncového bodu a toto uspořádání potřebuje vlastníka a cestu obnovy. Seznam zkopírovaný jednou při nasazení tiše přestane chránit při prvním odvolání certifikátu.

Zapište očekávanou dobu propagace a otestujte ji certifikátem, který jste ochotni odvolat. Pokud seznam nelze na hostiteli VPN obnovit, alternativou je kratší doba platnosti plus proces obnovy, který skutečně běží, ne předpoklad, že odvolání funguje, protože existuje URL.

Dokažte přijetí skutečným klientem

Připojte klienta, kterému má být povoleno připojení, a potvrďte vyjednané podrobnosti certifikátu v protokolu. Pak vyzkoušejte případy, které musí selhat: klientský certifikát předložený jako server, certifikát od vydavatele mimo kořen důvěry a odvolaný certifikát, pokud máte jeden navíc.

Zaznamenejte přijatého vydavatele, kontrolu role a zdroj odvolání vedle profilu. Tento záznam je to, co bude potřebovat další inženýr, když zařízení, které minulý měsíc fungovalo, přestane se připojovat, a je to také důkaz, že podniková CA se používá v rámci zdokumentované hranice přijetí, a ne jako univerzální úložiště důvěry.