Archívum

Archive for the ‘PKI’ Category

Engedélyhez kötött tanúsítványok

június 6, 2016 3 hozzászólás

Ha bármely tanúsítványsablonon bekapcsoljuk, hogy valakinek kell engedélyeznie a tanúsítvány-kiállítást, akkor pár dologra érdemes figyelnünk az igénylés során. A legegyszerűbb, ha ilyenkor webes felületet használunk a kérelem benyújtásához, ugyanis elbírálás után ugyanezen a felületen tudjuk lekérni a kapott tanúsítványt.

Amennyiben mégis mmc-t (vagy bármilyen más módszert) használunk, akkor a kliens-gépen ott lesz a Request, de az engedélyezés után kapott tanúsítvány kézhezvételéhez a leggyakrabban használt módszerek:

  1. exportáljuk a CA-n,
  2. kliensen kérjük le a tanúsítványt, a certreq segítségével (Figyelem: bármelyik tanúsítványt le tudjuk kérni a CA-tól, ha tudjuk a CA-ban található RequestID azonosítóját, így mindenképp jegyezzük meg, hogy melyiket akarjuk letölteni)
  • interaktív módon:

          certreq -retrieve RequestID

ezután kiválasztjuk a CA-t, illetve, hogy milyen néven/hova kerüljön mentésre a tanúsítvány, alapértelmezetten .cer lesz

  • automata üzemmódban:

          certreq.exe -retrieve -config <CAConfig> <RequestID> <OutPutCertFile.cer>

ekkor fontos, hogy a paraméterek ilyen sorrendben legyenek (az ID-t ne tegyük a -config elé, ne tegyük paraméter-megnevezési sorrendbe), a CAConfig pedig lehet pl. Server_Neve\CA_Neve (de certreq -retrieve /? természetesen mindig súg 😉 )

Amennyiben sikerült megkapnunk a tanúsítványt, az igénylő gépen importáljuk (akár grafikus felületen, dupla klikkel, akár certreq -accept <OutPutCertFile.cer> paranccsal), itt összerendelődik a privát kulccsal, így „teljessé” válik a tanúsítvány.

Bár néhány internetes fórumon szoktak rájuk hivatkozni, de a tanúsítvány-áttöltéshez se a „certutil -pulse” nem járható út, se a házirendben engedélyezett Auto-enrollment (User Configuration / Windows Settings / Security Settings / Public Key Policies / Certificate Services Client – Auto-Enrollment – erről majd egy következő cikkben még ejtek szót) nem hatásos, mint a hivatalos cikk is jelzi.

Split-DNS vs .local

május 9, 2016 2 hozzászólás

Az utóbbi időben két olyan rendezvényen is részt vettem, ahol felmerült a belső tartományi név TLD-kérdésköre: local vs. publikus (split DNS-el). Egyik helyen elfogadták JoeP-el közösen kinyilvánított álláspontunkat, másik helyen kevésbé. Nos, a tanfolyamokon el szoktam mondani ezzel kapcsolatosan a véleményem, a tapasztalataimra alapozva – de ez mindenképp mérlegelés kérdése. Pontosabban csak akkor, ha nem kis cégről beszélünk; ugyanis ahol SBS-t telepítenek, ott „gyárilag” eldöntik helyettünk (ez most az utolsó verziókra vonatkozik, régebben ott is megvolt a döntési szabadságunk).

A válasz ugyanis nagyon nem egyértelmű, ki-ki maga kell eldöntse, hogy mit választ, de ne én mondjam meg a tutit, itt van egy összefoglaló egy MVP-től (maga a cikk régi, de időnként frissítve van új információkkal, s itt felhívnám a figyelmet a legutolsó, 2014-es bejegyzésre, így talán egyértelműbb a kategóriába való besorolás oka is):

http://blogs.msmvps.com/acefekay/2009/09/07/what-s-in-an-active-directory-dns-name-choosing-a-domain-name/

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

SHA1 elavul

május 2, 2016 6 hozzászólás

Páran jelezték, hogy elég régóta nem írtam kedvenc témámról, a tanúsítványokról. Nos, kezdjük is egyből egy közérdekű közleménnyel: a Microsoft, eredeti terveihez képest, előbbre hozta az SHA1 nyugdíjazását: eredetileg 2017 januári hónapja volt becélozva az SHA1 kivonatolási (hash) mód elavult (deprecated) státuszba kerüléséhez, de már 2016 júniusától nem támogatott. A helyét az SHA2 (SHA256, SHA384, SHA512) veszi át – ehhez a CA kriptográfiai módszerének Key Storage Provider (KSP) kell legyen. Ha valaki Cryptographic Service Provider (CSP)-t használ, mivel az nem tud SHA2-t, szükség lesz még egy kis CA-átalakításra (KSP/CSP témát érintettük itt is, kissé más vonatkozásban; CNG (Cryptography Next Gen) érintett része itt).

