Yritän työskennellä OpenSSL C -sovellusliittymän kanssa, olen vielä suhteellisen uusi kaikessa tässä ja löydän siellä paljon sekoitettua tietoa, joten mielestäni on viisasta pyytää ideoita / mielipiteitä / selvennyksiä.
Asiakasohjelma vaatii joka tapauksessa varmenteen tai hakemiston lataamisen, joka sisältää ”TrustStore”. Onko tämä vain toinen merkitys palvelimen CA-varmenne itsessään siinä tapauksessa, että luon omat SSL-varmenteet kyseiselle palvelimelle?
Ja jos on, toimiiko välivarmentaja tätä tarkoitusta varten korvaamalla juurivarmentajan?
Luulen olevani oikealla tiellä. Halusin kuitenkin vain jonkin verran selvennystä estääkseen itseäni tekemästä todellista hämärää virhettä, koska olen kuullut asiasta ristiriitaisia tietoja. Jotkut sanovat, että asiakas tarvitsee itse juurivarmentajan; muiden lähteiden mukaan he asentavat vain välitodistuksen varmentajan turvallisuussyistä, mikä vaikuttaa loogiselta.
Olen kuitenkin yleensä hieman hämmentynyt siitä, miten luottamusketju toimii asiakassuhteen suhteen. Olen tosiasiassa tarvinnut vain luoda CSR: n ja asentaa varmenteen verkkopalvelimeen, joten asiakaspuolen asiat ovat minulle melko uusia.
Tämä kysymys esitettiin alun perin täällä Stack Overflow -ohjelmassa ehdotettiin, että kysyisin info-sec-yhteisöltä.
Kommentit
- Luulen, että käytät väärää ilmausta: itse allekirjoittama varmenne on varmenne, jossa liikkeeseenlaskijan varmenne on itse varmenne. Luultavasti tarkoittaa varmentetta, jonka sen sijaan on allekirjoittanut oma varmentajasi.Tässä tapauksessa: juurivarmentaja asetetaan yleensä luottamuskaupaan ja juurivarmentajan allekirjoittama välivarmente ja välivarmenteen allekirjoittama lehti-varmenne lähetetään TLS-kädenpuristuksen aikana .
- Mahdollinen kopio sivusta Miten SSL / TLS PKI toimii?
Vastaa
tl; dr Jos sertti sisältää jonkin verran muunnelmaa CA:TRUE, on järkevää jakaa se, jos ei, ei ole mitään hyötyä sen jakamisesta.
Itse luottoketju voidaan selittää sertifikaattirakenteella.
Jos aloitamme palvelimesi sertifikaatista (ts. varmenne, jota yleensä käytät apache-sovelluksessa):
- palvelinsertifikaatti luodaan varmenteen myöntäjän antaman CSR: n perusteella. Että CSR sisältää julkisen avaimesi ja joitain muita tietoja, joita CA voi olla kiinnostunut käyttämästä.
- varmentaja vastaanottaa CSR: si ja (yleensä) luo allekirjoitetun varmenteen käyttämällä välitodistusta. Sertifikaatissasi on kaksi julkista avainta: yksi aihetta varten (joka on CSR: stä otettu julkinen avain) ja toinen myöntäneelle osapuolelle, joka on varmentajan välitodistus.
- varmentaja Välitodistus on itse allekirjoitettu varmenne (jossa on joitain erityisvaihtoehtoja), jossa aihe-avain on välivarmentajan julkinen avain (joka on sama julkinen avain kuin palvelimesi varmenteen myöntäjän julkisessa avaimessa). allekirjoitus (tai myöntäminen) avain on varmentajan juurivarmente (vaihtoehtoisesti se on toinen välituote).
- CA: n juurivarmenne on (yleensä) itse allekirjoitettu varmenne. Käytännössä tämä tarkoittaa, että myöntäjä- ja aihe-avaimet ovat sama julkinen avain.
Näet tämän tarkistamalla varmenteet luonnossa, esimerkiksi:
$ 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 Tämän rakentaman luottamusketjun voi tiivistää seuraavasti (aloitan ” bottom ”- Equifax-sertifikaatti):
- juurivarmentaja (Equifax) delegoi päivittäiset toiminnot välivarmentajalle (GeoTrust) ja allekirjoittaa tätä varmenteen edustavan varmenteen (ts. varmentajan asettaminen: TOSI, KeyUsage: keyCertSign). Toisin sanoen juurivarmentaja ”luottaa” välituotteeseen myöntää varmenteita sen puolesta (toivottavasti suoritettuaan joukon pakollisia validointivaiheita).
- tässä ketjussa välituote (Geotrust) on edelleen delegoinut Googlen CA: lle (CN = Google Internet Authority G2).
- Edustaja (alias Google välitön CA) allekirjoittaa sitten CSR: n, joka tosiasiallisesti on asiakirja, joka ilmoittaa tietylle tietylle joukko nimiä (t CN ja mahdollisesti Subject Alternative Names), yksityisen / julkisen avaimen pari on kelvollinen / luotettava (luottamus tulee tästä siitä, että he ovat vahvistaneet vaatimuksen puhua tietyn nimen puolesta – tässä tapauksessa Google CA on myöntänyt * .google.com -sertifikaatti).
Huomaa, että (pää) varmentajat ovat yleensä itse allekirjoittaneet – varmentajaan luotetaan yleensä, koska se noudattaa joukkoa prosesseja ja menettelyjä, joiden katsotaan varmistavan, ettei se myönnä varmenteita ihmisille kenellä ei pitäisi olla niitä. Siksi en voi mennä ulos hakemaan itselleni todistusta, jonka mukaan olen google.Tämä on siis eräänlainen käytäntö (vaikkakin muodollisilla mekanismeilla tuettu), ja jos aloitat oman varmentajan, sen juuri- (ja väli) varmenteiden jakaminen saavuttaa täsmälleen saman asian kuin muiden varmentajien varmenteiden jakaminen: se antaa myönnetyt varmenteet että CA hyväksyy järjestelmän päteväksi (ts. luotettavaksi).
Käytännöllisemmin sanottuna trust store (openSSL: lle) on melkein joukko tiedostoja, joilla on tietty nimeämiskäytäntö. Katso https://www.openssl.org/docs/faq.html#USER5 :
Milloin varmenne on vahvistettu, että OpenSSL: n on luotettava sen juurivarmentajaan. Tämä tarkoittaa yleensä, että varmentajan varmenne on sijoitettava hakemistoon tai tiedostoon ja asianmukainen ohjelma on määritettävä lukemaan sitä
Tämä hakemisto on / etc / ssl / certs (RH-tykkäyksissä on muita, kuten / etc / pki).
https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 tarjoaa lisää yleiskuvan siitä, miten varmenne lisätään kauppaan, kuten tekee https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,
Lyhyt versio on, että update-ca-sertifikaatit automatisoi prosessin ja on yleisesti käytetty työkalu.
Hieman pidempi versio on, että sertifikaatit on tallennettava hashilla (esim. tiedostoihin, joiden nimi on openssl x509 -hash -in cert.pem -lähdössä), jotta openSSL voi vahvistaa ketjut tehokkaasti.
Katso https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html lisää taustaa varten.
päivitetty vastaamaan kommenteissa oleviin kysymyksiin:
Palvelimen varmenne , tässä keskustelussa määritellään luotetuksi tai ei sen luottamusketjun perusteella. Jos ajattelet kuinka (esim.) curl https://google.com toimii, se on hieman helpompi ymmärtää:
- curl avaa TLS-yhteyden Googleen, joka palauttaa varmenne.
- curl tarkastelee kyseistä ”loppukäyttäjän” varmentetta – eli palvelimen varmentetta – ja etsii nimenomaan liikkeeseenlaskijaa.
- jos liikkeeseenlaskija on ”tunnettu” luottamuskaupan loppuosa luottoketjusta tarkistetaan (ts. palvelinvarmenteen myöntäjän varmenne tarkistetaan ja jos sillä on muu liikkeeseenlaskija kuin itse, kyseinen myöntäjä tarkistetaan jne.). Varsinkin jos koko luottamusketju voidaan vahvistaa, varmenne katsotaan kelvolliseksi.
Luottoketjujen jakaminen olisi kuitenkin ehdottomasti epäkäytännöllistä, jos loppukäyttäjän varmenteet olisi sisällytettävä. Minulla ei ole numeroita siitä, kuinka monta verkkosivustoa siellä on, mutta sen perusteella, että Alexa tarjoaa 1 miljoonan parhaan, oletat, että se on yli miljoona.
Mikä on tavallaan luottamusketju: sinulla on yleensä oltava liikkeeseenlaskijan varmenteet, mutta et tarvitse lopullisten varmenteiden jakamista, koska ne kertovat sinulle, kuka liikkeeseenlaskija on.
Ja voit tarkistaa, etteivät ne ole ” t valehtelee, koska voit tarkistaa liikkeeseenlaskijoiden julkisen avaimen (ja luottamusketjun, joka vahvistaa, että se on oikea avain), ja tarkistaa, onko loppukäyttäjän (eli palvelimen) varmenne todella allekirjoittanut liikkeeseenlaskijan yksityisen vastapuolen. julkinen avain.
Joten ei, sinun ei tule jakaa loppukäyttäjän varmenteita, vaan vain luottamusketju – tai yksinkertaisemmin sanottuna: jaa kaikki luomasi sertifikaatit missä BasicConstraints (oikeutetusti) kertoo ainakin CA: TOSI. Älä jaa mitään, joka ei täytä tätä ehtoa, koska se on aikaa ja levytilan tuhlausta – kaikki, mitä ei sano CA: TOSI, voidaan vahvistaa mihinkään, mikä tekee.
Kommentit
Answer
Itse allekirjoittama varmenne on täsmälleen seuraava: se on allekirjoitti itseni (se on oma luottamusankkuri).
Siksi luotettavuus edellyttää, että se sijoitetaan manuaalisesti ja nimenomaisesti sovelluksen luotettavien ankkureiden luetteloon. Kuinka se tehdään, riippuu käyttöjärjestelmästä ja sovelluksesta.
Jos esimerkiksi käytät Windowsin sisäistä varmennetallennustilaa, sinun on sijoitettava kyseinen itse allekirjoittama varmenne luotetun päävarmenneviranomaisen varastoon, muuten varmenteita ei hyväksytä. OpenSSL käyttää erilaista, sovelluskohtaista tallennusjärjestelmää: sinun on asennettava varmenne myös luotettavana varmentajana, mutta miten se tehdään, riippuu suuresti siitä, mitä sovellusta ja käyttöjärjestelmää käytät (katso tämä artikkeli joillekin yleisohjeille).
Kommentit
- Tarkoittaako tämä siis " Trust Store " -sertifikaatti on aivan sama kuin esimerkiksi apacheen asennettu? Tämä ' s eniten hämmentävä osa, i ' ma
GNU/Linux-käyttäjä, jonka hakemiston minun piti linkittää asiakassovelluksessa, oli/etc/ssl/certs. En kuitenkaan löytänyt selkeää selitystä siitä, mikä prosessi tarkalleen on asian toisella puolella. Ainakin ymmärrät kysymykseni täällä, tärkein asia sen takana on kirjoittaa asiakkaan luotettavaksi palvelimeen, johon se muodostaa yhteyden. - Mitä minä ' m yrittää tehdä tarkalleen on luoda varmentaja, ja luulen varmenteen allekirjoittaneen varmentaja (välituote), joten tarkoittaakö tämä siinä tapauksessa, että varmentaja on luottamusankkuri väli Ca tulisi asentaa luotettujen varmenteiden hakemistoon? Kiitos vastauksestasi.
- Kysymyksesi on siis yleisempi. Olen ' ehdottanut sen sulkemista linkillä etsimääsi vastaukseen.
/etc/ssl/certshakemisto? Koska nämä kaikki sisältävät julkisia avaimia?