Jeg prøver å jobbe med OpenSSL C API, jeg er relativt ny for alt dette fremdeles, og jeg finner mye blandet informasjon der ute, så jeg tror det er lurt å be om ideer / meninger / avklaring.
Uansett krever klientprogrammet et sertifikat eller katalog som skal lastes inn som inneholder en «TrustStore». Er dette bare en annen betydning for serverens CA-sertifikat i tilfelle jeg oppretter mine egne SSL-sertifikater for serveren?
Og i så fall vil den mellomliggende CA fungere for dette formålet med erstatning av root CA?
Jeg tror jeg er på rett vei. Imidlertid ville jeg bare ha en avklaring for å forhindre at jeg gjør noen reelle feil, siden jeg har hørt litt motstridende informasjon om dette. Noen sier at klienten trenger selve roten CA; andre kilder sier at de bare installerer mellomliggende CA for sikkerhetsmessige grunner, noe som virker logisk.
Jeg er generelt litt forvirret over hvordan tillitskjeden fungerer i forhold til en klientforbindelse. Jeg har faktisk bare trengt å generere en CSR og installere et sertifikat på webserveren, så klientsiden er ganske ny for meg.
Dette spørsmålet ble opprinnelig spurt her på Stack Overflow ble det foreslått at jeg spør info-sec-fellesskapet.
Kommentarer
- Jeg tror du bruker feil uttrykk: et selvsignert sertifikat er et sertifikat der utstedersertifikatet er selve sertifikatet. betyr et sertifikat som er signert av din egen CA i stedet. I dette tilfellet: rot-CA blir vanligvis lagt inn i tillitsbutikken og mellomsertifikatet signert av rot-CA og bladsertifikatet signert av det mellomliggende sertifikatet blir sendt under TLS-håndtrykk. .
- Mulig duplikat av Hvordan fungerer SSL / TLS PKI?
Svar
tl; dr Hvis sertifikatet inneholder en eller annen variasjon av CA:TRUE, er det fornuftig å distribuere det, hvis det ikke gjør det, er det ingen fordel å distribuere det.
Selve tillitskjeden kan forklares ut fra sertifikatstrukturen.
Hvis vi starter fra serverens cert (dvs. sertifikatet du vanligvis bruker for apache):
- servercertifikatet ditt genereres av en sertifikatmyndighet, basert på en CSR du oppgir. At CSR inneholder den offentlige nøkkelen din, og annen informasjon CA kan eller ikke er interessert i å bruke.
- CA mottar din CSR, og vil (generelt) opprette et signert sertifikat ved hjelp av en mellomliggende CA. Sertifikatet ditt vil ha to offentlige nøkler: en for emnet (som er den offentlige nøkkelen hentet fra din CSR), og en for den utstedende parten, som er CAs mellomliggende sertifikat.
- CAen mellomliggende sertifikat er i seg selv et signert sertifikat (med noen spesielle alternativer), der emnøkkelen vil være den mellomliggende CA-enes offentlige nøkkel (som er den samme offentlige nøkkelen som finnes i utstederens offentlige nøkkel til serversertifikatet). signeringsnøkkel (eller utstedelse) vil være CAs rotsertifikat (alternativt vil det være et annet mellomledd).
- CAets rotsertifikat er (generelt) et selvsignert sertifikat. I praksis betyr dette at utsteder- og emne-nøklene er den samme offentlige nøkkelen.
Du kan se dette ved å sjekke sertifikater i naturen, f.eks:
$ 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 Den tillitskjeden dette bygger kan oppsummeres som (jeg starter fra » bottom «- Equifax cert):
- roten CA (Equifax) delegerer daglige aktiviteter til en mellomliggende CA (GeoTrust) og signerer et sertifikat som representerer dette faktum (dvs. innstilling CA: SANN, KeyUsage: keyCertSign). Med andre ord «stoler» roten mellomproduktet for å utstede sertifikater på dets vegne (forhåpentligvis etter å ha fullført en rekke obligatoriske valideringstrinn).
- i denne kjeden, det mellomliggende (Geotrust) har videre delegert til en Google CA (CN = Google Internet Authority G2).
- delegaten (også kjent som den mellomliggende Google) signerer deretter en CSR, som faktisk er et dokument som sier at for en gitt sett med navn (t CN, og muligens Subject Alternative Names), er et privat / offentlig nøkkelpar gyldig / klarert (tilliten her kommer fra at de har validert kravet om å snakke for et gitt navn – i dette tilfellet har Google CA utstedt en sertifikat for * .google.com).
Vær oppmerksom på at (rot) CAer generelt er selvsignerte – en CA er klarert generelt fordi den overholder et sett med prosesser og prosedyrer som føltes for å sikre at den ikke utsteder sertifikater til folk som ikke skulle ha dem. Det er derfor jeg ikke kan gå ut og skaffe meg et sertifikat som sier at jeg er google.Dette er derfor en slags konvensjon (om enn en støttet av formelle mekanismer), og hvis du starter din egen CA, oppnår distribusjon av rotsertifikater (og mellomliggende) sertifikater nøyaktig det samme som å distribuere certs fra andre CAer: det gjør at sertifikater utstedes av at CA blir akseptert som gyldig (dvs. pålitelig) av systemet.
I mer praktiske termer er tillitsbutikken (for openSSL) ganske mye en haug med filer med en spesifikk navnekonvensjon. Se https://www.openssl.org/docs/faq.html#USER5 :
Når et sertifikat er bekreftet at dets rot-CA må være «klarert» av OpenSSL, dette betyr vanligvis at CA-sertifikatet må plasseres i en katalog eller fil og det relevante programmet er konfigurert til å lese det
Den katalogen er / etc / ssl / certs (det er andre, for eksempel / etc / pki på RH-likes).
https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 gir litt videre oversikt over hvordan man legger til et sertifikat i butikken, som gjør https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,
Den korte versjonen er at update-ca-Certificate automatiserer prosessen, og er det ofte brukte verktøyet.
Den litt lengre versjonen er at sertifikater må lagres med hash (f.eks. i filer navngitt basert på utdata fra openssl x509 -hash -in cert.pem), slik at openSSL effektivt kan validere kjeder.
Se https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html for litt ekstra bakgrunn.
oppdatert for å svare på spørsmålene i kommentarer:
Serversertifikatet , i denne diskusjonen, er definert som klarert eller ikke basert på kjeden av tillit. Hvis du tenker på hvordan (f.eks.) curl https://google.com fungerer, er det litt lettere å forstå:
- curl åpner en TLS-forbindelse til google, som returnerer et sertifikat.
- krøller ser på «sluttbruker» -sertifikatet – dvs. serverens sertifikat, og ser spesielt etter utstederen.
- hvis utstederen er «kjent» i tillitsbutikken, blir resten av tillitskjeden validert (dvs. at sertifikatutstedersertifikatet er sjekket, og hvis det har en annen utsteder enn seg selv, blir den utstederen sjekket osv.). Bare hvis hele tillitskjeden kan valideres, anses sertifikatet som gyldig.
Det ville imidlertid være absolutt upraktisk å distribuere tillitskjeder hvis sluttbrukersertifikater måtte inkluderes. Jeg har ikke noen tall på hvor mange nettsteder som er der ute, men basert på det faktum at Alexa gir en topp 1M, vil du anta at det er mer enn 1 million.
Hvilket er liksom poenget med en tillitskjede: du trenger vanligvis å ha utstedersertifikatene, men du trenger ikke at sluttsertifikatene distribueres, fordi de forteller deg hvem utstederen er.
Og du kan bekrefte at de ikke er » ikke lyver, fordi du kan sjekke utstederens offentlige nøkkel (og tillitskjeden som fastslår at den er riktig nøkkel), og validere om sluttbrukerens (dvs. server) sertifikat virkelig ble signert av den private motparten til utstederens offentlig nøkkel.
Så nei, du bør ikke distribuere sluttbrukercertene, men bare kjeden av tillit – eller, i enklere ord: distribuere alle certsene du genererer der BasicConstraints (legitimt) sier noe i det minste CA: SANT. Ikke distribuer noe som ikke oppfyller den betingelsen, fordi det er bortkastet tid og diskplass. – alt som ikke sier CA: TRUE kan valideres mot noe som gjør det.
Kommentarer
Svar
Et selvsignert sertifikat er akkurat det: det er signerte meg selv (det er sitt eget tillitsanker).
Derfor, for å være klarert, må den plasseres manuelt og eksplisitt i programmets pålitelige ankerliste. Hvordan det gjøres, avhenger av operativsystemet og applikasjonen.
Hvis du for eksempel bruker Windows interne sertifikatlagring, må du plassere det selvsignerte sertifikatet i «klarert rotsertifikatmyndighet» -lager, ellers vil ikke sertifikatet godtas. OpenSSL bruker et annet, applikasjonsspesifikt lagringssystem: du må installere sertifikatet som en klarert CA, men hvordan du gjør det, avhenger mye av nøyaktig hvilket program og operativsystem du bruker (se denne artikkelen for noen generelle instruksjoner.
Kommentarer
- Så betyr dette " Trust Store " sertifikat er akkurat det samme som for eksempel installert i apache? At ' s den delen som er mest forvirrende, jeg ' ma
GNU/Linuxbruker, katalogen jeg trengte å koble til i klientprogrammet, var/etc/ssl/certs. Men jeg klarte ikke å finne en klar forklaring på hva prosessen er akkurat på den siden av tingene. I det minste forstår du spørsmålet mitt her, hovedpoenget bak det er å skrive klienten og få den til å stole på serveren den kobler til. - Hva jeg ' Når jeg prøver å gjøre nøyaktig, er det å opprette en CA, og jeg antar at sertifikatet er signert av CA (mellomliggende), så betyr det i så fall at CA er tillitsanker, derfor den mellomliggende Ca skal installeres i den klarerte sertifikatkatalogen? Takk for at du svarte.
- Spørsmålet ditt er derfor mer generelt. Jeg ' har foreslått å lukke den med en lenke til svaret du søker.
/etc/ssl/certskatalog? Ettersom disse alle inneholder de offentlige nøklene?