Archívum

Posts Tagged ‘ca’

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