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 документує три типи та їхні нотатки про довіру, і це та довідка, на яку посилаються, коли інтерфейс постачальника розходиться з профілем.