Igyekszem az OpenSSL C API-val dolgozni, viszonylag új vagyok még ebben az egészben, és sok vegyes információt találok odakinn, ezért azt gondolom, hogy bölcs ötleteket / véleményeket / magyarázatot kérni.
Mindenesetre az ügyfélprogram tanúsítványt vagy könyvtárat igényel, amely tartalmaz egy “TrustStore” -t. Ez csak egy másik jelentése a Maga a szerver CA tanúsítványa abban az esetben, ha saját SSL tanúsítványokat hozok létre az említett szerver számára?
És ha igen, akkor a közbenső hitelesítésszolgáltató erre a célra működik-e a root CA cseréjében?
Azt hiszem, jó úton járok. Mindazonáltal csak némi tisztázást akartam, hogy megakadályozzam magam abban, hogy valódi hibát kövessek el, mivel ellentmondásos információkat hallottam ezzel kapcsolatban. Egyesek szerint az ügyfélnek magának a root CA-ra van szüksége, más források szerint csak köztes CA-t telepítenek biztonsági okokból, ami logikusnak tűnik.
Általában kissé zavart vagyok abban, hogy a bizalmi lánc hogyan működik az ügyfélkapcsolat tekintetében. Valójában csak CSR-re volt szükségem és tanúsítványt kellett telepítenem a webkiszolgálóra, így az ügyféloldali dolgok számomra újdonságok.
Ezt a kérdést eredetileg feltették itt a Verem túlcsordulásánál azt javasolták, hogy kérdezzem meg az info-sec közösséget.
Megjegyzések
- Úgy gondolom, hogy nem megfelelő kifejezést használ: a önaláírt tanúsítvány olyan tanúsítvány, ahol a kibocsátó tanúsítvány maga a tanúsítvány. Valószínűleg olyan tanúsítványt jelent, amelyet inkább a saját hitelesítésszolgáltató írt alá. Ebben az esetben: a gyökér hitelesítésszolgáltatót általában a bizalmi tárolóba helyezik, és a gyökér-hitelesítésszolgáltató által aláírt köztes tanúsítványt és a köztes tanúsítvánnyal aláírt levéltanúsítványt elküldik a TLS kézfogás során. .
- A lehetséges másolata Hogyan működik az SSL / TLS PKI?
Válasz
tl; dr Ha a cert tartalmaz néhány variációt a CA:TRUE -ről, akkor van értelme terjeszteni, ha nem, akkor nincs előnye annak terjesztésének.
Maga a bizalmi lánc a tanúsítványszerkezettel magyarázható.
Ha a kiszolgálójának certjéből indulunk ki (pl. az a cert, amelyet általában az apache-hoz használna):
- a szerver tanúsítványt egy tanúsító hatóság állítja elő az Ön által megadott CSR alapján. Ez a CSR tartalmazza az Ön nyilvános kulcsát, és néhány egyéb információt, amelyet a CA felhasználhat.
- A CA megkapja az Ön CSR-jét, és (általában) létrehoz egy aláírt tanúsítványt egy köztes CA használatával. A tanúsítványának két nyilvános kulcsa lesz: egy a tárgyhoz (amely a CSR-ből kivont nyilvános kulcs), és egy a kiállító fél számára, amely a CA közbenső tanúsítványa.
- a CA ” A köztes tanúsítvány maga is egy aláírt tanúsítvány (néhány speciális opcióval), ahol a tárgykulcs a köztes CA nyilvános kulcsa lesz (amely megegyezik a szerver tanúsítványának Kibocsátó nyilvános kulcsában található nyilvános kulccsal). az aláíró (vagy kibocsátó) kulcs lesz a CA gyökértanúsítványa (alternatív megoldásként ez egy másik köztes dokumentum is lehet).
- A CA gyökértanúsítványa (általában) önaláírt tanúsítvány. A gyakorlatban ez azt jelenti, hogy a Kibocsátó és a Tárgy kulcsok ugyanazok a nyilvános kulcsok.
Ezt megnézheti a tanúsítványok vadonban történő ellenőrzésével, például:
$ 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 Az általunk létrehozott bizalmi lánc összefoglalható (kezdem a ” bottom “- az Equifax cert):
- a gyökér CA (Equifax) átruházza a napi tevékenységeket egy közbenső CA-ra (GeoTrust), és aláírja ezt a tényt képviselő tanúsítványt (azaz beállítja a CA-t: IGAZ, KeyUsage: keyCertSign). Más szavakkal, a gyökér CA “bízik” a köztesben, hogy igazolásokat bocsásson ki a nevében (remélhetőleg a kötelező érvényességi lépések sorozatának elvégzése után).
- ebben a láncban a köztes (Geotrust) tovább delegálta egy Google CA-t (CN = Google Internet Authority G2).
- a megbízott (más néven a Google közbenső CA) ezután aláír egy CSR-t, amely gyakorlatilag egy dokumentum, amely azt állítja, hogy egy adott adott esetben névsor (t CN, és esetleg Subject Alternative Names), egy magán / nyilvános kulcspár érvényes / megbízható (a bizalom abból adódik, hogy érvényesítették az állítást, hogy egy adott néven beszéljenek – ebben az esetben a Google CA kiadott egy tanúsítvány a * .google.com címhez).
Ne feledje, hogy a (root) hitelesítésszolgáltatók általában saját aláírással rendelkeznek – a hitelesítésszolgáltatók általában megbízhatóak, mert betartják azokat a folyamatokat és eljárásokat, amelyek úgy érzik, hogy nem adnak ki tanúsítványokat az emberek számára akinek nem kellene. Ezért nem tudok kimenni és megszerezni magamnak egy igazolást, miszerint google vagyok.Ez tehát egyfajta egyezmény (igaz, formális mechanizmusokkal alátámasztott), és ha saját CA-t alapít, a gyökér (és köztes) tanúsítványainak terjesztésével pontosan ugyanazt érjük el, mint más CA-k tanúsítványainak terjesztésénél: kiadja a tanúsítványokat hogy a CA érvényesnek (azaz megbízhatónak) fogadja el a rendszer.
Gyakorlatiasabban kifejezve a trust store (az openSSL számára) nagyjából egy halom fájl, amelyeknek van egy konkrét elnevezési szokása. Lásd: https://www.openssl.org/docs/faq.html#USER5 :
Mikor egy tanúsítvány ellenőrzése megtörtént, az OpenSSL-nek a “megbízhatónak” kell lennie a gyökér CA-ban, ez általában azt jelenti, hogy a CA tanúsítványt könyvtárba vagy fájlba kell helyezni, és a megfelelő programot be kell állítani az olvasásra
Ez a könyvtár az / etc / ssl / certs (vannak olyanok is, mint például az / etc / pki az RH-kedveléseknél).
https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 további áttekintést nyújt arról, hogy az ember hogyan ad hozzá tanúsítványt az áruházhoz, mivel https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,
A rövid verzió az, hogy update-ca-tanúsítványok automatizálja a folyamatot, és ez az általánosan használt eszköz.
A valamivel hosszabb verzió az, hogy a tanúsítványokat hash-sel kell tárolni (pl. openssl x509 -hash -in cert.pem) kimenetén, így az openSSL hatékonyan tudja ellenőrizni a láncokat.
Lásd: https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html további háttérrel.
frissítette a alkalmazást, hogy válaszoljon a megjegyzésekben feltett kérdésekre:
A szerver tanúsítványa , ebben a megbeszélésben megbízhatóként vagy nem a bizalmi láncolatán alapul. Ha belegondol az (pl) curl https://google.com működésébe, egy kicsit könnyebb megérteni:
- a curl TLS kapcsolatot nyit meg a google-val, amely visszatér tanúsítvány.
- a curl megnézi azt a „végfelhasználói” tanúsítványt – azaz a szerver tanúsítványát -, és kifejezetten a kibocsátót keresi.
- ha a kibocsátó „ismert” a a bizalmi tár, a megbízhatósági lánc fennmaradó része érvényesül (azaz a kiszolgálói tanúsítvány kibocsátójának tanúsítványa be van jelölve, és ha ennek nem saját kibocsátója van, akkor ez a kibocsátó be van jelölve stb.). Csak akkor tekinthető érvényesnek a tanúsítvány, ha a teljes megbízhatósági lánc érvényesíthető.
Azonban abszolút célszerűtlen lenne megbízhatósági láncokat terjeszteni, ha a végfelhasználói tanúsítványokat be kellene vonni. Nincs számom arról, hogy hány webhely van odakint, de azon a tényen alapulva, hogy az Alexa 1 millió legjobbat ad, feltételezhetjük, hogy ez meghaladja az 1 milliót.
Ami pont a lényeg bizalmi lánc: általában rendelkeznie kell a kibocsátói tanúsítványokkal, de nem szükséges a végtanúsítványok terjesztése, mert ezek megmondják, hogy ki a kibocsátó.
És ellenőrizheti, hogy vannak-e ” nem hazudik, mert ellenőrizheti a kibocsátók nyilvános kulcsát (és a megbízhatósági láncot, amely megállapítja, hogy ez a megfelelő kulcs), és ellenőrizheti, hogy a végfelhasználói (azaz szerver) tanúsítványt valóban a kibocsátó privát partnere írta-e alá. nyilvános kulcs.
Tehát nem, nem a végfelhasználói tanúsítványokat szabad terjesztenie, hanem csak a bizalom láncolatát – vagy, egyszerűbben fogalmazva: terjessze az összes t a létrehozott tanúsítványokhoz a BasicConstraints (jogosan) mond valamit legalább CA-ról: IGAZ. Ne terjesszen olyan dolgokat, amelyek nem felelnek meg ennek a feltételnek, mert ez az idő és a lemezterület pazarlása – minden, ami nem mondja CA: IGAZ, érvényesíthető valamivel szemben.
Megjegyzések
Válasz
Az önaláírt tanúsítvány pontosan az: aláírta magát (ez a saját bizalmi horgonya).
Ezért a megbízhatóság érdekében kézzel és kifejezetten az alkalmazás megbízható horgonyok listájára kell helyezni. Ennek végrehajtása az operációs rendszertől és az alkalmazástól függ.
Például, ha a Windows belső tanúsítványtárolóját használja, akkor az önaláírt tanúsítványt el kell helyeznie a “megbízható gyökértanúsító hatóság” tárolóba, különben a tanúsítványt nem fogadják el. Az OpenSSL egy másik, alkalmazás-specifikus tárolórendszert használ: a tanúsítványt megbízható hitelesítésszolgáltatóként is telepítenie kell, de ennek módja nagyban függ attól, hogy pontosan milyen alkalmazást és operációs rendszert használ (lásd: ez a cikk néhány általános utasításhoz).
Megjegyzések
- Tehát ez azt jelenti, hogy a " Trust Store " tanúsítvány pontosan ugyanaz, mint például az apache-ba telepített? Ez ' s az a rész, ami a legzavaróbb, i ' ma
GNU/Linuxfelhasználó, amelynek könyvtárához csatolnom kellett az ügyfélalkalmazásban/etc/ssl/certs. De nem tudtam egyértelmű magyarázatot találni arra, hogy mi is pontosan a folyamat a dolgok ezen az oldalán. Itt legalább megérted a kérdésemet, a lényeg az írás mögött az ügyfél és megbízzon abban a kiszolgálóban, amelyhez csatlakozik. - Mit i ' Ha pontosan meg akarom csinálni, CA-t kell létrehozni, és gondolom, hogy a tanúsítványt a CA (köztes) írja alá, tehát ebben az esetben ez azt jelenti, hogy a CA a megbízhatósági horgony, ezért a közbenső Ca-t telepíteni kell a megbízható tanúsítványok könyvtárába? Köszönjük, hogy válaszolt.
- Kérdése tehát általánosabb. ' azt javasoltam, hogy zárjam be egy linkkel a keresett válaszra.
/etc/ssl/certskönyvtár? Mivel ezek mind tartalmazzák a nyilvános kulcsokat?