Kezdőlap > PKI > Tanúsítvány exportálása – 1. rész

Tanúsítvány exportálása – 1. rész


Next-next-finish 🙂 De tényleg. Hogy akkor mégis miért született meg ez a cikk*? Nos, ahhoz, hogy tényleg ennyire könnyen menjenek a dolgok, néhány feltétel (és megfelelő csillag-állás) szükséges.

*: eredetileg egy cikk volt, a terjedelme miatt vágtam ketté

Addig általában nincs baj, amíg egy egyszerű exportot akarunk. Ha viszont már privát-kulcsot is tartalmazó állományt szeretnénk kapni, máris kezdődnek a bonyodalmak.

Elmélet

Kezdjük szokás szerint az elmélettel. A privát kulcsot a CA nem tárolja (alapértelmezés szerint), hanem azon a számítógépen található meg, ahonnan a kérelmet indítottuk. Hogy ezt megértsük, nézzük, mi történik – nagy vonalakban – egy tanúsítvány igénylésekor.

Tételezzük fel, hogy egy új kulcs-párt (privát, publikus) tartalmazó tanúsítványt igénylünk (vagyis nem egy létező tanúsítvány megújítását akarjuk). Ekkor az operációs rendszerünk elkészíti a publikus és privát kulcsokat, majd a privát kulcsot letárolja a kulcs-tárolóba (a kulcs tulajdonságaival – például a privát kulcs exportálhatóságával – együtt). Hogy ez helyileg hol található, függ a sablonban beállított Cryptographic Service Provider (CSP) vagy Key Storage Provider (KSP)-től. Ez utóbbiak Windows Vista/Server 2008 óta léteznek, a v3 típusú sablonoktól kezdve (sablonokról itt írtam). Az alapértelmezett Microsoft CSP/KSP-k esetén (a SmartCard-ok által használtakat kivéve), a kulcs-tároló a felhasználó profiljában, számítógép-tanúsítványok esetén az All users profilban található:

Felhasználó: %AppData%\Microsoft\Crypto\RSA\SID

Számítógép: %AllUsersProfile%\Microsoft\Crypto\RSA\MachineKeys

Amint megvan a kulcs-párunk, elkészül a tanúsítványon megtalálható adatokkal kitöltött, valamint a nyilvános kulccsal megspékelt kérés, amely a most létrehozott privát kulccsal van aláírva. Ezeket az adatokat a sablon adja meg, a Tárgy (Subject) mezőt kivéve, amelyik az igénylő Common Name/Distinguished Name attribútumát tartalmazza, IIS esetén ez az oldal neve. Az oprendszer létrehoz egy ideiglenes tanúsítvány-objektumot a Certificate Enrollment Requests tárolóban, ezzel is jelezve, hogy folyamatban van egy igény.

Attól függően, hogy miként indítottuk, a kérés mentésre vagy egy online CA kiszolgálóhoz kerül. Fontos tudni, hogy alapértelmezetten a privát kulcs nem kerül küldésre, ez alól kivétel, ha engedélyeztük a Key Archival funkciót és a sablon beállításai igénylik a privát kulcs CA-adatbázisában történő mentését. Ebben az esetben a gép elkéri a tanúsítvány-kiszolgáló CA Exchange tanúsítványát, majd ennek publikus kulcsával kódolja az újonnan generált privát kulcsot, s ez kerül a kérésbe.

Amint a CA megkapja a kérést, feldolgozza azt, ellenőrizve, hogy kiállíthat-e tanúsítványt, például egy Enterprise CA esetén a sablon jogosultságai alapján, vagy bizonyos esetekben beállítható a sablonban egy CA-kezelő engedélyezési hozzájárulása. Feltételezve, hogy a kérésben minden helyes, valamint minden szükséges (sablonban igényelt) információ kiolvasható az AD-ból (pl. felhasználó email-címe, számítógép DNS-neve), szükség szerint az engedélyek is megvannak, a CA előállítja a tanúsítványt és saját privát kulcsával aláírja.

Ezt a tanúsítvány letárolja a helyi CA adatbázisba is. Amennyiben a kérésbe volt csomagolva a titkosított privát kulcs is, a CA visszafejti saját CA Exchange privát kulcsával, majd újra titkosítja a CA-n beállított Key Recovery Agents ügynök(ök) nyilvános kulcsával/kulcsaival, majd ezt is letárolja (ezáltal innen csak egy érvényes ügynök tudja kiolvasni).

