Пред да го конвертирате: SSH клуч наспроти OpenVPN сертификат

Увозот не успева со грешка за сертификат, па очигледниот чекор изгледа како конверзија. Тој инстинкт ги води луѓето по пат каде што се менува наставката на датотеката, а одбивањето останува сосема исто. Ред ssh-ed25519 во authorized_keys и клиентски сертификат на OpenVPN се одделни објекти на акредитиви, со различни издавачи, различни кодирања и различни патеки на отповикување. Ако ги поминете овие проверки по ред, за една минута ќе знаете дали конверзијата воопшто може да помогне.

Кој објект всушност го имате?

Постојат пет работи што луѓето ги нарекуваат клуч, а само една од нив е она што го бара TLS профилот. Јавниот SSH клуч е еден ред текст со префикс за тип и base64 товар. OpenSSH сертификатот е тој клуч плус потпис, principals и опции, произведени од ssh-keygen кој дејствува како сопствена мала CA. X.509 сертификатот е сосема друга структура: носи субјект, прозорец на важност, проширувања и потпис од сертификациско тело. Приватниот клуч е тајната половина, а издадениот пакет обично е сертификат плус неговиот синџир плус приватниот клуч во една датотека.

Првиот тест чини една команда. Насочете го openssl кон датотеката и побарајте да ја анализира структурата на сертификатот:

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

Ако тоа не успее со грешка за невозможно вчитување или 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, регистрацијата станува следен чекор, и тој разговор оди многу побрзо со вистинската именка во првата реченица.