Archívum

Posts Tagged ‘certificate request’

Tanúsítvány – új vagy megújítás

március 24, 2014 7 hozzászólás

Mivel sajnos a projektek csak nyúlnak, mint a rétes, úgy döntöttem, megpróbálok Richard kérdéseire válaszolni.

Mielőtt még a kérdésekre térnék, egy kis kitérő: eddig jellemzően nyilvános kulcsú, vagyis PKI tanúsítványokról írogattam, de léteznek engedélyező tanúsítványok is (autentikáció=hitelesítés, autorizáció=engedélyezés). Míg az előbbit egy CA (Certificate Authority) állítja ki, s a bemutatót azonosítja, addig az utóbbit egy AA (Attribute Authority) állítja ki, s mint a neve is mutatja, engedélyez valamit. Találóan úgy szokták jellemezni, hogy a PKC egy útlevélhez hasonlít, míg az AC egy vízumhoz, amivel még az elvégezhető tevékenységet is korlátozzák. Ezt a hasonlat talán „konyhanyelven” is érthetőbbé teszi a dolgokat. Ugyanakkor azt is érdemes figyelembe venni, hogy ha nem belső, tartományi CA-ról van szó, hanem „igazi”, külső CA által kiállítottról, akkor a korrekt eljárás az, hogy mindenféle hivatalos adatokkal/papírokkal/aláírásokkal igazoljuk, hogy valóban jogosultak vagyunk rá – hiszen innentől kezdve, mint „útlevél”, ő fog bennünket képviselni.

Egy meglévő tanúsítvány meghosszabbítása a lejárat ideje előtt nem feltétlenül követelmény, de mindenképp egy javaslat – a technikai megvalósítása pedig cégtől (durván szólva CA-tól) függ. Üzleti szempontból sem jó pont, ha bármilyen szolgáltatás megszakad/figyelmeztetésre fut egy lejárt tanúsítvány miatt (pl. nemrég az OTP-Bank számlakezelésénél…).

Egyes tanúsító hatóságok esetén a lejárat után is van egy kis idő, amelyen belül a CA kiállítja a digitális tanúsítványt anélkül, hogy a tulajdonos megismételje az egész hitelesítési eljárást, de ezt követően a megújítás megkívánja a teljes ellenőrzést (például, GoDaddy általános szabálya az, hogy a tanúsítványa lejárta után van még egy 30 napos türelmi ablak, de pl. a GlobalSign is csak a lejárat előtti megújítást fogadja el). Ugyanakkor, ha egy Microsoft CA-ról van szó, egyértelműen nem lehet egy lejárt tanúsítványt megújítani, mint itt feketén-fehéren le is van írva.

Miben különbözik egy új tanúsítvány a régi megújításától? Alapvetően kényelmi kérdésekben csak. Végül is valóban szinte ugyanarról szó, hiszen leginkább a tanúsítványon található dátumok változnak. Bizonyos esetekben kérhetünk kulcs-változást is (erre alább visszatérek), de általában az érvényességi idő a legfontosabb változás.

Ezt bizonyítja az is, hogy egyes kiszolgálók elfogadják ugyanazt a CSR-t a tanúsítvány megújításakor. Ugyanakkor, ha csak „sima”, egyszeri kapcsolatról van szó (pl HTTPS, LDAPS, egyéb SSL), akkor szinte mindegy. Azért szinte, mert ha ugyanaz a CA, akkor annak tanúsítványa már benne van a kliens megbízható legfelső tanúsítványai között – ha ellenben másik CA-ról van szó, akkor az is megbízható kell legyen. Továbbá az emberi lustaság is szerepet játszik: miért töltsük ki ismét a tanúsítvány adatait, ha egyszerűen azt tudjuk mondani, hogy csak hosszabbítani akarunk (útlevél-példa)?

Ha viszont egy hosszabb távra használt tanúsítványról van szó (pl. EFS DRA), akkor szintén érdemes inkább megújításban gondolkozni, hiszen ekkor megmarad a kulcs-pár, magyarul, ha beállítottuk az AD-ben a Recovery Agent-et, akkor a későbbiekben is vissza tudjuk állítani a titkosított adatokat. Ha viszont új tanúsítványt kérünk, új kulcsokkal, akkor azok értelemszerűen nem lesznek benne a titkosításhoz használt kulcsok között.

Másik példa egy SSH-kiszolgáló, ahol már megbíztunk egy adott kulcsban, ne kelljen ismét ezzel foglalkozni. Természetesen egy egészen egyedülálló helyzet pl. egy CA-tanúsítvány megújítása, ahol a folyamatosság végett szintén érdemes a kulcsokat megtartani.

Ugyanakkor, ha pl. tanúsítvánnyal írtunk alá adott programot, akkor ott ismét előkerülhet ez a kérdés (ez és ez is ilyenről szól, ott ez a megoldás).

Az, hogy a privát kulcs változatlan marad-e, jó kérdés. Bizonyos esetekben bizony változik/változhat, mondjuk eddig 1024-bites titkosítást használtunk, s át akarunk térni 2048-bitre, vagy felmerül egy esetleges „kulcs-szivárgás” lehetősége, vagy egyszerűen csak biztonságosabban érezzük magunkat. Ugyanakkor elég sok esetben automatikusan változnak a kulcsok.

Ennek ellentéte pl. a már említett EFS DRA tanúsítványa. Ebben az esetben adott tartományon belül válthatunk egy Enterprise CA-ról egy másikra, a kulcsok nem változnak (természetesen a tanúsítvány igen). Ez mindenképp jó hír, hiszen ebben az esetben az állományok az eredetileg kapott kulccsal lettek titkosítva, s évek múlva is vissza tudjuk őket fejteni (külön cikkek foglalkoznak azzal, hogy mi van, ha nem tudjuk megújítani, illetve hogyan mentsük a DRA privát kulcsát). Azt ugye nem kell senkinek ecsetelni, hogy a DRA privát kulcsos tanúsítványát (Pfx) minden esetben érdemes (tíz lakat alatt) megőrizni, ha titkosított adataink vannak.

Vannak olyan CA-k, ahova ugyanazt a CSR-t be tudod nyújtani, tehát nem feltétlenül a request oldalán kell keresni a változást, hanem a válasz oldalon. Persze, hogy akkor feltevődik a kérdés, hogy minek egyáltalán benyújtani a kérelmet – nos, azért, mert a CA nem tudhatja, hogy azonos „feltételekkel” (adatokkal, kulccsal, stb.) újítsa meg, vagy egy másikat óhajtasz. Ugyanakkor, ha már megszűnt a tanúsítvány felhasználója, mi értelme lenne az automatikus újításnak (s itt gondoljunk bele pl. egy AD-ban a gépek változása esetén, amelyek automatikusan igényelnek/kapnak maguknak új tanúsítványt).

Milyen előnye van egy teljesen új tanúsítványhoz képest? Erre most külön nem válaszolnék, hiszen a fenti fejtegetéseimben megpróbáltam rávilágítani 🙂 Véleményem az, hogy ha nem változik semmi (legfeljebb a kulcs), akkor inkább megújítani érdemes (ugye a kulcs-változást is le lehet kezelni újítással). De ez csak egy javaslat, természetesen mindenki maga dönti el…

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

február 27, 2014 5 hozzászólás

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 🙂

Kategóriák:PKI Címkék: ,