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