Përpara se ta konvertoni: çelës SSH kundrejt certifikatës OpenVPN

Importimi dështon me një gabim certifikate, prandaj hapi i dukshëm duket si konvertim. Ky instinkt i çon njerëzit në një rrugë ku ndryshon shtesa e skedarit dhe refuzimi mbetet saktësisht i njëjtë. Një rresht ssh-ed25519 në authorized_keys dhe një certifikatë klienti OpenVPN janë objekte kredenciale të veçanta, me lëshues të ndryshëm, kodime të ndryshme dhe rrugë të ndryshme revokimi. Kalimi i këtyre kontrolleve sipas radhës ju tregon brenda një minute nëse konvertimi mund të ndihmojë fare.

Cilin objekt keni në të vërtetë?

Janë pesë gjëra që njerëzit i quajnë çelës, dhe vetëm njëra prej tyre është ajo që kërkon një profil TLS. Një çelës publik SSH është një rresht i vetëm teksti me një parashtesë tipi dhe një ngarkesë base64. Një certifikatë OpenSSH është ai çelës plus një nënshkrim, principals dhe opsione, të prodhuara nga ssh-keygen që vepron si CA e vetë e vogël. Një certifikatë X.509 është një strukturë krejt tjetër, që mban një subjekt, një dritare vlefshmërie, zgjerime dhe një nënshkrim nga një autoritet certifikimi. Çelësi privat është gjysma sekrete, dhe paketa e lëshuar është zakonisht një certifikatë plus zinxhiri i saj plus çelësi privat në një skedar të vetëm.

Testi i parë kushton një komandë. Drejtojeni openssl në skedar dhe kërkojini të analizojë strukturën e certifikatës:

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

Nëse kjo dështon me një gabim mundësie ngarkimi ose PEM, skedari nuk është certifikatë X.509, sido që ta keni quajtur. Riemërtimi nuk rishkruan ASN.1 brenda, dhe as mbështjellja e një rreshti çelësi publik në tekst kryeje PEM.

A kërkon profili fare certifikatë?

Certifikatat e klientit janë një metodë vërtetimi midis disave, dhe shumë profile TLS që funksionojnë nuk kërkojnë kurrë një të tillë. Serveri mund t'i vërtetojë përdoruesit përmes një shtojce, emrit të përdoruesit dhe fjalëkalimit, ose një backend tokenësh, ndërkohë që vazhdon të kërkojë nga klienti të verifikojë identitetin e serverit. Nëse profili nuk përmban direktivë certifikate klienti, kurrë nuk do të kërkohet një certifikatë, dhe asnjë konvertim nuk do ta bëjë portalin të kërkojë një.

Konfigurimet e vjetra me çelës statik janë një rast i tretë. Ato i paraprijnë shtrëngimit të duarve TLS dhe presin një skedar me sekret të ndarë paraprakisht, prandaj as ngjitja e një çelësi publik në atë fushë nuk mund të funksionojë. Lexoni çfarë kërkon në të vërtetë profili përpara se të vendosni se kredenciali është i gabuar.

Çfarë mund dhe çfarë nuk mund të bëjë rikodimi

Çelësat privatë kanë vërtet kontejnerë alternativë legjitimë. I njëjti çelës RSA ose EC mund të shkruhet si PEM tradicional, si PKCS#8, ose brenda një pakete PKCS#12, dhe mjetet konvertojnë me kënaqësi midis tyre. Çelësat publikë kanë një histori të ngjashme: ssh-keygen mund të nxjerrë formën RFC 4716 të një çelësi SSH, dhe OpenSSH kupton edhe formatin e vet të certifikatës. E gjithë kjo është paraqitje, dhe paraqitja nuk është besim.

Ajo që konvertimi nuk mund të bëjë është të krijojë një nënshkrim nga një autoritet certifikimi që nuk e ka parë kurrë çelësin tuaj. Një certifikatë është një pohim i lëshuesit se një çelës publik i caktuar i përket një subjekti të caktuar për një qëllim të caktuar. Rikodimi ruan bajtët e çelësit dhe e lë pohimin mungues, kështu që portali nuk ka çfarë të vlefshmojë kundrejt magazinës së vet të besimit.

Ky është hapi ku shumica e përpjekjeve dështojnë në heshtje: skedari tani mbaron me .crt, klienti e lexon pa u ankuar, dhe shtrëngimi i duarve prapë përfundon sepse pala tjetër nuk mund të ndërtojë një zinxhir deri te një lëshues i besuar.

Ku hyn autoriteti i certifikimit në pamje

Një regjistrim i vërtetë fillon me një çift çelësash që ju kontrolloni dhe një kërkesë nënshkrimi certifikate që mban subjektin që pret operatori. Operatori verifikon të drejtën, nënshkruan kërkesën me çelësin CA, dhe kthen certifikatën e lëshuar bashkë me çdo zinxhir të ndërmjetëm që klienti duhet të paraqesë. Pastaj klientit i duhet certifikata CA që e nënshkroi, sepse ajo është ajo që i lejon të konfirmojë se serveri me të cilin flet i përket të njëjtit vendosje.

Ai skedari i fundit harrohet lehtë dhe zëvendësohet me vështirësi. Vetë çelësi nënshkrues i CA nuk i përket kurrë konfigurimit të klientit, dhe asnjë sasi konvertimi lokal nuk prodhon zinxhirin që duhej të kishit marrë.

Çfarë ju kushton ripërdorimi i çelësit SSH

Supozoni se një konvertim prodhoi vërtet diçka të pranueshme. Ripërdorimi i një çifti çelësash për aksesin SSH dhe vërtetimin VPN vazhdon të lidhë dy vendime sigurie të pavarura. Heqja e një zëri nga authorized_keys ndalon hyrjet SSH, dhe nuk i bën asgjë një certifikate që CA e VPN-së e ka lëshuar tashmë për të njëjtin çelës publik. Ana e VPN-së revokohet përmes mekanizmit të vet, domethënë lista e revokimit të certifikatave ose regjistri i regjistrimit të operatorit.

Prandaj lista e kontrollit përfundon me një kusht ndalimi dhe jo me një truk. Nëse openssl nuk e analizon skedarin si certifikatë, ndaloni konvertimin dhe përshkruani çfarë keni: çelës SSH, certifikatë SSH, certifikatë X.509, çelës privat ose paketë. Nëse profili nuk kërkon një certifikatë klienti, ndaloni dhe pyesni cilën metodë vërtetimi pret serveri. Vetëm kur të dy përgjigjet tregojnë X.509, regjistrimi bëhet hapi tjetër, dhe ai bisedë shkon shumë më shpejt me emrin e duhur në fjalinë e parë.