Преди да го конвертирате: 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

Ако това се провали с грешка за невъзможност за зареждане или 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 влизанията и не прави нищо на сертификат, който VPN CA вече е издал за същия публичен ключ. VPN страната се отзовава чрез собствения си механизъм, което означава списъка за отзоваване на сертификати или записа за записване при оператора.

Затова контролният списък завършва с условие за спиране, а не с трик. Ако openssl не разчете файла като сертификат, спрете конвертирането и опишете какво имате: SSH ключ, SSH сертификат, X.509 сертификат, частен ключ или пакет. Ако профилът не иска клиентски сертификат, спрете и попитайте кой метод за удостоверяване очаква сървърът. Само когато и двата отговора сочат към X.509, записването става следващата стъпка и този разговор минава много по-бързо с правилното съществително в първото изречение.