Încerc să lucrez cu OpenSSL C API, sunt relativ nou pentru toate acestea și găsesc o mulțime de informații amestecate acolo, deci cred că este înțelept să cereți idei / opinii / clarificări.
Oricum, programul client necesită încărcarea unui certificat sau director care conține un „TrustStore”. Este acesta doar un alt sens pentru certificatul CA al serverului în sine, în cazul în care îmi creez propriile certificate SSL pentru serverul respectiv?
Și dacă da, CA intermediară va funcționa în acest scop în înlocuirea CA rădăcină?
Cred că sunt pe drumul cel bun. Cu toate acestea, am dorit doar câteva clarificări pentru a mă împiedica să fac o greșeală reală, deoarece am „auzit unele informații contradictorii în ceea ce privește acest lucru. Unii spun că clientul are nevoie de CA rădăcină în sine; alte surse spun că instalează doar CA intermediară pentru motive de securitate, ceea ce pare logic.
În general, sunt puțin confuz cu privire la modul în care funcționează lanțul de încredere în ceea ce privește conexiunea clientului. De fapt, am avut nevoie doar pentru a genera un CSR și a instala un certificat pe serverul web, așa că lucrurile din partea clientului sunt cam noi pentru mine.
Această întrebare a fost inițial pusă aici pe Stack Overflow, s-a sugerat să întreb comunitatea info-sec.
Comentarii
- Cred că folosiți o frază greșită: un certificat auto-semnat este un certificat în care certificatul emitentului este certificatul în sine. Probabil că înseamnă un certificat care este semnat de propria CA. În acest caz: CA rădăcină este, de obicei, introdusă în magazinul de încredere, iar certificatul intermediar semnat de CA rădăcină și certificatul frunză semnat de certificatul intermediar sunt trimise în timpul strângerii de mână TLS .
- Posibil duplicat al Cum funcționează SSL / TLS PKI?
Răspuns
tl; dr Dacă certificatul conține unele variații ale CA:TRUE, este logic să îl distribuiți, dacă nu, atunci nu există niciun avantaj să îl distribuiți.
Lanțul de încredere în sine poate fi explicat în termeni de structură a certificatului.
Dacă pornim de la certificatul serverului dvs. (adică certificatul pe care l-ați folosi în mod obișnuit pentru apache):
- certificatul dvs. de server este generat de o autoritate de certificare, pe baza unui CSR pe care îl furnizați. Respectivul CSR conține cheia dvs. publică și alte informații pe care CA ar putea să le folosească sau nu.
- CA vă primește CSR-ul și (în general), va crea un certificat semnat folosind un CA intermediar. Certificatul dvs. va avea două chei publice: una pentru subiect (care este cheia publică extrasă din CSR-ul dvs.) și una pentru partea emitentă, care este certificatul intermediar al CA.
- CA ” Certificatul intermediar este el însuși un certificat semnat (cu unele opțiuni speciale), în care cheia subiectului va fi cheia publică a CA intermediară (care este aceeași cheie publică ca și în Cheia publică a emitentului certificatului serverului dvs.). cheia de semnare (sau emitere) va fi certificatul rădăcină al CA (alternativ, va fi un alt intermediar).
- certificatul rădăcină al CA este (în general) un certificat autosemnat. În practică, acest lucru înseamnă că cheile emitentului și ale subiectului sunt aceeași cheie publică.
Puteți vedea acest lucru verificând certificatele în natură, de exemplu:
$ openssl s_client -connect google.com:443 < /dev/null CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority Lanțul de încredere pe care îl construiește acesta poate fi rezumat ca (încep de la „ bottom „- certificatul Equifax):
- CA rădăcină (Equifax) delegă activitățile zilnice unei CA intermediare (GeoTrust) și semnează un certificat care reprezintă acest fapt (adică setarea CA: TRUE, KeyUsage: keyCertSign). Cu alte cuvinte, CA rădăcină „are încredere” în intermediarul pentru a emite certificate în numele său (sperăm că după finalizarea unei serii de pași de validare obligatorii).
- în acest lanț, intermediarul (Geotrust) a delegat în continuare unei CA Google (CN = Google Internet Authority G2).
- delegatul (cunoscut și ca CA intermediar Google) semnează apoi un CSR, care este efectiv un document care afirmă că pentru o anumită dată set de nume (t CN, și eventual Subiecte alternative alternative), o pereche de chei private / publice este validă / de încredere (încrederea de aici provine din faptul că au validat revendicarea de a vorbi pentru un nume dat – în acest caz, CA Google a emis un certificat pentru * .google.com).
Rețineți că CA-urile (rădăcină) sunt în general autosemnate – o CA are încredere în general, deoarece respectă un set de procese și proceduri care se simt pentru a se asigura că nu eliberează certificate persoanelor cine nu ar trebui să le aibă. Acesta este motivul pentru care nu pot ieși și să obțin un certificat care să spună că sunt google.Prin urmare, aceasta este o convenție de tip (deși una susținută de mecanisme formale) și, dacă porniți propria CA, distribuirea certificatelor sale rădăcină (și intermediare) realizează exact același lucru ca și distribuirea certificatelor altor CA: face certificate emise de către CA să fie acceptat ca valid (adică demn de încredere) de către sistem.
În termeni mai practici, magazinul de încredere (pentru openSSL) este aproape o grămadă de fișiere cu o convenție de denumire specifică. Consultați https://www.openssl.org/docs/faq.html#USER5 :
Când un certificat este verificat, CA-ul său rădăcină trebuie să fie „de încredere” de OpenSSL, ceea ce înseamnă de obicei că certificatul CA trebuie plasat într-un director sau fișier și că programul relevant trebuie configurat pentru a-l citi
Directorul respectiv este / etc / ssl / certs (există și altele, cum ar fi / etc / pki în RH-like-uri).
https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 oferă o imagine de ansamblu suplimentară a modului în care se adaugă un certificat în magazin, ca face https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,
Versiunea scurtă este că update-ca-certificate automatizează procesul și este instrumentul utilizat în mod obișnuit.
Versiunea puțin mai lungă este că certificatele trebuie stocate prin hash (de exemplu, în fișierele numite bazate pe pe ieșirea openssl x509 -hash -in cert.pem), astfel încât openSSL să poată valida în mod eficient lanțuri.
Consultați https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html pentru unele informații suplimentare.
actualizat pentru a răspunde la întrebările din comentarii:
Certificatul serverului , în această discuție, este definit ca fiind de încredere sau nu pe baza lanțului său de încredere. Dacă vă gândiți cum funcționează (de exemplu) curl https://google.com, este puțin mai ușor de înțeles:
- curl deschide o conexiune TLS la google, care returnează un certificat.
- curl privește acel certificat „utilizator final” – adică certificatul serverului și caută în mod specific emitentul.
- dacă emitentul este „cunoscut” în depozitul de încredere, restul lanțului de încredere este validat (adică certificatul emitentului certificatului de server este verificat și dacă acesta are un alt emitent decât el, acesta este verificat etc.). Certificatul este considerat valabil numai dacă lanțul complet de încredere poate fi validat.
Cu toate acestea, nu ar fi absolut practic să distribuiți lanțuri de încredere dacă ar trebui incluse certificatele de utilizator final. Nu am nicio cifră cu privire la câte site-uri web există, dar, pe baza faptului că Alexa oferă 1M de top, ați presupune că este mai mare de 1 milion.
Care este un punct un lanț de încredere: în general, trebuie să aveți certificatele emitentului în jur, dar nu aveți nevoie ca certificatele finale să fie distribuite, deoarece acestea vă spun cine este emitentul.
Și puteți verifica dacă acestea nu sunt ” minciuna, pentru că puteți verifica cheia publică a emitenților (și lanțul de încredere care o stabilește este cheia corectă) și puteți valida dacă certificatul de utilizator final (adică serverul) a fost într-adevăr semnat de omologul privat al cheie publică.
Deci nu, nu ar trebui să distribuiți certificatele utilizatorului final, ci doar lanțul de încredere – sau, în termeni mai simpli: distribuiți toate certificatele pe care le generați unde Constrângerile de bază (în mod legitim) spun ceva cel puțin CA: TRUE. Nu distribuiți nimic care nu îndeplinește această condiție, deoarece este o pierdere de timp și spațiu pe disc – tot ceea ce face nu spune CA: TRUE poate fi validat împotriva a ceva ce face.
Comentarii
Răspuns
Un certificat autosemnat este exact: este a semnat-o eu însuși (este propria sa ancoră de încredere).
Prin urmare, pentru a fi de încredere, trebuie să fie plasat manual și explicit în lista de ancore de încredere a aplicației. Modul în care se face acest lucru depinde de sistemul de operare și aplicație. De exemplu, dacă utilizați stocarea certificatului intern Windows, atunci trebuie să plasați acel certificat auto-semnat în magazinul „autoritate de certificare rădăcină de încredere” sau certificatul nu va fi acceptat. OpenSSL folosește un sistem de stocare diferit, specific aplicației: va trebui să instalați certificatul și ca un CA de încredere, dar cum să faceți acest lucru depinde în mare măsură de exact ce aplicație și sistem de operare utilizați (consultați acest articol pentru câteva instrucțiuni generice).
Comentarii
- Deci înseamnă asta " Trust Store " certificat este exact același cu cel instalat în apache, de exemplu? Acel ' s partea care este cea mai confuză, i ' ma
GNU/Linuxutilizator, a cărui director trebuia să-l conectez în aplicația client, a fost/etc/ssl/certs. Cu toate acestea, nu am reușit să găsesc o explicație clară despre exact ce este procesul de pe acea parte a lucrurilor. Cel puțin înțelegeți întrebarea mea aici, principalul punct din spatele acesteia este să scrieți clientului și puneți-l în încredere în serverul la care se conectează. - Ce i ' Încerc să fac exact este să creez un CA și cred că certificatul este semnat de CA (intermediar), deci, în acest caz, înseamnă că CA este ancora de încredere, prin urmare Ca intermediar ar trebui instalat în directorul certificatelor de încredere? Vă mulțumim că ați răspuns.
- Prin urmare, întrebarea dvs. este mai generală. Am ' am propus să îl închid cu un link către răspunsul pe care îl căutați.
/etc/ssl/certsdirector? Deoarece toate conțin cheile publice?