Aki le akarja cserélni az új tanúsítványok kivonatolását, annak nincs nehéz dolga: egy emelt szintű parancssorban lefuttatja az alábbi sort, majd újraindítja a CA-kiszolgálót:

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

net stop certsvc

net start certsvc

Fontos, hogy ez csak a mostantól kiállított tanúsítványokra fog vonatkozni, a meglévőkre (beleértve a CA sajátját is!) nem.

Mint látszik, nem a „szokásos” (Next-Next-Finish kategória) kivitelezés a gond, hanem a tervezés – ugyanis kivitelezés után egy pár operációs rendszer nem tudja majd kezelni az új tanúsítványokat: az XP SP3, illetve Win2003 (+patch)-től felfele tudja a Windows az SHA2-t. Ha van egy olyan hálózatunk, ami ennél régebbi oprendszereket (pl. Win2000) futtat, amelyek nem lecserélhetőek, akkor egyik kerülőút a két CA használata lehet.

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

Sikertelen NPS hitelesítés

június 26, 2014 2 hozzászólás

Adott ügyfélnél a sikertelen hitelesítések sora kezdett gyűlni az NPS-kiszolgálón. Az eseménynaplóban sajnos eléggé semmitmondó üzenet volt, így segítséget kértek a probléma behatárolása érdekében.

Nézzük a naplóbejegyzést (kivonatoltam):

Network Policy Server discarded the request for a user.

Contact the Network Policy Server administrator for more information.

Authentication Details:

            EAP Type:                               –

            Account Session Identifier:                    –

            Reason Code:                           1

            Reason:                                               An internal error occurred. Check the system event log for additional information.

Ha megnézzük a listában a hibakódot, továbbra sem leszünk okosabbak, hiszen az üzenettel ellentétben nem a kiszolgálóval van baj, hanem csak bizonyos hitelesítések esetében van gond (erre még visszatérünk).

Semmi gond, nézzük tovább. Az NPS saját logállománya talán segít – reméltem. Ez a remény azonban hamarosan szétfoszlott, amint belenéztem, s gyakorlatilag a sikeres és sikertelen sorok között nem láttam érdemi különbséget.

Maradt a nyomozás. „Természetesen” semmi nem változott, semmi nem került telepítésre/eltávolításra. Az egyetlen nyom az volt, hogy a munkaállomások kivétel nélkül sikeresen hitelesítettek, egyedül a multi-funkciós készülékek (MFP) hasaltak el.

A megértéshez annyit érdemes tudni, hogy az ügyfélnél beállításra került az MFP-k tanúsítvánnyal történő hitelesítése. Ennek alapján a készülékek bekapcsoláskor egy intelligens hálózati eszköz segítségével bemutattak a Radius-kiszolgálónak egy érvényes tanúsítványt, ekkor kaptak „rendes” ip-címet, ellenkező esetben egy másik alhálózat tagjai lettek.

Nos, ez a hitelesítés hasalt el. Ideiglenesen kikapcsoltuk a Radius-hitelesítés igényét (hogy kapjon megfelelő ip-címet), s megnéztük az MFP-beállításait. Ekkor derült ki, hogy a bemutatásra feltöltött tanúsítvány járt le, ezért futott hibára. Ezt maga az MFP nem képes megújítani, így manuálisan kell feltölteni az újat – természetesen a régi lejárta előtt – s máris helyreáll a béke. De hogy ezt miért nem lehet egy rendes hibakóddal/üzenettel/naplóbejegyzéssel jelezni, nem értem 😦

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

Certificate Services 2012

május 20, 2014 5 hozzászólás

Úgy tűnik, lassan ki tudok evickélni a felszínre, így folytathatom a bloggolást 🙂

„Kezdetnek” legyen egyből egy rövid kivonat, egyik kedvenc témámról, a tanúsítványkezelésről, pontosabban a 2012 újdonságairól e téren.

Mint más területen is, itt is összevonták a Standard és Enterprise tudását, magyarul, bármelyik funkciót tudjuk használni 2012 Std esetén is (emlékszünk, korábbi verziók esetén bizonyos feladatköröket csak Ent SKU esetén használhattunk).

