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