Acest articol va explica modul de utilizare a certificatelor emise de o autoritate terță de certificare (CA), cum ar fi Let's Encrypt, Comodo, Symantec, Digicert etc. Va cuprinde, de asemenea, modul în care funcționează certificatele în general.
Rezumat
Certificatele au două scopuri principale: Criptarea comunicării între două entități și confirmarea autenticității entității. Primul poate fi acordat printr-un așa-numit certificat auto-semnat, dar pentru a autentifica entitatea, aveți nevoie de un certificat de încredere la nivel global emis de CA rădăcină sau intermediară. Acest articol va explica modul în care certificatele realizează în general această autentificare, cum se schimbă formatul certificatului pentru a funcționa cu alte dispozitive, inclusiv firewall-urile noastre, cum să importăm certificatul în firewall-ul dvs. și cum ar trebui tratate certificatele pentru a evita riscurile de securitate.
Cuprins
- Cum funcționează un certificat?
- Certificate auto-semnate
- Lucrul cu certificate
- Importul certificatelor în firewall-urile USG / ATP
- Securitate certificat
Cum funcționează un certificat?
Fiecare certificat este format din două părți: Certificatul (numit și cheia publică) și cheia privată. Certificatul poate fi distribuit public și conține doar informații despre scopurile pentru care a fost eliberat certificatul și către care entitate a fost emis certificatul - aceasta poate fi FQDN, adresa de e-mail sau altă valoare.
Certificatele au o perioadă de valabilitate limitată - acest lucru ajută la situațiile în care un certificat vechi cu cheie privată este dezgropat undeva după decenii. În cazul în care valabilitatea era infinită, certificatul ar putea fi încă folosit în scopuri rău intenționate de oricine pune mâna pe el. Începând cu 2021, se recomandă să nu utilizați o perioadă de valabilitate de peste un an. Odată cu apariția mecanismelor de reeditare automată, cum ar fi CertBot, această perioadă poate deveni mult mai scurtă pentru a îmbunătăți în continuare securitatea.
Certificatele pot fi revocate în cazul în care s-a scurs cheia privată - și, ca o precauție, orice încălcare a securității care a compromis hardware-ul care conține chei private ar trebui să fie urmată de o revocare a certificatului și reeditarea ulterioară a noilor certificate.
Certificatele pot fi eliberate către diverse entități, cum ar fi FQDN, e-mail, chiar adresa IP sau numele de utilizator. Deși este posibil din punct de vedere tehnic să aveți certificate FQDN wildcard și acestea sunt deseori preferate de utilizatori, rețineți că, în cazul unei scurgeri de chei private dintr-un anumit serviciu, certificatul wildcard autentifică întregul FQDN - ca urmare, o scurgere a cheia privată de pe un server web, care este utilizată pentru simpla prezentare a companiei, poate fi, de asemenea, utilizată pentru atacuri MITM între serverul Exchange sau sistemul CRM. Păstrarea certificatelor independente pentru fiecare subdomeniu ajută la atenuarea impactului scurgerii până când certificatul este revocat.
Deși este, de asemenea, posibil să emiteți certificate la adresa IP, acest lucru este depreciat. Motivul din spate este că IP-urile pot fi schimbate cu ușurință în comparație cu FQDN.
Principiul de bază al certificatelor este destul de simplu. Într-un exemplu, Alice dorește să acceseze serverul lui Bob, dar problema este că nu a fost niciodată acolo, astfel încât ei să nu poată schimba vreun secret comun pentru autentificare. Cum poate Alice să fie sigură că se conectează de fapt la Bob? Aici intervine Charlie. Alice îl cunoaște pe Charlie și și-a adăugat certificatul în depozitul de certificate rădăcină. Prin urmare, Alice îl consideră pe Charlie o entitate de încredere. Dacă Bob are propriul certificat și cheie privată eliberat de Charlie, el se poate autentifica cu Alice și nu contează că Alice nu a fost niciodată în legătură cu Bob înainte, deoarece Bob este de încredere de Charlie și, din moment ce Alice are încredere în Charlie, ea are încredere și în Bob. . Acest lucru se numește un lanț de încredere.
Să aruncăm o privire la Lanțul de încredere pentru certificatul nostru de web Campus de asistență:
Observați că există și o altă entitate numită R3. Aceasta se numește CA intermediară, în timp ce DST Root CA X3 este Root CA. Certificatul poate avea o singură CA rădăcină, dar pot exista mai multe CA intermediare. CA intermediară este o entitate căreia i sa acordat permisiunea de a emite certificate pentru clienții săi. Atâta timp cât computerul dvs. are certificatul DST Root CA X3 în lista certificatelor rădăcină de încredere, va considera support.zyxel.eu de încredere.
Certificate auto-semnate
În mod implicit, firewall-urile noastre (și multe alte dispozitive) folosesc certificate auto-semnate pentru a stabili conexiunea TLS criptată. Un astfel de certificat este raportat de un mesaj de eroare bine-cunoscut de către browser: 
Există două motive pentru care acest lucru se întâmplă. Primul motiv este că certificatul este practic un certificat CA rădăcină care nu este prezent în sistemul dvs. Dar pur și simplu să-l instalați ca CA rădăcină pe computerul dvs. nu va face truc, deoarece certificatul nu este emis pentru IP-ul sau domeniul dvs. Certificatul este totuși potrivit pentru o conexiune sigură și utilizarea acestuia nu prezintă niciun risc de securitate atâta timp cât cheia sa privată nu este scursă - singura problemă aici este că identitatea nu poate fi confirmată.
Lucrul cu certificate
De-a lungul anilor, au fost dezvoltate multe formate de certificate. Cu toate acestea, certificatele utilizează același principiu și toate formatele pot fi convertite în alte formate.
Formate de certificate
Cel mai vechi format ar fi PEM, care conține cheia codificată ASCII. Motivul din spatele acestui fapt este utilizarea originală în mesaje criptate, unde certificatul binar ar putea fi malformat. PEM-urile sunt frecvente în sistemele Unix și este probabil ca CA dvs. să vă fi trimis un certificat împreună cu o cheie privată în format PEM. De obicei folosește extensia de fișier .pem sau .cer.
DER este o formă binară de certificat în format ASCII PEM. Toate tipurile de certificate și chei private pot fi codate în format DER. Acest format acceptă stocarea unui singur certificat și nu include o cheie privată pentru CA intermediară / rădăcină. Au extensie .der sau .cer și sunt cele mai des utilizate pe platformele Java.
PKCS # 7 este un format binar care permite conținerea certificatelor sau a întregului certificat Lanț de încredere într-un singur fișier. Cu toate acestea, nicio cheie privată nu poate fi stocată în acest format. Acest format este cel mai des utilizat de către CA pentru a furniza un lanț de încredere complet. Folosește extensia .p7b.
PKCS # 12, cunoscut și sub numele de PFX, este un format care poate conține tot lanțul de încredere și cheia privată. De obicei, acest format este furnizat de CA, deoarece poate fi securizat printr-o parolă. Utilizează în mod obișnuit extensiile .p12 sau .pfx.
Instrumente de certificare
Windows are un utilitar CLI de sistem încorporat certutil care poate fi utilizat pentru a converti certificate. Pluginurile de gestionare din Microsoft Management Console permit, de asemenea, gestionarea certificatelor.
Utilitarul open-source numit OpenSSL este, de asemenea, capabil să gestioneze și să convertească certificate. Binare sunt disponibile pentru Windows, Linux și macOS (și multe alte platforme)
Comenzi utile certutil:
Merging PEM into PFX:
C:\temp>certutil –MergePFX cert.cer cert.pfx
NOTE: as certutil doesn't allow to specify private key path, the key must be present
in the same directory as certificate, have the same name and .key extension.
Comenzi utile OpenSSL:
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Importul certificatului în firewall-urile USG / ATP
Designul actual (din iunie 2021) este limitat la importul de certificate fără chei intermediare. În cazul în care certificatul conține o cheie intermediară, fișierul va fi analizat incorect și încercarea de a utiliza un astfel de certificat poate duce la indisponibilitatea serviciului (cum ar fi WebGUI). Este o idee bună să obțineți certificatul în format .pem și să-l exportați în format .pfx folosind fie certutil, fie OpenSSL. Certificatul poate fi importat, împreună cu parola acestuia, în următorul meniu:
Configuration > Objects > Certificates > My Certificates
Securitate certificat
Fiecare certificat are cheia privată respectivă. În timp ce un certificat este informație publică, cheia privată trebuie tratată ca un secret - și nu ar trebui să fie partajată de nimeni. Nici măcar la noi la Zyxel - singura modalitate validă este de a utiliza instrumente de asistență la distanță, cum ar fi TeamViewer. Când stocați cheia privată în format pem, verificați de două ori permisiunile de acces la cheia privată pentru a preveni scurgerea acesteia. Utilizați întotdeauna criptarea parolei în format pfx pentru a oferi cel puțin un anumit grad de securitate la exportul certificatelor. Orice certificate cu cheia privată scursă trebuie revocate imediat.
DISCLAIMER:
Stimate client, vă rugăm să rețineți că folosim traducerea automată pentru a furniza articole în limba dvs. locală. Este posibil ca nu toate textele să fie traduse cu exactitate. Dacă există întrebări sau discrepanțe cu privire la acuratețea informațiilor din versiunea tradusă, vă rugăm să consultați articolul original aici: Versiunea originală