A következő, szerintem jelentős (várható) lépés az volt, hogy végre lehet Core verzióra is telepíteni. Ez sem szorul további magyarázatra, hiszen a terhelés minimális volta, meg az előző Core verziókra is részlegesen telepíthető IIS előrevetítette ezen kívánság megvalósulásának lehetőségét.

Mint megszoktuk, újabb Windows verziók/családok esetén újabb tanúsítvány-sablonokat is kapunk, így a soron következő 4. verzió egyértelmű volt. Ez a verzió természetesen nem csak számozásában több, mint elődjei, de képes pl. ugyanazon kulcs használatával megújítani a sablonon keresztül igényelt tanúsítványt (ehhez legalább Win8/2012 szükséges) – ezt is érintette a kis eszmefuttatás. Szintén v4 fejlesztés, hogy egyszerre tudja használni a Cryptographic Service Provider (CSP) és Key Storage Provider (KSP)-ket (v2 esetén a „Request handling” fülön lehetett az  előbbieket, míg v3 esetén a „Cryptography” fülön utóbbiakat), itt most egy fülön rendezhetjük ezek sorrendjét is. Ami szintén érdekesség, hogy mostantól sablon másolása esetén nem verziót kell megadnunk, hanem a kompatibilitási fülön a kiszolgáló/igénylő operációs rendszereit kiválasztva tudjuk meghatározni a sablonon elérhető funkciók listáját, ebből állapítja meg a CA a mentendő sablon verzióját.

A nyalánkságok közül kiemelném a CA-val folytatott tanúsítvány-igénylés menetének titkosítását, mely most már alapértelmezetten bekapcsolt állapotban van (eddig is lehetett, de alapból ki volt kapcsolva). Fontos, hogy az XP-k még nem tudják így kérni a tanúsítványokat, így ilyen esetben ki kell kapcsolni ezt a titkosítást.

Mivel már 2008-ra is létezett egy folt a CA-kiszolgáló privát kulcsainak mentésére (KB2603469), ez itt természetesen alapból megoldott, így ezt csak megemlítem. A Server manager és PowerShell szinte kötelező jellegű fejlesztés, ami viszont hasznos, az a tanúsítvány lejáratának figyelmeztetése. Ráadásul testre szabhatóan, egy hordozható gép akkujának merüléséhez hasonlóan, mi tudjuk házirendből szabályozni, hogy százalékban kifejezve milyen szintű „élettartam” (hasonlatban „töltöttség”) esetén kezdjen riasztani. Ezeket az eseménynaplóban jelentkező riasztásokat viszont már úgy kezeljük, ahogy akarjuk (pl. emailt küldünk).

A teljes változás-listát itt találjuk.

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

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 – 2. rész

március 3, 2014 Hozzászólás

Folytassuk ezt, áttérve a gyakorlatra.

A legfontosabb az exportálandó tanúsítvány azonosítása: a név alapján a legkönnyebb, ám létezhetnek ugyanolyan nevű, de más funkciójú tanúsítványok, ekkor a sorozatszám (Serial number) vagy lenyomat (Thumbprint, Cert Hash) segít.

Természetesen privát kulcsos tanúsítványt csak akkor tudunk exportálni, ha a privát kulcs is a gépen van, pl. mmc-konzolon megnyitva a tanúsítványt You have a private key that corresponds to this certificate.” üzenetet kell lássunk (mellékesen már a tallózáskor látható a kulcs jele a tanúsítvány ikonján):

cert-pfx

Ha ezt tisztáztuk, próbáljuk meg kapásból Mmc-ből exportálni – s itt máris jöhet egy buktató.

Ha szürke a Pfx opció, s „The associated private key cannot be found.  Only the certificate can be exported” hibaüzenetet kapunk, akkor nagy valószínűség szerint nincs hozzáférésünk a már említett kulcs-tároló könyvtárhoz és tartalmához:

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

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

Ugyanez az egyik leggyakoribb oka egy másik ismert hibának is, ami már a tanúsítvány megnyitásakor látszik: „You have a private key that corresponds to this certificate but CryptAcQuireCertificatePrivateKey failed”.  A könyvtárhoz szükséges jogok a KB278381-ben vannak leírva.

