OpenVPN verify-x509-name: subject, name и name-prefix

Сначала прочитайте тип сопоставления, затем текст: verify-x509-name директива может выглядеть правильно и всё же принять сертификат, которому вы не собирались доверять. Две строки с одинаковым ожидаемым текстом, но разными типами — это разные требования. Сначала читайте тип, затем текст. Рассматривайте директиву как ещё одно условие подключения, а не как всю проверку.

Что на самом деле утверждает опция

Директива называет идентичность, которую должен нести сертификат другой стороны. Когда сравнение не удаётся, OpenVPN прерывает рукопожатие, и туннель не поднимается. Всё остальное в профиле по-прежнему действует: сертификат должен выстраиваться в цепочку до доверенного CA, а проверка роли должна пройти, поэтому это дополнительное условие, а не замена. Профиль, который удовлетворяет ожиданию имени и не проходит проверку роли, всё равно сломан, и журнал обычно так и говорит.

Это также отличается от проверки имени хоста, которую выполняет браузер. Браузер сопоставляет имена с альтернативными именами subject по правилам своего стека TLS, тогда как OpenVPN сравнивает одно поле сертификата с выбранным вами типом. Поэтому вставка имени хоста в браузерном стиле в директиву может дать несовпадение даже тогда, когда сертификат действительно покрывает службу.

subject: полное отличительное имя, символ за символом

Когда тип не указан, по умолчанию используется subject, и ожидаемое значение должно воспроизводить весь subject DN сертификата. Порядок полей, разделители, пробелы и экранирование — всё учитывается, потому что сравнение идёт по строке в том виде, в каком она закодирована. Если опустить тип, вы выбрали самое строгое из трёх сравнений. Нет шага нормализации, который спас бы косметическое различие. Это стоит знать до первого продления, а не после.

Эта строгость хрупка от продления к продлению. CA, который переупорядочивает атрибуты, вставляет лишнее поле или меняет способ экранирования значения, создаёт новую строку для той же машины, и директива, работавшая годами, начинает сбоить при следующем выпуске. Хранение принятого DN в журнале изменений превращает следующее продление в различие. Там, где оператор публикует полный DN и гарантирует его форму, subject — разумный выбор; в остальных случаях более узкое поле легче держать верным.

name: одно поле, обычно общее имя

Тип name сравнивает одно поле subject. Если профиль не говорит иначе, это поле — общее имя, и ожидаемое значение — именно это поле, а не DN вокруг него.

Загвоздка в том, что современные сертификаты не всегда помещают имя службы в CN. Многие несут его в альтернативном имени subject и оставляют CN пустым или общим, поэтому сертификат, который браузер принимает, всё равно может не пройти это сравнение. Прежде чем писать ожидание, изучите сертификат, который вам действительно выдали, и подтвердите, какое поле выбирает профиль. Пустой CN в сравнении с именем — это несовпадение, а не случайность конфигурации.

name-prefix: широкий по замыслу, поэтому ограничьте область

Ожидание типа name-prefix совпадает с началом выбранного поля. Это удобно для схемы именования и опасно для всего общего.

Если ожиданием является vpn.example , прошли бы и vpn.example.com и vpn.example.net , при условии что остальная часть цепочки доверенная. Широта — это свойство, и одновременно та часть, которую нужно обосновать письменно. Префикс разумен, когда CA и схема именования ваши, и гораздо слабее, когда публичный CA выдаёт по тому же шаблону. Если схеме нужна гибкость, ограничьте её на стороне CA, а не расширяйте проверку клиента.

Выберите тип по идентификатору, затем докажите его

Работайте в обратном направлении от идентичности, которую подразумевает оператор. Если он публикует полный DN и держит его стабильным, subject это и выражает. Если он называет службу общим именем, используйте name. Если он владеет схемой именования и принимает всё её пространство, name-prefix это прямо говорит.

Продления — это место, где директива проверяется. Сравнивайте одобренную идентичность с новым сертификатом, а не со старым файлом, потому что новый адрес конечной точки не означает новую идентичность сертификата. Не удаляйте директиву только потому, что знакомый адрес отвечает: доступность и предполагаемая сторона — разные факты, а адрес доказывает лишь то, что что-то ответило. Запишите точную ошибку и публичные данные имени в очищенном отчёте, потому что несовпадение имени можно показать без всякого материала закрытого ключа.

После поддерживаемого исправления подключитесь снова со всеми задуманными проверками и проверьте ресурс, который вам действительно нужен. Успех означает, что нужный сервер был принят, а не что какой-то сертификат протолкнули. Официальное руководство OpenVPN 2.6 manual документирует три типа и их заметки о доверии, и это та ссылка, на которую ссылаются, когда интерфейс поставщика расходится с профилем.