Користете го постоечкиот корпоративен CA за OpenVPN партнери

Ништо во OpenVPN не бара сертификатот да доаѓа од Easy-RSA, а флотата што веќе има организациски PKI обично не треба да гради втор. Вистинската работа не е избор на алатка, туку одлука што значат издадените идентитети, кои партнери ги прифаќа тунелот и како обновувањето и отповикувањето стигнуваат до проверувачот. Поминете ги петте чекори подолу по ред, бидејќи подоцнежен чекор не може да поправи одлука за улога донесена во првиот.

Издадете две улоги наместо еден заеднички идентитет

На секој партнер му е потребен сопствен сертификат и соодветен приватен клуч. Побарајте од PKI тимот идентитет на сервер со серверска употреба и одделни клиентски идентитети со клиентска употреба, за тунелот да може да ги разликува двете при ракувањето.

Спротиставете се на кратенките што се појавуваат под притисок на рокови. Копиран клуч на веб-сервер на преносни сметачи ја брише разликата врз која се потпира проверката на улогата, а клуч за потпис на CA инсталиран на VPN крајна точка претвора еден компромитиран домаќин во компромитирана хиерархија. Пакетот PKCS12 може да носи клуч на крајна точка и неговиот синџир, но никогаш не дава дозвола тој идентитет повторно да се користи во друга улога.

Поврзете ги влезовите за доверба на секоја страна

На клиентот и на серверот на секој од нив му е потребно сидро за доверба, сопствен идентитет и јасно очекување на улогата. Фрагмент од клиент што ги наведува сите три изгледа вака.

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

Серверската страна го огледува тоа со remote-cert-tls client и сопствениот сертификат, и токму тоа спречува клиентски сертификат да биде прифатен како сервер. Проверката на името е одделна одлука од проверката на улогата. Прочитајте ја распоредената конфигурација за да видите кое поле се споредува, наместо да претпоставите совпаѓање на име на домаќин во стил на прелистувач. Двете страни треба исто така јасно да наведат на кој издавач имаат доверба, бидејќи заедничка патека до датотека низ флотата не е исто што и заедничка политика.

Доставете посредни сертификати без проширување на довербата

Двете страни не мора да делат еден издавачки синџир. Кога партнер претставува сертификат потпишан од посреден, страната што проверува му треба тој посреден достапен, и OpenVPN го разликува влезот на сидрото за доверба од дополнителните сертификати што се користат за комплетирање на локално претставен синџир. Референцата за TLS опции на OpenVPN 2.6 ги документира двете.

Посредниот CA сам по себе не е проблем, но широк корпоративен корен фрлен во пакетот за доверба е. Колку е пошироко сидрото, толку повеќе сертификати го поминуваат тестот на синџирот, а проверката на улогата тоа не го претвора во список на овластени вработени. Стеснете го сидрото до издавачот што навистина потпишува VPN идентитети каде хиерархијата тоа го дозволува. Ако не го дозволува, документирајте го поширокото сидро како намерно прифатен ризик наместо да го оставите имплицитно.

Договорете се со PKI тимот како обновувањето и отповикувањето стигнуваат до VPN проверувачите, вклучително кои издавачи се важни и кој го објавува списокот. Точката за дистрибуција на CRL вградена во сертификат е инструкција, не доказ дека нешто ја презело.

Одлучете како отповикувањето навистина пристигнува

crl-verify го тера проверувачот да консултира датотека или крајна точка, и тој распоред бара сопственик и пат за освежување. Список копиран еднаш за време на распоредувањето тивко престанува да ве штити при првото отповикување на сертификат.

Запишете го очекуваното време на ширење и тестирајте го со сертификат што сте подготвени да го отповикате. Ако списокот не може да се освежи на VPN домаќинот, алтернативата е пократок период на важност плус процес на обновување што навистина работи, а не претпоставка дека отповикувањето работи затоа што постои URL.

Докажете го прифаќањето со вистински клиент

Поврзете клиент што треба да биде дозволен и потврдете ги преговараните детали за сертификатот во дневникот. Потоа испробајте ги случаите што мора да пропаднат: клиентски сертификат претставен како сервер, сертификат од издавач надвор од сидрото за доверба и отповикан сертификат ако имате еден вишок.

Запишете го прифатениот издавач, проверката на улогата и изворот на отповикување до профилот. Тој запис е она што му треба на следниот инженер кога уред што работеше минатиот месец престанува да се поврзува, и тоа е исто така доказот дека корпоративниот CA се користи внатре во документирана граница на прифаќање, а не како депонија за доверба за општа намена.