Nézzünk más módszereket. Azonosításhoz bevethetünk PowerShell-t is, hiszen a tanúsítványtárolóban pont úgy lépegethetünk, mint egy könyvtárstruktúrában (annyi különbséggel, hogy a „meghajtó-váltásnál” szükséges a „cd” utasítás), ahol előbb a tároló helyét határozzuk meg (CurrentUser, LocalMachine), ezen belül pedig a tárolók (CA, Trust, My, stb.) közül választhatunk – itt tudatosan nem egy lépésben csinálom, hogy gyakoroljuk 🙂 :

cd cert:

dir

cd LocalMachine

dir .\My

A listázott tanúsítványok közül kimásoljuk az érintett tanúsítvány lenyomatát, s ha mindezt egy Windows 8/2012 (vagy újabb) rendszerű gépen csináljuk, akkor kapásból tudjuk is exportálni az Export-PfxCertificate használatával. Aki régebbi rendszerrel nyomul, az viszont ezt próbálhatja ki.

Végül, de nem utolsó sorban nézzük a szinte minden érintett cikkemben előforduló parancssoros tanúsítványkezelőt. A Certutil [-user] –store My paranccsal ki tudjuk listázni őket, itt a Serial number és Cert Hash adatai alapján tudjuk kezelni.

Természetesen az exportálás sem okoz gondot neki:

certutil -exportPFX -p “jelszó” [-user] my ”sorozatszám_vagy_lenyomat” tanusitvany.pfx

Még egy picit térjünk vissza az mmc konzolra. Tételezzük fel, hogy a kezdeti akadályokon túlküzdöttük magunkat, de továbbra is The associated private key is marked as not exportable hibaüzenet fogad bennünket a konzolból történő exportkor (például egy számítógép tanúsítványának pfx-mentése során, ha azt egy CA állította ki, ahol a Computer sablonban a privát kulcs alapértelmezettje a nem-menthető).

Ha nem tudjuk az elméletet, s ugyanezt megnézzük Certutil-al, a listázáskor nem írja ki egyértelműen, hogy „Private key is NOT exportable”, így azt gondolhatnánk, hogy sínen vagyunk. Ne dőljünk be neki! Ekkor igaz, hogy lefut az exportálást végző utasítás, de a kapott pfx nem fogja tartalmazni a privát kulcsot. (Ilyenkor sem lehetetlen azt megkapni, de azt én már nagyjából hackelés kategóriába sorolnám.) Ugyanez az helyzet, ha már a listázásnál az „Encryption test FAILED” sort látjuk.

S még egy utolsó dolog. Amikor egyes helyeken azt írják, hogy „hozzunk létre egy CA-t”, az számukra annyit jelent, hogy hozzunk létre egy olyan önaláírt tanúsítvány-kulcs párost, amelynél rendelkezünk a privát kulccsal, azzal alá tudunk írni. Érezzük, hogy ez nem ugyanaz, mint egy „igazi” CA tanúsítvány-kiszolgáló, de ha mégis valaki erre vetemedik, akkor emelt szinten ezt futtassa:

openssl genrsa -des3 -out privkey.pem 2048

openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095

Ekkor legyártja külön a privát kulcsot, 2048-bites DES3 kódolással, bekéri a titkosításhoz használt jelszót, lementi a titkosított privát kulcsot, majd második lépésben bekéri a tanúsítványon szereplő többi adatot, s elkészíti a tanúsítványt. Mint látjuk, nagyon hasonlít a tanúsítvány-kérelem igényléséhez (openssl req -new -keyout privkey.pem -out certreq.pem –days 365), „csak” a kimenet változik 🙂 De természetesen egy telepített CA-val nem tud vetekedni…

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

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: ,

Tanúsítvány miatti lassulás

szeptember 18, 2013 2 hozzászólás

Adott cégnél panaszkodtak a kollégák, hogy egy adott alkalmazás lassan indul el. Mindez azért volt furcsa, mert igaz, hogy böngészőt használnak, de az a helyi kiszolgálókra csatlakozott, onnan töltötte be az adatokat. S egyértelműen látszott, hogy míg a fejlesztőknél villámgyorsan betöltődik az oldal, a felhasználók esetén legalább 2 perc kellett elteljen.

A kérdés körbejárása közben derült ki, hogy gyakorlatilag nem is az oldallal van baj, hanem annak egy adott részével. Ott egy Java-alkalmazás futott le, amelyik meghívott egy digitálisan aláírt .ocx komponenst, s ennek betöltése során jött a hosszú várakozási idő.

A kollégák körbejárása, majd később a közös nyomozás nem volt egyszerű. A Java verziók stimmeltek, egyértelmű volt, hogy a komponens betöltődik (tehát korrekt módon lett regisztrálva) – de a lassúság valóban zavaró volt. A jogosultságok ellenőrzése szintén nem hozott eredményt, ha egy fejlesztő jelentkezett be a felhasználó gépén, akkor azon a gépen nála is lassú volt.

