Bago ito i-convert: SSH key kumpara sa OpenVPN certificate

Nabibigo ang import na may error sa certificate, kaya ang halatang hakbang ay mukhang conversion. Ang instinct na iyon ay nagdadala ng mga tao sa landas kung saan nagbabago ang extension ng file at ang pagtanggi ay nananatiling eksaktong pareho. Ang linyang ssh-ed25519 sa authorized_keys at isang OpenVPN client certificate ay magkahiwalay na credential object, na may iba't ibang issuer, iba't ibang encoding at iba't ibang revocation path. Ang pagdaan sa mga pagsusuring ito nang sunod-sunod ay magsasabi sa iyo sa loob ng isang minuto kung makakatulong ba ang conversion.

Aling object ang talagang hawak mo?

May limang bagay na tinatawag ng mga tao na key, at isa lamang sa mga ito ang hinihingi ng isang TLS profile. Ang pampublikong SSH key ay isang linya ng teksto na may prefix ng uri at base64 na payload. Ang OpenSSH certificate ay ang key na iyon kasama ang isang lagda, principals at mga opsyon, na ginagawa ng ssh-keygen na kumikilos bilang sarili nitong maliit na CA. Ang X.509 certificate ay isang ganap na ibang istruktura, na nagdadala ng subject, validity window, mga extension at lagda mula sa isang certificate authority. Ang pribadong key ay ang lihim na kalahati, at ang inisyung bundle ay karaniwang isang certificate kasama ang chain nito kasama ang pribadong key sa isang file.

Ang unang pagsusulit ay isang utos lamang. Ituro ang openssl sa file at hilingin itong suriin ang istruktura ng certificate:

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

Kung nabigo iyon na may error na hindi ma-load o PEM, ang file ay hindi X.509 certificate anuman ang itinawag mo dito. Ang pagpapalit ng pangalan ay hindi nagsusulat muli ng ASN.1 sa loob, at ganoon din ang pagbabalot ng linya ng pampublikong key sa teksto ng PEM header.

Humihingi ba ang profile ng certificate?

Ang mga client certificate ay isang paraan ng authentication sa ilang paraan, at maraming gumaganang TLS profile ay hindi kailanman humihingi ng isa. Ang server ay maaaring mag-authenticate ng mga user sa pamamagitan ng plugin, username at password, o token backend, habang hinihiling pa rin sa client na i-verify ang pagkakakilanlan ng server. Kung ang profile ay walang direktiba ng client certificate, walang certificate ang hihilingin, at walang conversion ang magpipilit sa gateway na humingi ng isa.

Ang mga lumang static-key configuration ay ikatlong kaso. Nauuna ang mga ito sa TLS handshake at umaasa ng file ng secret na naibahagi nang maaga, kaya't ang pag-paste ng pampublikong key sa field na iyon ay hindi rin maaaring gumana. Basahin kung ano talaga ang hinihingi ng profile bago magpasya na mali ang credential.

Ano ang kaya at hindi kaya ng recoding

Ang mga pribadong key ay may lehitimong alternatibong container. Ang parehong RSA o EC key ay maaaring isulat bilang tradisyonal na PEM, bilang PKCS#8, o sa loob ng PKCS#12 bundle, at ang mga tool ay malugod na nagko-convert sa pagitan ng mga ito. Ang mga pampublikong key ay may katulad na kuwento: ang ssh-keygen ay maaaring maglabas ng anyong RFC 4716 ng isang SSH key, at nauunawaan din ng OpenSSH ang sarili nitong format ng certificate. Lahat ng iyon ay representasyon, at ang representasyon ay hindi tiwala.

Ang hindi kaya ng conversion ay lumikha ng lagda mula sa isang certificate authority na hindi kailanman nakakita ng iyong key. Ang certificate ay isang paghahayag ng issuer na ang isang partikular na pampublikong key ay pag-aari ng isang partikular na subject para sa isang partikular na layunin. Pinapanatili ng recoding ang mga byte ng key at hinahayaang wala ang paghahayag, kaya walang ma-validate ang gateway laban sa tindahan ng tiwala nito.

Ito ang hakbang kung saan tahimik na nabibigo ang karamihan ng pagtatangka: nagtatapos na ngayon ang file sa .crt, binabasa ito ng client nang walang reklamo, at nag-a-abort pa rin ang handshake dahil hindi makabuo ang kabilang panig ng chain hanggang sa pinagkakatiwalaang issuer.

Saan pumapasok ang certificate authority sa larawan

Ang tunay na enrolment ay nagsisimula sa isang pares ng key na kontrolado mo at isang certificate signing request na nagdadala ng subject na inaasahan ng operator. Vine-verify ng operator ang karapatan, nilalagdaan ang request gamit ang CA key, at ibinabalik ang inisyung certificate kasama ang anumang intermediate chain na dapat ipakita ng client. Pagkatapos ay kailangan ng client ang CA certificate na naglagda nito, dahil iyon ang nagpapahintulot dito na kumpirmahin na ang server na kausap nito ay kabilang sa parehong deployment.

Ang huling file na iyon ay madaling kalimutan at imposibleng palitan. Ang signing key mismo ng CA ay hindi kailanman kabilang sa client configuration, at walang dami ng lokal na conversion ang gumagawa ng chain na dapat mong natanggap.

Magkano ang gastos ng muling paggamit ng SSH key

Ipagpalagay na ang isang conversion ay talagang gumawa ng katanggap-tanggap. Ang muling paggamit ng isang pares ng key para sa SSH access at VPN authentication ay nag-uugnay pa rin ng dalawang independiyenteng desisyon sa seguridad. Ang pag-alis ng isang entry sa authorized_keys ay humihinto sa mga SSH login, at wala itong ginagawa sa isang certificate na inisyu na ng CA ng VPN para sa parehong pampublikong key. Ang panig ng VPN ay nire-revoke sa pamamagitan ng sarili nitong mekanismo, ibig sabihin ang certificate revocation list o ang enrolment record ng operator.

Kaya nagtatapos ang checklist sa isang kondisyon ng paghinto sa halip na isang trick. Kung hindi sinusuri ng openssl ang file bilang certificate, itigil ang conversion at ilarawan kung ano ang mayroon ka: SSH key, SSH certificate, X.509 certificate, pribadong key o bundle. Kung hindi humihingi ng client certificate ang profile, huminto at itanong kung anong paraan ng authentication ang inaasahan ng server. Kapag ang dalawang sagot ay tumuturo sa X.509, saka lamang nagiging susunod na hakbang ang enrolment, at ang usapan na iyon ay mas mabilis kapag tama ang pangngalan sa unang pangungusap.