Pirms konvertējat: SSH atslēga pret OpenVPN sertifikātu

Importēšana neizdodas ar sertifikāta kļūdu, tāpēc acīmredzamais solis izskatās kā konvertēšana. Šis instinkts ved cilvēkus pa ceļu, kur mainās faila paplašinājums, bet atteikums paliek tieši tāds pats. Rinda ssh-ed25519 failā authorized_keys un OpenVPN klienta sertifikāts ir atsevišķi akreditācijas datu objekti ar dažādiem izdevējiem, dažādiem kodējumiem un dažādiem atsaukšanas ceļiem. Izpētot šīs pārbaudes pēc kārtas, minūtes laikā uzzināsiet, vai konvertēšana vispār var palīdzēt.

Kuru objektu jūs patiesībā turat?

Ir piecas lietas, ko cilvēki sauc par atslēgu, un tikai viena no tām ir tas, ko vēlas TLS profils. SSH publiskā atslēga ir viena teksta rinda ar tipa prefiksu un base64 saturu. OpenSSH sertifikāts ir šī atslēga plus paraksts, principals un opcijas, ko ģenerē ssh-keygen, darbojoties kā sava mazā CA. X.509 sertifikāts ir pavisam cita struktūra: tas nes subjektu, derīguma logu, paplašinājumus un sertifikācijas iestādes parakstu. Privātā atslēga ir slepenā puse, un izsniegtā pakete parasti ir sertifikāts plus tā ķēde plus privātā atslēga vienā failā.

Pirmais tests maksā vienu komandu. Vērsiet openssl uz failu un palūdziet tam analizēt sertifikāta struktūru:

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

Ja tas neizdodas ar nevar ielādēt vai PEM kļūdu, fails nav X.509 sertifikāts, lai kā jūs to nosauktu. Pārdēvēšana nepārraksta iekšpusē esošo ASN.1, un to nedara arī publiskās atslēgas rindas ietīšana PEM galvenes tekstā.

Vai profils vispār pieprasa sertifikātu?

Klienta sertifikāti ir viena autentifikācijas metode no vairākām, un daudzi strādājoši TLS profili to nekad nepieprasa. Serveris var autentificēt lietotājus ar spraudni, lietotājvārdu un paroli vai pilnvaru aizmuguri, vienlaikus pieprasot, lai klients pārbaudītu servera identitāti. Ja profilā nav klienta sertifikāta direktīvas, sertifikāts nekad netiks pieprasīts, un neviena konvertēšana neliks vārtejai to pieprasīt.

Vecākas statiskās atslēgas konfigurācijas ir trešais gadījums. Tās ir pirms TLS rokasspiediena un gaida iepriekš kopīgu slepeno failu, tāpēc arī publiskās atslēgas ielīmēšana šajā laukā nevar darboties. Izlasiet, ko profils patiešām pieprasa, pirms nolemjat, ka akreditācijas dati ir nepareizi.

Ko pārkodēšana var un ko nevar

Privātajām atslēgām tiešām ir likumīgi alternatīvi konteineri. To pašu RSA vai EC atslēgu var ierakstīt kā tradicionālu PEM, kā PKCS#8 vai PKCS#12 paketes iekšpusē, un rīki labprāt konvertē starp tiem. Publiskajām atslēgām ir līdzīgs stāsts: ssh-keygen var izvadīt SSH atslēgas RFC 4716 formu, un OpenSSH saprot arī savu sertifikāta formātu. Tas viss ir attēlojums, un attēlojums nav uzticēšanās.

Ko konvertēšana nevar, ir radīt parakstu no sertifikācijas iestādes, kas nekad nav redzējusi jūsu atslēgu. Sertifikāts ir izdevēja apgalvojums, ka konkrēta publiskā atslēga pieder konkrētam subjektam konkrētam mērķim. Pārkodēšana saglabā atslēgas baitus un atstāj apgalvojumu neesošu, tāpēc vārtejai nav ar ko pārbaudīt pret savu uzticības krātuvi.

Šis ir solis, kurā lielākā daļa mēģinājumu klusi neizdodas: fails tagad beidzas ar .crt, klients to lasa bez iebildumiem, un rokasspiediens tomēr pārtrūkst, jo pretējā puse nevar izveidot ķēdi līdz uzticamam izdevējam.

Kur attēlā ienāk sertifikācijas iestāde

Īsta reģistrācija sākas ar jūsu kontrolētu atslēgu pāri un sertifikāta parakstīšanas pieprasījumu, kas nes operatora gaidīto subjektu. Operators pārbauda tiesības, paraksta pieprasījumu ar CA atslēgu un atgriež izsniegto sertifikātu kopā ar jebkuru starpķēdi, kas klientam jāuzrāda. Pēc tam klientam vajag to parakstījušo CA sertifikātu, jo tieši tas ļauj apstiprināt, ka serveris, ar kuru tas runā, pieder tai pašai izvietošanai.

To pēdējo failu ir viegli aizmirst un neiespējami aizstāt. Pats CA parakstīšanas atslēga nekad nepieder klienta konfigurācijai, un nekāda vietējā konvertēšana nerada ķēdi, kas jums bija jāsaņem.

Ko jums izmaksā SSH atslēgas atkārtota izmantošana

Pieņemsim, ka konvertēšana tomēr radīja kaut ko pieņemamu. Viena atslēgu pāra izmantošana gan SSH piekļuvei, gan VPN autentifikācijai joprojām saista divus neatkarīgus drošības lēmumus. authorized_keys ieraksta noņemšana pārtrauc SSH pieteikšanos, un tas neko nedara sertifikātam, ko VPN CA jau ir izsniegusi tai pašai publiskajai atslēgai. VPN puse tiek atsaukta ar savu mehānismu, proti, sertifikātu atsaukšanas sarakstu vai operatora reģistrācijas ierakstu.

Tāpēc kontrolsaraksts beidzas ar apturēšanas nosacījumu, nevis triku. Ja openssl failu neanalizē kā sertifikātu, pārtrauciet konvertēšanu un aprakstiet, kas jums ir: SSH atslēga, SSH sertifikāts, X.509 sertifikāts, privātā atslēga vai pakete. Ja profils nepieprasa klienta sertifikātu, apstājieties un pajautājiet, kādu autentifikācijas metodi serveris gaida. Tikai tad, kad abas atbildes norāda uz X.509, reģistrācija kļūst par nākamo soli, un šī saruna norit daudz ātrāk, ja pirmajā teikumā ir pareizais lietvārds.