Az egyik jelentős különbség, ami alapján el tudtunk indulni, az a két gép hálózati csatlakozása közötti eltérés. A fejlesztők egy teljesen más hálózatra csatlakoznak, amelynek van ugyan némi átjárása a belső hálózatra, de korlátozott módon. Ezért egy fejlesztői gépet – megfelelő ellenőrzés után – rákötöttünk a belső hálózatra, s úgy próbáltuk elérni a kért weboldalt. S íme, máris jött az első nyom: az internetre akart csatlakozni, ehhez a belső hálózaton használt proxy-hoz kérte a név/jelszó párost. Akár megkapta, akár nem, tovább lehetett lépni, s betöltődött a kért komponens – de felmerült a kérdés, hogy ha végig belső hálón vagyunk, miért is akar kimenni?

A kérdés megválaszolása érdekében egy „igazi” belső hálós géppel próbáltuk ki ugyanezt, s a proxy logjaiból egyértelműen kiderült, hogy igen, valóban kimegy a netre. Amikor pedig megláttuk, hogy hova, akkor esett le a tantusz: a komponenst aláíró tanúsítvány-kiállító webhelyére. Mint később tovább pontosítottuk, a CA fel volt ugyan véve a megbízható legfelső szintű tanúsítványok közé (házirendből), de a komponens tanúsítványában ki volt töltve az AIA mező, s a szintén ott beállított OCSP használatával ment „haza” (itt már érintettem az AIA-t). Ezzel nem is lett volna gond, de a belső hálózaton használt proxy (egy ISA) a cég előírásai miatt tele van szabályokkal (ráadásul a vas sem mai darab), így az internetre való kijutás nem azonnali. Ugyanakkor viszont a fejlesztők egy másik VLAN-on korlátlan internetet kapnak – s így már érthető a két gép közötti működés eltérése. Bizonyításképp egy új, első helyre állított ISA-szabály segítségével, amely hitelesítés nélkül kiengedte a felhasználókat a tanúsítvány-kiszolgáló irányába, sikerült a drasztikus lassulást megszüntetni – ezzel újabb frusztráló tényezőt megszüntetve.

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

Pfx előállítása – 2/2

május 7, 2013 2 hozzászólás

(az előző folytatása)

Különböző formátumú tanúsítványok közti konverzió

Szokásomhoz híven előbb leírom az általános információkat, majd onnan közelítek a felmerült kérdés megoldásához. Elég sok eszköz van, amivel tanúsítványokat tudunk kezelni, ebből most hármat említek meg. Használhatnánk a (cikkeimben nem egyszer említett) Certutil, a Pvk2Pfx segédprogramokat, de talán a legismertebb (szerencsére Windowsra is elérhető) az OpenSSL. Ugyanakkor fontos tudni, hogy néha nem mindig használható minden eszköz, például egy OpenSSL által előállított kulcs-állomány nem feltétlenül kompatibilis a másik két alkalmazással, vagy egy Makecert által létrehozott kulcs esetenként csak a Pvk2pfx-el kompatibilis.

Nézzük sorra. Induljunk ki abból, hogy rendelkezésünkre áll a tanúsítvány, valamint a privát kulcs, ebből kell .pfx-et gyártanunk.

Pvk2pfx használatával:

Pvk2pfx –pvk certfile.pvk –spc certfile.cer –out certfile.pfx

Certutil használatával:

Certutil –MergePFX certfile.cer certfile.pfx

Mivel a paraméterezés alapján nem tudjuk megadni a privát kulcs állományát, arra kell figyeljünk, hogy ennek elnevezése ugyanaz kell legyen, mint a tanúsítvány-állománynak (s helyileg is egy könyvtárban kell legyenek), a kiterjesztése viszont kötelezően .key kell legyen.

OpenSSL használata:

Tekintettel arra, hogy az eredeti feladatban nem állt rendelkezésünkre a csak privát kulcsot tartalmazó állomány, ezt ki kell nyernünk, ehhez meg az egyik legkönnyebb mód ezen program használata. Ezért is egy kicsit jobban fogom részletezni, ugyanakkor megragadom az alkalmat többféle konverzió menetének leírására is.

