Sziasztok,
windows topicba tettem be a kérdést, mert MS plarformon érdekel a probléma megoldása, de valószínűleg ez igazából egy platform-semleges téma:
arról keresek leírást, hogy egy megfelelőn kitöltött (common name, organization, organization unit, locality, stb.) és elküldött certificate request-ben szereplő adatok közül melyek jutnak el ténylegesen is a CA-hoz a request fájlban, ezek közül a CA milyen okból ignorál(hat) bizonyos sorokat (pl. startssl szolgáltató csak a publik key-t nézi a request-ből, a common name, locality stb.-t nem) ill. ha a CA valamely paramétert önkényesen megváltoztatta, akkor az igénylőhöz visszajutó answer fájlt az igénylő szónélkül befogadja v. elutasít(hat)ja? ("én nem ilyen lovat akartam" effektus)
Techneten sok kereséssel sem találtam választ, cert-el foglalkozó MS könyvekben pedig mindenféle üzemeltetési dolgokkal fárasztanak, de igazán jó alapozó könyvet nem találtam.
- 6668 megtekintés
Hozzászólások
Nekem figyelembe vette a startcom(startssl) a csrben a cn,o,ou stb mezoket. A tanusitvanyban pontosan ugyonazok a bejegyzesek szerepelnek, mint ami a csrben voltak. Class2tol szerepel naluk a tanusitvanyban a site uzemelteto neve. Gondolom valami ingyenes cuccot krealtal naluk.
---
Apple iMac 20"
áéíóöőúüű
- A hozzászóláshoz be kell jelentkezni
Félreérthető voltam: az hogy a CA ignorál egyes sorokat, azt úgy értettem, hogy szószerint nem is foglalkozik velük!
Ignorálás=validálás és változtatás nélkül fog szerepelni a tanúsítványban, akkor amikor a válasz fájl visszaérkezik hozzám és összeáll a tanúsítvány. Miképpen lehetséges ez? Úgy hiszem azért lehetséges, mert amit én bekalapáltam: organization, org. unit, locality, stb. na ezek mind NEM is kerültek bele a .CSR-be, a CA szerver nem is kapta meg, azaz nem is validálhatta, azaz a válaszban sem szerepel semmi erre vonatkozólag, így ami belekerül a certificate-be az azok az értékek, amiket én eredetileg bekalapáltam a .CSR-be.
Konkrét példa: a Verisign-al volt egy vitám. Korábban már csináltam jópár .CSR-t más cert. szolgáltatók felé (Godaddy, Entrust, Comodo) mindegyiknél elkészítettem a request-et a lokális szerveren, azaz a wizard-nak beadtam O, OU, L, CN, és SAN (Subject Alternate Name=több DNS név 1 certificate-ben) paramétereket. Az elkészült request-et feltöltöttem a szolgáltató webes portálján, a portál a feltöltött fájlból felismerte és kiszedte a SAN neveket, és ez alapján generálta le nekem a válaszfájlt.
Namármost, a verisign supportos ember kötötte az ebet a karóhoz, hogy az képtelenség hogy én a request-be beletegyek SAN neveket! Csakis olyan request-et küldhetek neki, amiben egyetlen CN név van, és majd ŐK (verisign) teszik be a többi nevet a SAN-ba, nem veszik figyelembe a request-ben látszódó SAN értékeket. De ha ez valóban így van, akkor:
a) hogy a lótúróba nem volt ugyanez a dolog gond 4 másik egymástól fgetlen CA szolgáltatónál és
b) ez felveti a kérdést: ha a CA szolgáltató saját hatáskörében változtatgathat a kiadott tanúsítvány paramétereken, akkor a módosult válasz mekkora mértékig fogadható el az igénylő (esetünkben én, a megrendelő) oldalán?
- A hozzászóláshoz be kell jelentkezni
A csr tartalmát meg tudod tekinteni és ellenőrizni is tudod az openssl req ... paranccsal. Valahogy így:
openssl req -noout -text -in valami.csr
A kívánt információkért ezeken az oldalakon nézz körül:
https://srv.e-szigno.hu/menu/index.php?lap=szolgaltatoi_tanusitvanyok
http://www.netlock.hu/html/ssl/csr.html
- A hozzászóláshoz be kell jelentkezni
megnézem, köszi az openssl-es példát!
- A hozzászóláshoz be kell jelentkezni
Szerintem minden eljut a CA-hoz, hova máshova jutna, a teljes tanúsítványtartalomra vonatkozik a CA aláírása, náluk áll össze a végleges tanúsítvány
- A hozzászóláshoz be kell jelentkezni
Megnéztem, a SAN névlista valóban eljut a request-ben a CA szerverhez (ezen mondjuk pont nem lepődtem meg), de pl. sem az érvényességi időt nem találtam meg az openssl-es parancs kimenetében, sem a friendly name-t. Mindkettő elég jelentős része a cert-nek, meglepő h. semmi nem látszik belőlük a requestben.
Jut eszembe, a másik hülyeség amin vitatkoztam a verisign-os supportossal az az volt, h. ha Ő majd küldi nekünk vissza a válaszfájlt az általa begépelt SAN nevekkel (gyk. nem szerepeltek SAN nevek a neki kiküldött request-ben, mert Ő így követelte tőlünk), akkor a SAN névlistában NEM FOG SZEREPELNI a CN név. Namármost a SAN lista úgy működik, h. ha a kliens érzékeli a SAN jelenlétét, nem foglalkozik onnantól kezdve a CN névvel, és csak a SAN listát lesi. Ez meg azt vonja magával, hogy a CN nevet MEG KELL ISMÉTELNI a SAN listában is (akár az amúgy semmiben sem kitüntetett 1. helyen), különben a SAN-os tanúsítvány pont a Common Name-ben szereplő FQDN-re nem lesz érvényes. Szerintem ez a verisign-os
1) vagy hülye és nem ért hozzá
2) a saját szarul implementált/felépített folyamataik miatt követelte így az inputot, és a mellébeszéléssel a házuk becsületét védte
- A hozzászóláshoz be kell jelentkezni
Olyan van, ami a CSR-ben nincs benne, de a certben benne van, de ennek a fordítottját kérdezted! Nyilván a CA mondja meg, hogy meddig jó, mire használhatod, etc.
- A hozzászóláshoz be kell jelentkezni
" ha a kliens érzékeli a SAN jelenlétét, nem foglalkozik onnantól kezdve a CN névvel"
Már amelyik, futottam bele olyanba, ahol csak a CN-t nézte, SAN-ba hiába volt bent a név, visított.
Amúgy hozzáadják a SAN-hoz a CN-ben lévőt is, ha pl. domainen.hu-ra veszel sima tanusítványt, ált. a www.domainem.hu meg a domainem.hu szerepel SAN-ba.
- A hozzászóláshoz be kell jelentkezni
1. minden benne lesz a csr-ben, és eljut a ca-hoz.
2. ebből a ca eldönti, hogy mit hagy meg, ill. mit mire változtat, milyen mezőket rak be kötelezően.
3. a ca-knál általában szokott lenni egy nyilvános 'policy', ami leírja, hogy egy adott class-hoz tartozó cert kiállításánál melyik mező mit tartalmazhat, és azt hogyan validálja a ca, minden más mezőt ki szoktak dobni.
- A hozzászóláshoz be kell jelentkezni