Използвайте съществуващия си корпоративен 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 се използва в документирана граница на приемане, а не като хранилище за доверие с общо предназначение.