A program használata során érdemes figyelni arra, hogy vagy mindent egy helyre másoljunk, vagy az útvonalak helyesek legyenek, különben system library:fopen:No such file or directory:.\crypto\bio\bss_file.c hibaüzenet jöhet, ami nem a bss_file.c hiányát jelzi 🙂

Mielőtt még leírnám az utasításokat, nézzük, a paraméterek mit takarnak:

–       Certificate: a tanúsítvány(oka)t (esetleg privát kulcsot) tartalmazó állomány

–       CAcert: a tanúsítvány-kiszolgáló tanúsítványa

–       PrivateKey: a tanúsítvány privát kulcsa

PEM
PEM -> DER

openssl x509 -outform der -in Certificate.pem -out Certificate.der

PEM -> P7B

openssl crl2pkcs7 -nocrl -certfile Certificate.cer -out Certificate.p7b -certfile CAcert.cer

PEM -> PFX

openssl pkcs12 -export -out Certificate.pfx -inkey PrivateKey.key -in certificate.crt -certfile CAcert.crt

PEM -> KEY

Pfx-ből exportálva (lásd később) a kulcsot PEM formátumban kapjuk meg, ekkor a kulcs még titkosított formában van, ennek a titkosításnak az eltávolítása:

openssl rsa -in PrivateKey.pem -out PrivateKey.key

DER

DER -> PEM

openssl x509 -inform der -in Certificate.cer -out Certificate.pem

P7B

P7B -> PEM

openssl pkcs7 -print_certs -in Certificate.p7b -out Certificate.cer

P7B -> PFX

openssl pkcs7 -print_certs -in Certificate.p7b -out Certificate.cer

openssl pkcs12 -export -in Certificate.cer -inkey PrivateKey.key -out Certificate.pfx -certfile CAcert.cer

PFX

PFX -> PEM

openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

Megjegyzés: A PFX-ből a PEM formátumba konvertálás folyamán az OpenSSL a tanúsítványokat és privát kulcsot egy állományba helyezi. A különválasztáshoz megnyitjuk az állományt egy szövegszerkesztőben, és átmásoljuk az egyes tanúsítványokat és a privát kulcsot (beleértve a BEGIN / END bejegyzéseket is) a saját egyéni szöveges állományukba, külön mentve őket Certificate.cer, CAcert.cer, PrivateKey.key néven. Az ömlesztett állomány a következő sorrendben tartalmazza őket: a privát kulcs, a tanúsítvány, a gyökér tanúsítványa, esetleges köztes tanúsítványok.

Csak a tanúsítvány exportálása:

openssl pkcs12 -in certificate.pfx -clcerts -nokeys -out cert.pem

A privát kulcs exportálása:

openssl pkcs12 -in certificate.pfx -nocerts -out PrivateKey.pem

A kiinduló kérdés megoldása:

A végcélként egy .pfx állományt tervezünk, aminek a neve a %Pfx% változóban lesz. A nyersanyagunk egy .P7b állomány, ami a felmenő tanúsítvány-láncot tartalmazza (ez lesz a %CA%), valamint a megújított tanúsítvány .Crt formátumban (ez pedig a %Crt%). Mivel írtuk, hogy ezen felül még szükséges a privát kulcs, ezért az első lépés a sikeres művelethez exportálni (pl. MMC-konzolból) a jelenlegi tanúsítványt, privát kulccsal (az %OldCert% változóban megadott állományba).

Az exportált OldCert.Pfx állományból kiexportáljuk a privát kulcsot (ez lesz a %Key%):

Set %UtilPath% = c:\Program Files (x86)\GnuWin32\bin
“%UtilPath%\OpenSSL” pkcs12 -in %OldCert% -nocerts -out %Key%

Itt a kapott PrivateKey.pem állományt vagy tovább „tisztítjuk”, azaz eltávolítjuk a titkosítást, vagy „nyers” formátumban felhasználjuk – ekkor arra figyeljünk, hogy előbb a .pem titkosítási jelszavát kéri be, s csak utána a készülendő .pfx állomány titkosítására használt jelszót.

Utolsó lépésként összefűzzük a kapott állományokat (haladó felhasználóként megspékeljük az eredeti utasítást azzal, hogy a CA nem .crt, valamint a privát kulcs nem .key formátumú):

“%UtilPath%\OpenSSL” pkcs12 -export -out %NewPfx% -inkey %Key% -in %Crt% -certfile %CA%

A futtatás során megadjuk az előbb említett, titkosításhoz használt két jelszót (a privát kulcs titkosítását feloldó, valamint a készülő állomány titkosítására használtat), s máris előállt a kért állomány.

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