Користите постојећи корпоративни 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 користи унутар документоване границе прихватања, а не као одлагалиште поверења опште намене.