remote-cert-tls server: какво проверява директивата в профил на OpenVPN

Три различни въпроса получават отговор от три различни части на профила на OpenVPN и точно смесването им води до това хората да изключат проверка, която е работела. Подписан ли е сертификатът на партньора от органа, на който се доверявам? Декларира ли този сертификат ролята на TLS сървър? Дали това е точно сървърът, който съм искал да достигна? remote-cert-tls server отговаря само на средния въпрос и го прави, като чете разширенията вътре в сертификата.

Три проверки, които лесно се смесват в главата

Котвата на доверие живее в директивата ca. Проверката на ролята принадлежи на remote-cert-tls. Проверката на идентичността принадлежи на verify-x509-name, когато профилът го използва, или на каквато и проверка на името да добави внедряването.

Те покриват различни откази:

Един профил може да има и трите и пак да е слаб, ако CA е споделен твърде широко, което е въпрос на управление на ключове, а не на директиви.

Какво чете проверката на ролята

Директивата е макрос. Тя се разгръща в изискване за използване на ключ и изискване за разширено използване на ключ, което посочва ролята TLS уеб сървър, така че сертификатът на партньора трябва действително да декларира тази цел. Сертификат, издаден за удостоверяване на клиент, не го удовлетворява, дори когато същият орган е подписал и двата.

Това е важно, защото споделен CA е често срещан в малки внедрявания. Един орган подписва всеки клиент и сървъра и без проверка на ролята всеки от тези сертификати може да завърши сървърната страна на ръкостискането. Проверката не прави този сценарий невъзможен, но премахва тривиалната му версия.

Директивата е асиметрична по дизайн: клиентите носят remote-cert-tls server, а сървърите носят remote-cert-tls client. Разменете ги и всяка връзка се проваля с грешка за роля, която изглежда като повреден сертификат.

По-старите профили понякога използват ns-cert-type за същата цел. Актуалните страници на ръководството считат тази опция за заменена, така че профил, който все още разчита на нея, заслужава мигриране, а не отстраняване на грешки.

Защо изключването изглежда като поправка

Когато проверката на ролята се провали, връзката спира с грешка при проверката и очевидното действие е да изтриете реда. Тогава връзката се вдига, което изглежда като напредък и всъщност е режимът на отказ, който директивата съществува да предотврати. Сега приемате партньор, чийто сертификат никога не е бил предназначен за тази роля.

Вместо това прочетете грешката. Тя назовава проверката, която се е провалила, а сертификатът от другата страна може да бъде прегледан, за да се види какви разширения наистина носи. Две минути четене решават дали неизправността е в издаването, или в конфигурацията. Гадаенето струва един следобед и обикновено завършва с отслабен профил. Подновен сървърен сертификат, който е загубил разширеното си използване на ключ, е истинска неизправност в подновяването, а не причина да отпускате клиента.

Проверката на името е отделна директива

Удовлетворяването на проверката на ролята казва, че партньорът е някакъв сървър, подписан от вашия орган. Това не казва нищо за кой точно, което има значение, когато един и същ CA издава сертификати за няколко шлюза и един от тях е компрометиран или преназначен.

verify-x509-name сравнява субекта на сертификата със стойност, която конфигурирате, с режими за съвпадение за точен субект, префикс или едно поле. Използвайте полето, което действително идентифицира шлюза, и очаквайте да го актуализирате умишлено, когато името се промени.

Нито една от директивите не заменя доброто боравене с ключове. Ако файлът с клиентския ключ се копира наоколо с профила, идентичността на партньора е толкова силна, колкото е списъкът за разпространение.

Прегледайте сертификата, преди да редактирате профила

Прочетете сертификата на партньора и клиентския журнал, в този ред. Сертификатът ви казва какви роли декларира; журналът ви казва коя проверка го е отхвърлила.

Тези команди отпечатват разширенията за използване и редовете за проверка от подробна връзка:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

Ако разширенията показват ролята на сървър, а журналът все още съобщава за отказ на ролята, профилът вероятно сочи към грешен файл на сертификат, а не към лош сертификат. Ако разширенията показват само удостоверяване на клиент, спрете да гледате клиента и поправете издаването. Във всеки случай възстановете проверката, преди да наречете връзката здрава, защото успешно ръкостискане след премахване на проверката доказва по-малко от грешката, която е заменило.