Профіль OpenVPN мае тры блокі сертыфікатаў: які з іх сакрэтны?

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

Адзін файл, тры блокі, розныя задачы

Тыповы профіль убудоўвае блок ca, блок cert і блок key паміж маркерамі BEGIN і END або указуе на тыя ж тры як на асобныя файлы. Некаторыя профілі дадаюць чацвёрты блок для ключа tls-auth або tls-crypt, які з’яўляецца агульным сакрэтам, а не сертыфікатам. Кліент чытае кожны блок згодна з дырэктывай, якая яго называе, таму пазначэнні важнейшыя за парадак іх з’яўлення.

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

Дырэктывы вакол блокаў вызначаюць, як яны выкарыстоўваюцца. Змяніце ca — і кліент давярае іншай установе; змяніце cert, не змяніўшы key, — і рукапоціск падае з неадпаведнасцю, якая не мае ніякага дачынення да даверу.

Блок CA публічны, ключ CA — ніколі

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

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

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

Серверны і кліенцкі сертыфікаты накіраваны ў процілеглыя бакі

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

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

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

Дзве запыты, якія выглядаюць аднолькава і не з’яўляюцца такімі

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

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

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

Што даказвае чысты рукапоціск і што не

Дасягненне завершанага TLS-рукапоціску азначае, што наладжаныя адносіны ідэнтычнасці вытрымалі: серверны сертыфікат прывязаны да вашага CA, а ваш сертыфікат прыняты. Гэта нічога не кажа пра палітыку журналаў аператара і нічога пра тое, ці будуць працаваць вашыя праграмы пасля ўзняцця тунеля.

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