remote-cert-tls server: што правярае дырэктыва ў профілі OpenVPN
Дырэктыва правярае ролю, закадзіраваную ў сертыфікаце суразмоўцы, а не яго імя. Параўнайце ролю, якар даверу і праверку імені хоста, перш чым нешта адключаць.
Тры розныя пытанні атрымліваюць адказы ад трох розных частак профілю OpenVPN, і менавіта іх змяшэнне прыводзіць да таго, што людзі адключаюць праверку, якая працавала. Ці падпісаны сертыфікат суразмоўцы тым цэнтрам, якому я давяраю? Ці аб'яўляе гэты сертыфікат ролю сервера TLS? Ці гэта менавіта той сервер, да якога я хацеў далучыцца? remote-cert-tls server адказвае толькі на сярэдняе пытанне, і робіць гэта, чытаючы пашырэнні ўнутры сертыфіката.
Тры праверкі, якія лёгка змяшаць у галаве
Якар даверу жыве ў дырэктыве ca. Праверка ролі належыць remote-cert-tls. Праверка асобы належыць verify-x509-name, калі профіль яе выкарыстоўвае, або любой праверцы імені, якую дадае разгортванне.
Яны пакрываюць розныя збоі:
| Question | Directive | Failure it catches |
|---|---|---|
| Who signed this? | ca | Certificate from an unrelated authority |
| Is this a server? | remote-cert-tls | Client certificate presented by a peer |
| Is this my server? | verify-x509-name | Another valid server from the same CA |
Профіль можа мець усе тры і ўсё роўна быць слабым, калі 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Калі пашырэнні паказваюць ролю сервера, а журнал усё яшчэ паведамляе пра збой ролі, профіль, верагодна, паказвае на няправільны файл сертыфіката, а не на дрэнны сертыфікат. Калі пашырэнні паказваюць толькі аўтэнтыфікацыю кліента, спыніце глядзець на кліент і выпраўце выдачу. У любым выпадку аднавіце праверку, перш чым называць злучэнне здаровым, бо паспяховы рукапаціск пасля выдалення праверкі даказвае менш, чым памылка, якую ён замяніў.