A CA ezután kérés szerint kiszolgáltatja a tanúsítványt. Amennyiben a kérés előbb állományba volt mentve, majd úgy átadva a kiszolgálónak, úgy szintén kézi úton tudjuk megkapni. Amennyiben mmc-konzolon, vagy megfelelő alkalmazáson (pl. egy Web-kiszolgáló tanúsítványa esetén az IIS) keresztül igényeltük, úgy automatikusan annak adja vissza.

Miután a kliens megkapja a tanúsítványt, rákeres az ideiglenes tanúsítvány-objektumra a Certificate Enrollment Requests tárolóban, ebből kiolvassa a számára szükséges adatokat (pl. privát kulcs tárolójának helyét), majd törli. Az új tanúsítványt beteszi a Személyes tárolóba, majd a privát kulcsra vonatkozó információt egy (a tárolóban használt) belső tulajdonságba teszi be, ennek alapján fogja tudni azonosítani a hozzá tartozó privát kulcsot.

Amikor egy Pfx-et exportálunk, a gépünk a tanúsítványnak az előzőekben említett tulajdonságát olvassa ki, hogy tudja, melyik kulcs-tárolóban találja a privát kulcsot. Hogy ez a gyakorlatban miként történik, hamarosan 🙂

Reklámok
Kategóriák:PKI Címke: ,
  1. Richard
    március 4, 2014 - 9:01 du.

    Írhatnál 1 rövid (de ha lehet inkább hosszabb 😉 ) cikket egy meglevő tanúsítvány megújításáról is. Azaz amikor -mint ennek a cikknek a 2. bekezdésében is írtad- egy meglevő tanúsítványt meg akarok hosszabbítani még a lejárati ideje előtt (mert ha jól tudom ez feltétel.. de miért?) az miben különbözik attól mint amikor igénylek egy komplett új tanúsítványt? Ha a meglevőt hosszabbítani akarom, akkor elvileg a privát kulcs változatlan marad… tehát az újabb request-ben mi is lesz akkor megváltozott? Miért akarnék / milyen esetben akarnék ilyesmit tenni kompletten új tanúsítvány igénylése helyett? Mik az előnyei hátrányai a 2 opciónak?

    Remélem ezen kérdések körvonalaztak egy alaposab kivesézésre érdemes témakört. Az egész PKI szerintem tokkal vonóval a Microsoft-alapú IT feketebáránya, pl. mert nincs hozzá 1 tetves hivatalos MSPress book, holott a mai modern MS portfólió egésze kisebb -de inkább nagyobb- részben PKI-ra épül. A Brian Komar féle egyetlen PKI témájú könyv meg totálisan félreértelmezi, mit vár el az egyszeri halandó MS informatikus egy “Introduction to PKI” tematikájú könyvtől.
    Tavaly vagy 2 hónapot rászántam a PKI-re, és áttúrtam a Technet archívumát a Windows 2000-től kezdve, és szégyen-gyalázat, alig találtam -és még rohadtul elrejtve az MSDN-en belül is- magas szakmai minőségű alapozó irományokat. Minden más PKI jellegű article az agyatlan alkalmazói szintet tárgyalta csakis, azaz hogyan kell kattintgatva beállítani olyasmit egy CA szerveren, ami fogalom szinten elnagyolva van csak megmagyarázva.

    Ugyanígy érdekes téma a certificate request elküldése és a certificate response fájl visszaérkezése között a CA szerveren a request-be történő belemódosítás esete is. Pl. a public 3rd party CA csak olyan request-ek fogad el tőlem, amiben 1 db subject name van, és egy webes formon megadott SAN listát a CA szerver teszi bele a válasz fájlba. Azaz szigorúan véve nem arra a request-re kapjuk meg a response fájlt, mint amit eredetileg elküldtünk. Ez most aggályos, vagy teljesen “by design”? Egy PKI könyvben sem találtam meg rá a választ…

    • március 5, 2014 - 8:17 de.

      Nem ígérek semmit (de azt legalább betartom 🙂 ).
      Komolyra fordítva a szót, most benne vagyok pár nagyobb projektben, ha azokat kivégeztem, megpróbálok válaszolni a kér(d)ésedre.

  2. Richard
    március 5, 2014 - 9:25 de.

    Asteriksz :
    Nem ígérek semmit (de azt legalább betartom ).
    Komolyra fordítva a szót, most benne vagyok pár nagyobb projektben, ha azokat kivégeztem, megpróbálok válaszolni a kér(d)ésedre.

    Nagy köszönet!

  1. március 3, 2014 - 1:15 du.
  2. március 24, 2014 - 8:27 de.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: