Самападпісаныя супраць публічных CA для VPN: што насамрэч змяняецца

Вы адкрываеце старонку сертыфікатаў у наладах VPN, бачыце бясплатны самападпісаны варыянт побач з платным публічным CA, і пытанне гучыць як выбар бяспекі. Насамрэч гэта выбар аўдыторыі. Абодва варыянты шыфруюць тунель аднымі і тымі ж прымітывамі, і абодва робяцца бяскарыснымі, калі прыватны ключ трапіць у рукі чужых. Што адрознівае іх — хто робіць сцвярджэнне пра асобу сервера і хто можа гэтае сцвярджэнне праверыць.

Сертыфікат выконвае дзве задачы, якія блытаюць

Сертыфікат звязвае публічны ключ з імем, а ключ выконвае працу шыфравання і подпісу. Подпіс на сертыфікаце — асобнае сцвярджэнне: нейкі орган праверыў, што імя належыць уладальніку гэтага ключа. Самападпісаны сертыфікат робіць гэтае сцвярджэнне пра самога сябе, а гэта зусім не сцвярджэнне трэцяга боку.

Публічным сайтам патрэбна версія ад трэцяга боку, бо наведвальнікі прыходзяць без папярэдніх адносін і спадзяюцца на сховішча даверу браўзера. Кліент VPN не чужы. Вы даяце яму сертыфікат CA або замацоўваеце сертыфікат сервера ў профілі, які ён усталёўвае, таму праверка ідзе менавіта супраць абранага вамі органа. Камерцыйны CA не павінен удзельнічаць, каб гэтая праверка нешта значыла.

Моцнасць атрыманай сесіі залежыць ад памеру ключа і набору шыфраў, а не ад падпісанта. Таму называць самападпісаны сертыфікат "менш шыфраваным" проста памылкова; ён менш шырока гарантаваны, а гэта іншая ўласцівасць.

Дзе публічны CA апраўдвае сваю плату

Найбольш відавочны выпадак — старонка адміністравання. Калі калегі, падрадчыкі ці любы іншы чалавек без падрыхтаванага профілю павінны адкрыць вэб-інтэрфейс сервера VPN без папярэджання браўзера, публічна давераны сертыфікат здымае гэтае трэнне. Браўзер ужо давярае падпісанту, таму няма чаго імпартаваць і няма чаго тлумачыць.

Гэтая зручнасць мае выдаткі, якія варта назваць перад купляй. Абнаўленне трэба аўтаматызаваць, інакш сайт ламаецца па раскладзе, публічныя сертыфікаты раскрываюць імя хоста ў журналах празрыстасці сертыфікатаў, а абмежаванні хуткасці выдачы караюць скрыпт, які занадта старанна паўтарае спробу. Нішто з гэтага не прычына пазбягаць публічнага CA, але гэта аперацыйная праца, якую прыватны CA пераносіць у іншае месца.

Чаго публічны сертыфікат не робіць — гэта не аўтэнтыфікуе вашых карыстальнікаў. Асоба кліента — асобнае рашэнне, якое прымаецца кліенцкімі сертыфікатамі, паролямі або другім фактарам, і CA, што падпісвае сервер, нічога не кажа пра тое, каму можна да яго падключацца.

Дзе прыватны CA падыходзіць для VPN

Для прыватнага VPN з вядомым наборам кліентаў весці ўласны CA — звычайны выбар. Вы ствараеце CA адзін раз, падпісваеце сертыфікат сервера імем, якое будуць выкарыстоўваць кліенты, і распаўсюджваеце сертыфікат CA ў кожным профілі. Тады кожны кліент правярае сервер супраць вашага органа, і ніводная знешняя старонка не даведваецца імя хоста.

Выдаткі рэальныя, але абмежаваныя. Браўзеры папярэдзяць, калі хтосьці адкрые старонку адміністравання напрамую, бо ў браўзера няма прычын давяраць вашаму CA. Распаўсюджванне профіляў становіцца часткай адаптацыі, а змена CA азначае дотык да кожнага кліента. Гэта прымальныя цэны для сэрвісу з дзесяццю ці пяццюдзесяцю вядомымі карыстальнікамі і балючыя для публічнай кропкі з тысячамі.

Адна ўмова робіць усю схему сапраўднай: праверка павінна адбывацца. Кліент, настроены ігнараваць памылкі сертыфікатаў, прымае любы сервер, які паказвае любы сертыфікат, таму гарантыя асобы знікае, а шыфраванне застаецца. Гэтая налада і ёсць сапраўдная слабасць у большасці гісторый пра "самападпісаныя ненадзейныя".

Прыватны ключ CA вырашае, што вы зможаце зрабіць пазней

Сюрпрыз звычайна прыходзіць праз месяцы, калі вы хочаце дадаць прыладу. Выдача кліенцкага сертыфіката патрабуе прыватнага ключа CA, і стварэнне спісу адклікання таксама. Калі вы атрымалі ў спадчыну сервер, які мае файлы сертыфіката і ключа, але не мае ключа CA, вы не можаце падпісаць нічога новага. Вашыя варыянты — перабудаваць PKI і выдаць кожнаму кліенту новы сертыфікат CA або перайсці на аўтэнтыфікацыю паролем, што ўяўляе іншую мадэль бяспекі і не вяртае страчанае.

Дзве драбнейшыя пасткі жывуць на той жа тэрыторыі. Скрыпты easy-rsa мяркуюць, што вы стаіце ў каталозе, які іх змяшчае, таму памылка адсутнага файла звычайна азначае няправільнае месца, а не пашкоджаную ўстаноўку. І схема толькі на сертыфікатах цалкам законная: вы можаце патрабаваць кліенцкія сертыфікаты без папярэдне агульнага ключа, пры ўмове, што ў кожнага кліента ён ёсць і сервер правярае ланцуг.

Выдавайце адзін сертыфікат на прыладу, а не адзін агульны кліенцкі сертыфікат на ўсю каманду. Тады страчаны ноўтбук каштуе вам аднаго адклікання замест перавыдачы для ўсіх.

Праверце, што вы атрымалі ў спадчыну

Перш чым планаваць любыя змены, прачытайце сертыфікат, які ў вас ужо ёсць:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

Калі выдавец роўны суб'екту, сертыфікат самападпісаны, што з'яўляецца выбарам дызайну, а не дэфектам. Даты паведамляюць, калі абнаўленне стане чыёйсьці праблемай, а паспяховая праверка супраць CA, які вы збіраецеся пастаўляць, пацвярджае, што ланцуг працуе яшчэ да таго, як яго паспрабуе хоць адзін кліент.

Затым выбірайце па аўдыторыі і распаўсюджванні: публічны CA, калі невядомыя браўзеры павінны давяраць старонцы адміністравання, прыватны CA, калі кожны кліент атрымлівае профіль, які вы кантралюеце. Ні адзін адказ не шыфраваны больш за іншы.