Înainte să-l convertiți: cheie SSH sau certificat OpenVPN

Importul eșuează cu o eroare de certificat, așa că pasul evident pare o conversie. Acel instinct îi duce pe oameni pe un drum în care extensia fișierului se schimbă, iar respingerea rămâne exact aceeași. O linie ssh-ed25519 în authorized_keys și un certificat de client OpenVPN sunt obiecte de acreditare separate, cu emitenți diferiți, codificări diferite și căi de revocare diferite. Parcurgerea acestor verificări în ordine vă spune într-un minut dacă o conversie poate ajuta măcar.

Ce obiect aveți de fapt?

Există cinci lucruri pe care oamenii le numesc cheie, și doar unul dintre ele este ceea ce vrea un profil TLS. O cheie publică SSH este o singură linie de text cu un prefix de tip și o încărcătură base64. Un certificat OpenSSH este acea cheie plus o semnătură, principii și opțiuni, produse de ssh-keygen acționând ca propria sa CA mică. Un certificat X.509 este o structură complet diferită, care poartă un subiect, o fereastră de valabilitate, extensii și o semnătură de la o autoritate de certificare. O cheie privată este jumătatea secretă, iar un pachet emis este de obicei un certificat plus lanțul său plus cheia privată într-un singur fișier.

Primul test costă o singură comandă. Îndreptați openssl spre fișier și cereți-i să analizeze structura certificatului:

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

Dacă eșuează cu o eroare de încărcare imposibilă sau PEM, fișierul nu este un certificat X.509 oricum l-ați numit. Redenumirea nu rescrie ASN.1 din interior, iar învelirea unei linii de cheie publică în text de antet PEM nu face nici ea asta.

Profilul cere măcar un certificat?

Certificatele de client sunt o metodă de autentificare printre mai multe, iar multe profiluri TLS funcționale nu cer niciodată unul. Un server poate autentifica utilizatorii printr-un plugin, un nume de utilizator și o parolă sau un backend de tokenuri, cerând în același timp clientului să verifice identitatea serverului. Dacă profilul nu conține o directivă de certificat de client, nu va fi niciodată cerut un certificat, iar nicio conversie nu va face gateway-ul să ceară unul.

Configurațiile vechi cu cheie statică sunt un al treilea caz. Ele precedă strângerea de mână TLS și așteaptă un fișier de secret partajat în prealabil, motiv pentru care lipirea unei chei publice în acel câmp nu poate funcționa nici ea. Citiți ce cere de fapt profilul înainte de a decide că acreditarea este greșită.

Ce poate și ce nu poate face recodificarea

Cheile private au într-adevăr containere alternative legitime. Aceeași cheie RSA sau EC poate fi scrisă ca PEM tradițional, ca PKCS#8 sau într-un pachet PKCS#12, iar instrumentele convertesc cu plăcere între ele. Cheile publice au o poveste similară: ssh-keygen poate emite forma RFC 4716 a unei chei SSH, iar OpenSSH înțelege și propriul format de certificat. Toate acestea sunt reprezentare, iar reprezentarea nu este încredere.

Ceea ce conversia nu poate face este să creeze o semnătură de la o autoritate de certificare care nu v-a văzut niciodată cheia. Un certificat este o afirmație a unui emitent că o anumită cheie publică aparține unui anumit subiect pentru un anumit scop. Recodificarea păstrează octeții cheii și lasă afirmația absentă, așa că gateway-ul nu are ce valida împotriva depozitului său de încredere.

Acesta este pasul la care majoritatea încercărilor eșuează în tăcere: fișierul se termină acum în .crt, clientul îl citește fără să se plângă, iar strângerea de mână tot se întrerupe pentru că partea cealaltă nu poate construi un lanț până la un emitent de încredere.

Unde intră în scenă autoritatea de certificare

O înregistrare reală începe cu o pereche de chei pe care o controlați și cu o cerere de semnare a certificatului care poartă subiectul așteptat de operator. Operatorul verifică dreptul, semnează cererea cu cheia CA și returnează certificatul emis împreună cu orice lanț intermediar pe care clientul trebuie să îl prezinte. Apoi clientul are nevoie de certificatul CA care l-a semnat, pentru că el este cel care îi permite să confirme că serverul cu care vorbește aparține aceleiași implementări.

Acest ultim fișier este ușor de uitat și imposibil de înlocuit. Cheia de semnare a CA nu aparține niciodată configurației clientului, iar nicio conversie locală nu produce lanțul pe care ar fi trebuit să îl primiți.

Cât vă costă reutilizarea cheii SSH

Să presupunem că o conversie a produs totuși ceva acceptabil. Reutilizarea unei singure perechi de chei pentru accesul SSH și autentificarea VPN cuplează în continuare două decizii de securitate independente. Eliminarea unei intrări din authorized_keys oprește autentificările SSH și nu face nimic unui certificat pe care CA a VPN-ului l-a emis deja pentru aceeași cheie publică. Partea VPN este revocată prin propriul mecanism, adică lista de revocare a certificatelor sau evidența de înregistrare a operatorului.

Așa că lista de verificare se termină cu o condiție de oprire, nu cu un truc. Dacă openssl nu analizează fișierul ca certificat, opriți conversia și descrieți ce aveți: cheie SSH, certificat SSH, certificat X.509, cheie privată sau pachet. Dacă profilul nu cere un certificat de client, opriți-vă și întrebați ce metodă de autentificare așteaptă serverul. Numai când ambele răspunsuri indică X.509 devine înregistrarea pasul următor, iar conversația aceea merge mult mai repede cu substantivul corect în prima propoziție.