Перш чым пераўтвараць: ключ SSH супраць сертыфіката OpenVPN

Імпарт завяршаецца памылкай сертыфіката, таму відавочны крок выглядае як пераўтварэнне. Гэты інстынкт вядзе людзей шляхам, дзе пашырэнне файла змяняецца, а адмова застаецца цалкам той самай. Радок ssh-ed25519 у authorized_keys і кліенцкі сертыфікат OpenVPN — асобныя аб’екты ўліковых даных, з рознымі эмітэнтамі, рознымі кадаваннямі і рознымі шляхамі адклікання. Паслядоўнае праходжанне гэтых праверак за хвіліну пакажа, ці можа пераўтварэнне наогул дапамагчы.

Які аб’ект вы насамрэч трымаеце?

Ёсць пяць рэчаў, якія людзі называюць ключом, і толькі адна з іх — гэта тое, што патрабуе профіль TLS. Публічны ключ SSH — адзін радок тэксту з прэфіксам тыпу і карыснай нагрузкай base64. Сертыфікат OpenSSH — гэта той жа ключ плюс подпіс, прынцыпалы і опцыі, створаныя ssh-keygen, які выступае ў ролі ўласнай невялікай CA. Сертыфікат X.509 — зусім іншая структура: ён нясе суб’ект, акно сапраўднасці, пашырэнні і подпіс ад цэнтра сертыфікацыі. Прыватны ключ — гэта сакрэтная палова, а выдадзены пакет звычайна ўяўляе сабой сертыфікат плюс яго ланцуг плюс прыватны ключ у адным файле.

Першая праверка каштуе адну каманду. Навядзіце openssl на файл і папрасіце разабраць структуру сертыфіката:

openssl x509 -in client.crt -noout -subject -issuer

Калі гэта завяршаецца памылкай unable-to-load або PEM, файл не з’яўляецца сертыфікатам X.509, як бы вы яго ні назвалі. Перайменаванне не перапісвае ASN.1 унутры, і абгортванне радка публічнага ключа ў тэкст загалоўка PEM таксама гэтага не робіць.

Ці профіль наогул патрабуе сертыфікат?

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

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

Што можа і чаго не можа перакадзіраванне

Прыватныя ключы сапраўды маюць законныя альтэрнатыўныя кантэйнеры. Той жа ключ RSA або EC можна запісаць як традыцыйны PEM, як PKCS#8 або ўнутры пакета PKCS#12, і інструменты з задавальненнем пераўтвараюць паміж імі. У публічных ключоў падобная гісторыя: ssh-keygen можа выдаць форму RFC 4716 ключа SSH, а OpenSSH разумее і ўласны фармат сертыфіката. Усё гэта — прадстаўленне, а прадстаўленне не ёсць давер.

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

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

Дзе ў карціну ўваходзіць цэнтр сертыфікацыі

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

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

Што вам каштуе паўторнае выкарыстанне ключа SSH

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

Такім чынам, кантрольны спіс канчаецца ўмовай спынення, а не трукам. Калі openssl не разбярэ файл як сертыфікат, спыніце пераўтварэнне і апішыце, што ў вас ёсць: ключ SSH, сертыфікат SSH, сертыфікат X.509, прыватны ключ або пакет. Калі профіль не патрабуе кліенцкага сертыфіката, спыніцеся і спытайце, які метад аўтэнтыфікацыі чакае сервер. Толькі калі абодва адказы паказваюць на X.509, рэгістрацыя становіцца наступным крокам, і размова ідзе значна хутчэй з правільным назоўнікам у першым сказе.