Archívum

Archive for the ‘PKI’ Category

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

május 6, 2013 6 hozzászólás

Nemrég egy érdekes feladatot kaptam: adva van egy lejárt tanúsítvány, amely lejárt, de az illetékes nem a megszokott módon újította meg, hanem a régi tanúsítvány-kérelmet adta be, s arra kapott egy új tanúsítványt, p7b formátumban. Ebből kellett pfx-et gyártani.

Mielőtt még a megvalósítást leírnám, a megértéshez nézzük át a tanúsítvány tárolásának formáit.  A különböző platformok és eszközök az SSL tanúsítványokat különböző formátumokban használják (pl. ebben a cikkben is több formátumra volt szükség, a Windows-ok világában a .pfx, míg egy Apache esetén a .crt, .cer kiterjesztés a szokványos), szerencsére van átváltási lehetőség ezek között.

Hogy tovább bonyolítsuk a dolgot, pl. a .cer kiterjesztés kétféle tárolási formát is takar: a PEM és a DER verziót (a kettő közti különbséget egy szövegszerkesztőben történő megnyitással láthatjuk, a BEGIN és END ellenőrzésével).

No de akkor lássuk a formátumokat:

PEM formátum

Ez a tanúsítvány-kiszolgáló által kiállított leggyakoribb formátum, tartalmazza a „- BEGIN CERTIFICATE -” és „- END CERTIFICATE -” bejegyzéseket.

Több PEM tanúsítvány és még a privát kulcs is benne lehet egy állományban, egymás után, de a legtöbb platform (pl. Apache) elvárja, hogy a tanúsítványok és a privát kulcs külön állományokban szerepeljen.

Jellemzői:

  • Base64 kódolású ASCII állományok
  • a lehetséges kiterjesztések .Pem, .Crt, .Cer, .Key (ha csak egy tanúsítvány van benne, a .pem-et átnevezve .crt vagy .cer kiterjesztésre a Windows natívan is megmutatja nekünk a tartalmát)
  • Apache és hasonló kiszolgálók használnak Pem formátumot

A .Pem és .Crt kiterjesztéseket gyakran használják szinonimaként, mivel mindkettő Base64 kódolású ASCII állomány. A jelentős különbség az, hogy míg a .Pem állomány a tanúsítványokat és a kulcsot is tartalmazhatja, addig a. Crt állomány csak a tanúsítványt – a valóságban ezt viszont gyakran figyelmen kívül hagyják.

Ha multifunkciós készüléket (MFP) akarunk úgy hálózatba kötni, hogy a webes adminisztratív felületét https-en érjük el, akkor ott is Pem formátumot kell használjunk, tehát az mmc konzolból exportált Der formátumot át kell alakítsuk.

DER formátum

Az előző (ASCII PEM) formátumú tanúsítvány bináris formája. Bármilyen típusú tanúsítványt és privát kulcsot lehet kódolni DER formátumba.

Jellemzői:

  • bináris formátumú állományok
  • a lehetséges kiterjesztések .Cer és .Der
  • DER jellemzően a Java platform által van használva

P7B/PKCS # 7 formátum

Tartalmazza a „- BEGIN PKCS -” és „- END PKCS7 -” bejegyzéseket. Ez is több tanúsítványt tartalmazhat (a tanúsítvány-láncot), de a privát kulcsot nem.

Jellemzői:

  • Base64 kódolású ASCII állományok
  • a lehetséges kiterjesztések .P7b, .P7c
  • Több platform támogatja, pl: – Windows, Java, Tomcat

PFX / PKCS # 12 formátum

A tanúsítványt, a felmenő tanúsítvány-láncolatot, valamint a privát kulcsot tartalmazza egy kódolt állományban.

Jellemzői:

  • bináris formátumú állományok
  • a lehetséges kiterjesztések .Pfx, .P12
  • általában a Windows-on van használva, a tanúsítványok és kulcsok importálása és exportálása céljából

Egyéb ismert kiterjesztések:

A .Csr állomány a szervezetről adminisztratív információkat tartalmazó tanúsítvány-aláírási/igénylési állomány kiterjesztése.

A .Key állomány az általunk használt titkosításhoz szükséges privát kulcsot tartalmazza.

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

PKIView

július 4, 2012 5 hozzászólás

Mostani cikkemben bármely MS tanúsítványokkal foglalkozó szakember egyik segédjét fogom használni. Az eszköz létezett már W2k3 világban is, akkor a Resource Kit részeként a PKI Health Tool nevet viselte. Windows 2008-tól kezdve már az alaprendszer része, pontosabban az msc állomány alapból települ – még ha a Felügyeleti eszközök közé nem is kerül kivezetésre, ugyanakkor az átnevező kommandó révén most már Enterprise PKI néven tudjuk használni:

Az eszköz grafikusan mutatja meg a CA-k állapotát, ennek alapján néha hamarabb rájöhetünk egy-két hibára, ami a PKI rendszerünket zavarhatja. Aki nem foglalkozott még CA-val, vagy semmit nem állított el a tanúsítvány-kiszolgáló paraméterein, belefuthat abba, hogy kíváncsiságból futtatva a snap-in-t sárga háromszöggel ellátott szerverrel szembesül – vagyis figyelmeztető állapot miatt kezd el hevesebben verni a szíve. Még az sem biztos, hogy megnyugtatja, ha „beljebb” megy, s azt látja, hogy ez a jelzés a „CDP Location” lejáratát jelenti – mindaddig, amíg nem tudja értelmezni – s ezt próbálom most tisztázni.

Ebben a cikkben már említettem a CRL (Certification Revocation List) rövidítést – gyakorlatilag a használaton kívüli tanúsítványok sorozatszámának és visszavonási idejének (esetleg a visszavonás okát is tartalmazó) listája. Ennek a listának az alapján tudjuk eldönteni, hogy egy tanúsítvány érvényes-e még.

Igen ám, de ezt a listát valahogy el kell juttatni az ügyfélhez – ezért minden tanúsítvány tartalmaz egy CRL Distribution Points névvel jelzett sort, röviden CDP, ami pont azt jelzi, hogy hol lehet elérni a jelzett listát.

S itt jön a trükk: a PKIView jelzését nem úgy kell értelmezni, hogy a CDP jár le, hanem valójában a CRL lista jelzett időpontban történő elévülését jelenti.

Még ettől sem kell megrémülni. Tudnunk kell ugyanis, hogy teljesen jogos a CRL lejárata, hiszen az újabb CRL által tudunk értesülni az időközben történt változásokról. S hogy mennyi időközönként évül el a lista? Nos, erre írtam, hogy ezt tudjuk változtatni, de alapértelmezetten 1 hét, a Delta CRL elévülési ideje 1 nap. Hogy tekerjünk még egyet a dolgon, pontosítok: ezek nem az elévülési idők, hanem a publikálási idők. A kettő között az a különbség, hogy magának a listának az elévülési ideje 10%-al (de max. 12 órával) hosszabb, mint a publikálási idő (hogy legyen idő a címtárban replikálódni).

Ha mindezen tudás birtokában vagyunk, még egy dolgot ellenőrizzünk: a két CRL publikálási idejét. Ezt a CA-Manager-ben tudjuk megtenni (ezt akár a PKIView-ból el tudjuk érni, jobb klikkel a CA-n), azon belül pedig a Revoked Certificates ág tulajdonságait megnézve. Sőt, ugyanitt tudjuk ellenőrizni a lista következő publikálásának idejét is. Ha teljesen jól működik a kiszolgálónk, akkor a publikálás ideje meg kell előzze a lejárat idejét.

S hogy akkor mégis miért kap(hat)unk figyelmeztetést? Nos, azért a feltételes mód, mert csak akkor szembesülünk ezzel a sárga háromszöggel, ha nem sokkal a lejárati idő előtt használjuk az eszközt – de ha a különböző időpontok ellenőrzése pozitív eredményt hoz, akkor nem kell vele foglalkoznunk. Mivel a „nem sokkal” elég pongyola fogalmazás, ezért az eszköz gyökerén állva, jobb klikk, Opciók esetén tudjuk meghatározni, hogy számunkra mi számít soknak vagy kevésnek, mikortól jelenjen meg a figyelmeztetés.

Amennyiben mégis gond lehet az automatikus CRL-lista létrehozásával, létrehozhatjuk/frissíthetjük manuálisan is:

CertUtil [-config szervernév\CA_név] –CRL

A lista a „C:\WINDOWS\system32\certsrv\CertEnroll” könyvtárba kerül, ha szükséges, a címtárba innen tudjuk publikálni, felülírva az ott található (esetlegesen rossz) adatokat:

CertUtil -dspublish -f -dc “dcnev.domain.com” “C:\Utvonal\crlnev.crl”

Zárszó előtt még egy rövidítés: AIA (Authority Information Access): azt az információt tárolja, hogy a kiszolgálónkhoz hol találunk naprakész tanúsítványt. Ez, hasonlóan a CDP-hez, szintén egy elérési lista, ami prioritási sorrendben felsorolja az elérhetőségeket: helyileg (ez a CA-nak magának kell, de nem jelenik meg a kibocsátott tanúsítványokon), címtár, http, helyi vagy távoli útvonal.

S hogy miért említettem ezt a második listát? Azért, mert különbség van a címben jelzett eszköz 2003-as és 2008-as verziója között, az említett elérési pontok meghatározásában. A W2k3-as eszköz az AIA és CDP információkat egy 1 hétre érvényes CA Exchange tanúsítványból olvasta ki (s ezért csak szükség esetén kérte ezen tanúsítványok kiállítását). Ezzel szemben, bár az előbb említett tanúsítvány itt is kiállításra kerül, a jelenlegi eszköz a CA állapota alapján gyűjti be az adatokat: ha egy online CA-ról van szó, akkor közvetlen lekérdezéssel, offline CA esetén az általa kibocsátott tanúsítványokból olvassa ki. Ez azt jelenti, hogy ha bármi változás történik a két lista elérési pontjaiban, akkor az új eszközzel online látjuk, régebben viszont a tanúsítványok elévülését kellett erőltetni (Pl. CertUtil -cainfo xchg utasítással)

Gemalto key

június 14, 2012 6 hozzászólás

Nemrég egy sorsolással egybekötött játékon sikerült nyernem egy Gemalto Smart Guardian USB-kulcsot. Szerencsére a gyártó hazai disztribútora, a nyeremény felajánlója, volt annyira rendes (köszi Andi és Tamás 🙂 ), hogy kérésemre kicserélték egy kisebb kapacitású, ám nagyobb tudású Smart ENTERPRISE Guardian típusúra. Ami számomra lényeges volt, hogy ez utóbbi beépítve tartalmaz egy SmartCard chipet és olvasót – magyarul nem csak tárolóként, hanem hitelesítésre és azonosításra is használható eszközről van szó.

Amikor elkezdtem használni az intelligens kártya „részét”, természetesen az „olvasó” telepítése (ami automatikusan lezajlott) után következett volna a tanúsítvány feltöltése. Ennek mikéntje viszont nem volt egyértelmű. A kulcson található dokumentációban egy link segítségével lehetett volna további információkhoz jutni – elvileg a név és a hivatkozás jó is lenne, de a protokoll az csak http, így átdob egy másik oldalra (Device Administration Service), ami már használaton kívül van, ezért ott 404-es hibát dobott.

A neten keresgélve viszont találtam egy nyomot, amely alapján kiderült, hogy ugyanaz a cím, de https protokollal, a https://www.netsolutions.gemalto.com/ link már használható. Innen telepíteni kell az SConnect kiegészítőt, majd ezzel tudjuk feltölteni a (pfx vagy p12 formátumú) tanúsítványt.

Beismerem, eddig csak tanultam/hallottam SmartCard alapú Windows-hitelesítésről, élőben még nem volt alkalmam kipróbálni (természetesen a különböző banki aláírások, egyéb alkalmazások esetén már találkoztam velük – de azok értelemszerűen nem alkalmasak Windows felhasználói hitelesítésre, beléptetésre). Azt hittem, hogy a saját tanúsítványomat felmásolom az eszközre, s kész is vagyok. Nos, tévedtem – s utánagondolva, valóban logikus a történet.

Kezdjük azzal, hogy (legalábbis a Gemalto-nál), szükségünk van egy ügynökre. Gyakorlatilag a SmartCard tanúsítványt nem mi fogjuk igényelni, hanem ez az ügynök, a mi nevünkben. Ez alapból létezik a CA kiszolgálón, de alaphelyzetben nincs publikálva.

Ezután két lehetőségünk van: Smart Card Logon vagy Smart Card User. A kettő között az a különbség, hogy az előbbi csak „Smart Card Logon” és „Client Authentication” (magyarul SmartCard általi felhasználói hitelesítésre) lesz használható, utóbbi ezen kívül „Secure email” (elektronikus levelek aláírására, valamint titkosítására) szereppel is felruházza a tulajdonosát.

A testreszabáshoz duplikáljuk a kettő közül kiválasztott sablont, majd legalább a nevét módosítva a „Request handling” fülön a CSP-k közül kiválasztjuk a „Microsoft Base Smart Card Crypto Provider”-t, valamint az „Issuance Requirements” fülön 1-re állítjuk az engedélyezések számát. Végül a házirendnél „Application policy”, azon belül „Certificate Request Agent” opciót kell válasszunk, majd jöhet a két sablon (ügynök és az előbb testreszabott duplikált intelligens kártya) publikálása.

Következő lépésként már a kliensen kell igényeljük a tanúsítványokat. Előbb az ügynök tanúsítványát, majd utána haladó opcióként az ügynök nevében kérünk egy SmartCard tanúsítványt – ez, ha megadjuk helyesen a PIN-kódot, egyből rákerül a „kártyára” (esetünkben az USB-kulcsra), de bekerül a helyi felhasználói tanúsítvány-tárolónkba is…

Végezetül arra (az egyik kolléga által felvetett kérdésre) reagálnék, hogy az intelligens kártyának mekkora a létjogosultsága. Az mondjuk igaz, hogy az ő ujjlenyomat-olvasójával (volt szerencsém nekem is huzamosabb ideig ilyen laptopot használnom) nem veheti fel a versenyt kényelem szempontjából. Ott akár indításnál is kérheti az ujjunkat, így már az OS sem indul el megfelelő hitelesítés nélkül. Futó oprendszernél pedig elég lehúzni, s máris megfelel egy jelszó-beírásnak – például egy zárolás esetén is.

Ezzel szemben itt szükséges az OS (bár lehet, hogy léteznek olyan hordozható gépek, amelyek – mivel be van építve a kártya-olvasó – szintén hitelesítés után adják át a vezérlést az oprendszernek). Ezen kívül pedig tudnunk kell (sőt, be is kell ütnünk J) a PIN-kódot is, amivel a kártya tartalmához hozzáférhetünk. Igaz, hogy pl. zárolás esetén nem használhatjuk, tehát kényelem szempontjából valóban „nehézkesebb”, viszont kicsit más a felhasználhatósági területe. Például egy kártyán több felhasználó tanúsítványa lehet, így ahol létezik egy meghatalmazotti viszony, ott mindenképp használhatóbb, hiszen elég kiválasztani a meghatalmazó(k) tanúsítványát, nem kell tudni sem a bejelentkezési nevét, sem a jelszavát. Sőt, egy kártya olyan azonosításra szolgáló adatokat is tárolhat, amelyek nem csak számítógépes hálózatokban használt hitelesítésre alkalmasak – de ez már messzire vezet J

Sok embernek az intelligens kártya hallatán a multi-faktoros hitelesítés ugrik be. Tisztázandó, hogy nem csak ezzel lehet ilyent, listáznám a három módszert, amely közül legalább kettőnek kell teljesülni:

–       valamit tudunk (PIN, jelszó, stb)

–       valamink van (SmartCard, SecurID, OTP-s eszköz, stb)

–       valakik vagyunk (biometrikus azonosítás, pl. ujjlenyomat)

Ennek következtében mindkét fenti esetben (ujjlenyomat-olvasó, SmartCard) kialakítható egy multi-faktoros hitelesítés.

Zárásképp még egy tulajdonságát említeném meg az eszköznek, amit egyelőre még nem használok ki: OTP-t (One Time Password) is tud generálni, sőt, a „kisebbik” testvér, az SG is…

u.i. Vistánál régebbi rendszerek esetén a SmartCard használata esetén a következő hibaüzenet fogad:

„The card supplied requires drivers that are not present on this system.” („A megadott kártyához olyan illesztőprogramra van szükség, amely nincs meg a rendszerben”)

Ez nem azt jelenti, hogy az usb-kulcson található driver nincs telepítve (az csak az “olvasó”-t telepíti), hanem, hogy ezeken a rendszereken alapból nincs feltelepítve a megfelelő CSP, teljes nevén “Microsoft Base Smart Card Cryptographic Service Provider“. Ezt innen tudjuk letölteni, s ennek telepítése után már itt is élvezhetjük a SmartCard előnyeit 🙂

Kategóriák:General, PKI

Public Key Infrastructure (PKI) 3. rész – konkrét probléma

augusztus 17, 2011 Hozzászólás

Megvolt az elmélet (1. rész, 2. rész) – jöhetett a gyakorlat. Adott helyen egy nyomozás kiderítette, hogy az ISA szerver lejárt tanúsítványa okoz gondot a Mátrixban hálózatban.

Mivel tartományi gépről volt szó, s Enterprise CA-ról, a furcsa az volt, hogy nem kért/kapott magának automatikusan új tanúsítványt. Az összes többi gép a hálózatban rendben működött – de az ISA nem, az automatikus igénylés folyamatosan RPC-hibára panaszkodott.

Ekkor vettem végig az előző cikkben említett módszereket: az mmc konzolon keresztüli frissítés szintén RPC-hibára panaszkodott, a webes felületen pedig nem volt elérhető a Computer sablon. Mielőtt még nekiálltam „kézzel” generálni, átfutottam ezt is, itt is a már említett módszerek voltak felsorolva:

The “Advanced Certificate Enrollment and Management” white paper describes various methods for requesting certificates from an enterprise CA. For example, you can request certificates by using the Web-based CA interface, by creating .inf files that contain certificate information, by using the Certreq.exe utility, and by using the Certutil.exe utility.

Következett a kézi generálás a CertReq használatával. Ha egy új tanúsítványt hozunk létre, akkor alapnak elég ez:

[NewRequest]

Subject=”CN=computer.domain.hu”
KeyLength=1024
MachineKeySet=TRUE
Silent=TRUE

Ha már létezőt akarunk megújítani, akkor a

certutil -store my

paranccsal kilistázott tanúsítványokból (értelemszerűen nem az Archived! jelzéssel ellátottból) tudjuk kiolvasni azt az adatot, amit az alábbi két sor egyike tartalmaz (amit majd az .inf állományhoz kell illesszünk):

UseExistingKeySet=TRUE
KeyContainer=”ea725e035fb897b670fb28f41358ae5f_4a40ddf8-1ce7-4886-bf3d-a97870755888″

A kérelem tartalmát a certutil -dump newreq.req parancs segítségével tudjuk megnézni, ha viszont megvan a tanúsítvány, akkor a certreq –accept utasítással tudjuk importálni a cél-gépre.

A kérelem létrehozásakor egy Access denied hibaüzenetet fogadott, így a %AllUsersProfile%\application data\microsoft\crypto\rsa\machinekeys mappának minden állományán átállítottam a jogokat (Adminoknak full jog – valamiért nem örökölte). Ezután már a „bővített” kérést is elfogadta, mármint létrehozta a request állományt. A request-et viszont a CA továbbra sem fogadta el, a sablon hiányára vonatkozva (The request contains no certificate template information 0x80094801 (-2146875391). Denied by Policy Module 0x80094801).

Ha betettem a

[RequestAttributes]

CertificateTemplate=Computer

sorokat, a CA továbbra is beintett, de a Computer helyett Machine sablont kérve máris más jellegű hibaüzenet került elő.

(Mivel innentől egy másik irányba mentem el, leírom egy általános kérelem formáját:

[NewRequest]

Subject = “CN=computer.domain.hu”
KeySpec = 1
KeyLength = 1024
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0  

[RequestAttributes]

CertificateTemplate=Machine

Ezt tudjuk a mi igényünk szerint átszabni.)

Szóval a fenti próbálkozás kapcsán a The DNS name is unavailable and cannot be added to the Subject Alternate name. 0x8009480f (-214875377) hibaüzenet fogadott. Már kicsit kóválygott a fejem, így anélkül, hogy logikusan végig-gondoltam volna az értelmét, elindultam ebbe az irányba. Lefuttattam az alábbi parancsot:

CERTUTIL -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

utána kaptam (kiemelés tőlem):

SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\TTRootCA3\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

 Old Value:

  EditFlags REG_DWORD = 11014e (1114446)
    EDITF_REQUESTEXTENSIONLIST — 2
    EDITF_DISABLEEXTENSIONLIST — 4
    EDITF_ADDOLDKEYUSAGE — 8
    EDITF_BASICCONSTRAINTSCRITICAL — 40 (64)
    EDITF_ENABLEAKIKEYID — 100 (256)
    EDITF_ENABLEDEFAULTSMIME — 10000 (65536)
    EDITF_ENABLECHASECLIENTDC — 100000 (1048576)

New Value:

  EditFlags REG_DWORD = 15014e (1376590)
    EDITF_REQUESTEXTENSIONLIST — 2
    EDITF_DISABLEEXTENSIONLIST — 4
    EDITF_ADDOLDKEYUSAGE — 8
    EDITF_BASICCONSTRAINTSCRITICAL — 40 (64)
    EDITF_ENABLEAKIKEYID — 100 (256)
    EDITF_ENABLEDEFAULTSMIME — 10000 (65536)
    EDITF_ATTRIBUTESUBJECTALTNAME2 — 40000 (262144)
    EDITF_ENABLECHASECLIENTDC — 100000 (1048576)

CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

Ennek értelemszerűen akkor van értelme, ha a kérelmet kiegészítjük az alábbi sorral:

[RequestAttributes]
SAN=dns=abc.domain.hu&dns=ldap.domain.hu

De esetünkben nem ez volt a gond, így természetesen ez sem hozott megoldást.

Össze voltam zavarodva.

Megpróbáltam visszatérni a grafikus felületre, így ismét a webes igénylést vettem górcső alá. Jött az ötlet, miszerint másoljam le a Computer tanúsítvány-sablont (mert a CA-n mégiscsak ez volt a neve, nem Machine), s ez alapján hozzam létre az igényt. A Certificate Templates-en jobb klikk, másolás megtörtént, s ott átállítottam, hogy Subject Name fülön Supply in the request szerepeljen. A webes oldalon való megjelenéshez még szükséges egy New / Certificate template to issue. A probléma nem oldódott meg ezután sem…

Mondhatni szerencsére közbejött más intéznivaló, így ezt félbehagytam.

Csak arra nem gondoltam, ami a legkézenfekvőbb lett volna: a gép újraindítása. Ez ugyanis (mint időközben kiderült) megoldotta a problémát, kapott végre egy normális tanúsítványt (lehet, hogy az egész csak jogosultsági gond volt, amit már az elején megjavítottam?).

Az új tanúsítvány esetén még arra kell figyelni, hogy ISA lévén, még van további tennivalónk: az ISA konzolon, a Config / Networks / Internal / Web Proxy fülön a tanúsítványra rá kell mutatni.

Nem tartozik a témához, de menet közben begyűjtöttem pár OID-ot (amelyek itt vannak említve), pár használtabb:

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication
OID=1.3.6.1.4.1.311.20.2.2 ; Smart Card Logon

Egyéb hasznos certutil parancsok:

certutil -store my: a tanúsítványok parancssoros listázása és megjelenítése
certutil -viewstore my: a tanúsítványok grafikus listázása és megjelenítése
certutil -viewdelstore my: a tanúsítványok grafikus felületen történő törlése
certutil -delstore my <certid>:  a <certid> azonosítóval rendelkező tanúsítvány törlése

További olvasnivalók:

CA hibaüzenetek itt.

A Certreq szintaxisa, az inf állomány lehetséges mezői, típusai itt.

Kategóriák:PKI, Windows Server

Public Key Infrastructure (PKI) 2. rész

augusztus 10, 2011 2 hozzászólás

(folytatás innen)

Tanúsítvány kibocsátás

A Windows 2003 szerver három módon tud kibocsátani tanúsítványt: Auto, Web, Manual. Mielőtt még eldöntenénk, hogy melyiket válasszuk, nézzük meg, hogy ki mit tud:

Enterprise: AD integrált, a tanúsítványokat és a CRL-t is ott publikálja. Ők csak az AD-ban található felhasználóknak és számítógépeknek tudnak tanúsítványt kiállítani. Az AD-ban található adatok alapján dönti el, hogy jóváhagyja vagy elutasítja a kérelmet.

Mivel az Enterprise tanúsítványok az AD-ban kerülnek publikálásra, s például a felhasználói tanúsítványok a megfelelő fiókhoz köthetőek, ennek eredményeképpen egyes programok, mint például az MS Outlook automatikusan használ(hat)ják őket a levelek titkosítása során.

Az auto-enrollment csak akkor járható, ha a tanúsítványt igénylő és a vállalati CA közvetlenül kapcsolatot tud létesíteni.

Stand-alone: nem kell neki AD, emiatt viszont az összes olyan adatot meg kell adni, ami a kérelem elbírálásához szükséges. Alapértelmezés szerint ezek a kiszolgálók nem válaszolnak automatikusan a kérelmekre, de ez a beállítás módosítható.

Tanúsítvány-igénylés

Az automatikus tanúsítvány igénylés (ami csak Enterprise CA esetén használható, Windows Enterprise vagy Datacenter esetén) a tanúsítványok önálló igényléséről/megújításáról szól, házirendből szabályozva. Természetesen szükség esetén felhasználói beavatkozást is be lehet iktatni.

Mint szinte mindenhol, itt is lehetnek ügynökök. A „sorozó” ügynök más nevében kér tanúsítványt, tipikusan intelligens kártyák esetében használatos. Ugyanakkor az ilyen kártyáknál fokozottan kell figyelni, például ha titkosító tanúsítványt igénylünk, akkor biztosak kell legyünk abban, hogy a magán titkosító kulcs is megfelelő helyen legyen tárolva.

A kulcsok mentése a magán titkosító kulcsok biztos tárolását biztosítja, arra az esetre, ha titkosított adatot kell visszaállítani, de a kulcs elveszett. A kulcs tárolásának módját a sablonban tudjuk szabályozni, a kulcs-visszaállítás feladatát pedig kulcs-visszaállító ügynökök végzik.

Igénylés módja

Összegezve a fentieket, az igénylésünk típusa két dologtól függ: a kérést kiszolgáló CA típusa, valamint, hogy a kérelmező és a kiszolgáló közvetlenül tud-e hálózaton kommunikálni.

Ha Standalone CA-tól akarunk igényelni tanúsítványt, akkor három lehetőségünk van:

1. Certificates snap-in

2. Certreq eszköz

3. Webes felület

Enterprise CA esetén szintén használhatóak az előbbiek, de bejön egy negyedik lehetőség is, a házirend. Bármelyik esetben beállítható, hogy vagy automatikus válaszadás történjen, vagy egyéni elbírálás legyen minden esetben. Előbbi esetben a sablonon engedélyezni kell az AutoEnrollment jogot a kérelmezőnek.

4. Házirend esetén XP/2003 párostól adhatunk meg automatikus igénylést, felhasználónak és gépnek egyaránt. Viszont követelmény, hogy legalább V2 típusú sablonnal kell rendelkezzen az igényelt tanúsítvány.

Ki kicsoda?

Ha ki kell derítsük, hogy ki a CA (számítógépnév és/vagy CA-név), itt találunk megoldást. No meg arra is, hogyha arra vagyunk kíváncsiak, hogy az adott CA milyen típusú (önálló vagy vállalati, illetve gyökér vagy alárendelt): certutil –cainfo.

Az elméleti tudásunk bővítéséhez még a következő két cikk javasolt:

http://www.tech-faq.com/the-certificate-enrollment-process.html

http://technet.microsoft.com/en-us/library/cc962066.aspx

A következő rész már a konkrét probléma taglalása lesz…

Kategóriák:PKI, Windows Server

Public Key Infrastructure (PKI) 1. rész

augusztus 9, 2011 6 hozzászólás

Most, hogy (ismét) foglalkoztam a tanúsítványokkal, eszembe jutott egy régebbi történet, amely nagyjából le van írva, de nincs publikálva. Átnéztem, de mivel túl hosszúra sikeredett, ezért darabolva fogom bloggolni…

Tudom, a PKI olyan dolog, amit nem lehet soha teljesen megérteni (GT szavaival élve J), de legalább pár dolgot megpróbáltam tisztába tenni, hogy ne vaktában lövöldözzek.

Kezdjük az elmélettel.

Telepítés

Azt tudjuk, hogy a CA-t kétféle módon lehet telepíteni: Standalone vagy tartományba integrált Enterprise. A kettő közötti különbség: a vállalati (Enterprise) CA sablonok alapján dolgozik, támogatja az AD-ba integrált automatikus tanúsítvány-igénylést, valamint felhasználói tanúsítványok kibocsátására alkalmas. Az önálló (Standalone) CA mindezeket nem támogatja, ezért elsősorban Root CA vagy Policy CA feladatkörökre használják.

Bár nem teljesen egyértelmű, de a Windows SKU-ja sokat számít. Ugyanis a Standard verziók csak a Version 1 típusú sablonokat támogatják, nincs kulcs-archiválás (key-archiving), szerepkör szétválasztás (role separation) vagy automatikus igénylés. Mindezeket csak az Enterprise vagy Datacenter verziók biztosítják.

Itt találunk némi további pontosítást: a Standard SKU-ra is tudunk telepíteni Enterprise CA-t, de pl. nem tudjuk használni az automatikus igénylést. Enterprise CA esetén pedig a telepített gép tagja kell legyen egy tartománynak, de nem kell DC legyen.

Standalone tud más névvel is legenerálni tanúsítványt (pl. kinti név más, mint a belső, pl. Owa), az Enterprise viszont tud Autoenrollment-et, s AD-ba teszi a kész tanúsítványt.

Szerepkörök

A Windows 2003 és 2008 CA-k támogatják a szerepkör szétválasztást (role separation). Ezek az alábbiak:

CA Administrator: a CA-t kezeli és a tanúsítvány-sablonokat módosíthatja

CA Manager: Jóváhagyja a tanúsítvány-kéréseket és visszavonja a tanúsítványokat. Ugyanakkor joga van magán-kulcsok visszaállítására.

Auditor: A biztonsági eseménynapló megtekintésére jogosult

Backup Operator: A CA adatbázisának, konfigurációjának és kulcsainak mentését végzi

Tanúsítvány-listák (CRL, CTL)

Az egyik legfontosabb dolog a tanúsítvány lejártának ellenőrzése. Ezt a Windows 2003 a CRL (Certificate Revocation List)-en keresztül végzi, ennek a Delta-CRL verzióján keresztül. A Windows 2008 ezen kívül még támogatja az OCSP (Online Certificate Status Protocol)-t is.

A CTL (Certificate Trust List) a megbízható CA-knak a hash kivonatait tartalmazó aláírt lista, mely házirend segítségével kerül szétosztásra.

Sablonok

A tanúsítvány-sablonok határozzák meg a tanúsítványok tartalmi keretét és kiszolgálásuk menetét, például meg tudjuk határozni a CRL disztibúciós pontjainak elérését. Továbbá egy tanúsítvány-kezelőt is ki tudunk jelölni, aki a beérkező kéréseket jóváhagyja.

Most egy picit beszéljünk a különböző sablon-verziókról.

Version 1: Windows 2000-nél jelentek meg, nem módosíthatóak, kizárólag a hozzáférési jogokat tudjuk szabályozni.

Version 2: Windows 2003-nál lettek bevezetve, egyénileg konfigurálhatóak

Version 3: Windows 2008-nál hozták őket létre, támogatják az új Microsoft Crypto-API felületét, új titkosításokkal és hash algoritmusokkal.

Mint már említettük, csak az Enterprise vagy Datacenter SKU-k tudnak a V2 és V3 sablonokra épülő tanúsítványokat kibocsátani.

Kategóriák:PKI, Windows Server

Dell OMSA & Enterprise CA

augusztus 4, 2011 2 hozzászólás

Az új szerverek kapcsán felmerült bennem, hogy az OMSA tanúsítványa ne a Dell által generált, önaláírt tanúsítvány legyen, hanem a hálózatunkban is használt Enterprise CA által kiállított.

Alapértelmezésben nem tűnik nagy kunsztnak, de a végrehajtás során folyamatosan hibába ütköztem:

ERROR! Import of OMSA.cer failed. Try again.

Mikor már az agyam darabokban hevert, akkor kértem a Dell support segítségét. Kiderült, hogy nekik sem sikerül elsőre, így hosszas nyomozás következett, aminek a végeredményeképpen végül sikerült megetetni a tanúsítványt az OMSA-val.

Szóval akkor következzen a menet:

       Generate a new certificate: létrehozunk egy másik önaláírt tanúsítványt, olyan adatokkal, amelyet mi szeretnénk (pl. Alias: Omsa, CN=szervernév) – úgy tűnik, ezt a lépés, bármennyire ésszerűtlen, szükséges. Amire érdemes figyelni: alapból az OMSA telepítő az asztalra kitesz egy parancsikont, amely a szerver Netbios-nevével tölti be az OMSA-t. Ha ez megfelel, akkor értelemszerűen a CN is ez a rövid név legyen – ha nem, akkor a CN-be olyan értéket írjunk, amelyet a böngésző sorában fogunk használni az OMSA-ra való hivatkozáskor – ellenkező esetben a böngésző szóvá fogja tenni az eltérést J

A tanúsítvány generálása során, ha ugyanazt az Alias-t akarjuk felhasználni, mint a jelenlegi, akkor érdemes előbb egy másik Alias-al végigjátszani a folyamatot (az a tanúsítvány úgyis el lesz dobva), majd az „éles” alias-al a helyes adatokat megadni.

       Certificate maintenance: létrehozunk egy tanúsítvány aláírási kérelmet (CSR) – ekkor gyakorlatilag a meglévő tanúsítvány adatait felhasználva létrehozzuk azt a kérelmet, amely alapján a CA ki tudja majd állítani az új tanúsítványt

       a kérelmet eljuttatjuk a CA-nak, pl. webes felületen (Request Certificate/Advanced Certificate Request/Submit a certificate request…), kiválasztjuk a Web Server sablont, majd a kész tanúsítvány esetén letöltjük B64 kódolással a tanúsítvány-láncot.

       Import a certificate chain: betöltjük, majd aktiváljuk az előző lépésben elmentett láncot

Ugye nem is nehéz? J Amire kell figyelni: ha az OMSA harmadik pontjában található Import root certificate menüpontot akarjuk használni, akkor a CA tanúsítványát megadhatjuk neki .cer formátumban, de az „Update and proceed” gomb lenyomása után a saját tanúsítványt PKCS#7 formátumban kell megadni (tehát mint a tanúsítvány-lánc betöltésénél). Ezután szintén aktiválni kell – ez néha hibára szokott futni, de újból kell próbálni.

Ha bármit módosítani akarunk (pl. rövid névről át akarunk térni FQDN-re, majd vissza), akkor hiába van elmentve a tanúsítvány-láncunk, nem fogjuk tudni betölteni – inkább érdemes elölről kezdeni a folyamatot.

Ha egy korábbi állapotra akarunk visszatérni, akkor esetleg még a C:\Program Files (x86)\Dell\SysMgt\iws\config útvonalon található Keystore.db állomány előző mentéseivel (bak) érdemes játszani.

u.i. Ja, s még véletlenül se próbálja meg senki a 6.4-es verzióval, időnként fehér képet fog kapni a folyamat során (egy füles során megtudtam, hogy ez az OMSA-nak egy ősrégi hibája, ami hivatalosan nem elismert, de amit a 6.5-ben javítottak). A 6.5-re váltás sem jó, ha frissítéssel történik, inkább el kell távolítani a régit, s úgy feltenni az újat…

u.i.2. Ha ugyanezt az IDrac tanúsítványával akarjuk eljátszani, akkor ott egyszerűbb dolgunk van, ott ugyanis egyből a CSR-el kezdjük. De vagy kapcsoljuk be az IE9-en a kompatibilitási módot, vagy ne azzal hajtsuk végre a műveletet…

Kategóriák:General, PKI, Windows Server

Cert install 4.

február 18, 2010 Hozzászólás

Az előző (1. rész, 2. rész, 3. rész) részek folytatása, egyben befejezése.

5. Powershell segítségével, emelt jogokkal:

 

$filename = “\ServerShareverisign.cer”

 

[Reflection.Assembly]::Load(“System.Security, Version=2.0.0.0, Culture=Neutral, PublicKeyToken=b03f5f7f11d50a3a”)

 

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($filename)

 

$store = New-Object System.Security.Cryptography.X509Certificates.X509Store([System.Security.Cryptography.X509Certificates.StoreName]::Root,[System.Security.Cryptography.X509Certificates.StoreLocation]::LocalMachine)

 

$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite);

 

$store.Add($cert);

 

Pirossal jelöltem a két változó paramétert, a tároló opciói: a My, Root, a végén a tárolóhely: LocalMachine helyett CurrentUser.

Kategóriák:General, PKI

Cert install 3.

február 17, 2010 Hozzászólás

Előző (1. rész, 2. rész) sorozatom folytatása:

3. CapiCom segédeszköz használata

 

Egy külső, ingyenes segédprogramról van szó, amit erről linkről lehet letölteni. A gond viszont vele az, hogy tesztelés során nem sikerült csendes módon telepítenem a Root-ba a tanúsítványt, így nem sokáig nyúztam. Szomorú

 

Hogy kicsit pontosítsunk a dolgon, nem szükséges a teljes SDK. Ezért, ha egy gépre telepítettük, akkor

  1. a CAPICOMx86 könyvtárból másoljuk ki a Capicom.dll-t, ugyanis ez nekünk bőven elég a továbbiakban. A használathoz értelemszerűen előbb regisztrálni kell, ehhez pl. a %SystemRoot%System32 könyvtárba másoljuk, majd a regsvr32 /s %SystemRoot%System32Capicom.dll parancs segítségével izzítjuk (a /s csendes telepítést jelent). Használat után a regisztráció megszüntethető a regsvr32 /u /s %SystemRoot%System32Capicom.dll paranccsal.
  2. ha nem mi akarjuk megírni az importáló modult, akkor a CAPICOMsamplesvbs könyvtárban levő CStore.vbs-t is érdemes kimásolni, hiszen ezt már csak paraméterezni kell. Kacsintó

Az eszköz használatára természetesen szükségünk lesz a WSH-ra (Windows Scripting Host), helyi gépen, viszont a fentieket bárhol tárolhatjuk, akár megosztáson is. Akkor nézzük a paramétereket.

 

Tanúsítvány telepítéséhez elég az „import” paraméter, illetve a tanúsítványt tartalmazó állomány neve, törlésnél viszont figyeljünk a –delkey kapcsolóra: enélkül csak a tanúsítvány kerül törlésre, a privát kulcs megmarad.

 

Tároló helye (StoreLocationName, -l kapcsoló):

 

CU (Current User): alapértelmezett

LM (Local Machine)

AD (Active Directory)

SC (Smart Card)

 

Tárolók (StoreName, -s kapcsoló):

 

My (alapértelmezett):  Personal, magyarul Személyes
CA: Intermediate Certification Authorities, magyarul Közbenső szintű hitelesítésszolgáltatók
Root:  Trusted Root Certification Authorities, magyarul Megbízható legfelső szintű hitelesítésszolgáltatók

 

Így nekünk a következő parancsot kell lefuttatnunk: cscript CStore.vbs import -s Root verisign.cer

 

Ha bejelentkezési állományként képzeljük el, akkor így nézne ki:

 

@echo off
set DllFile=\servershareCapicom.dll
set CstoreFile=\servershareCStore.vbs
set CertFile=\servershareverisign.cer

rem Skip if Capicom is permanently installed
regsvr32 /s %DllFile%

rem Removing previous certificate
cscript /nologo %CstoreFile% delete -delkey -noprompt -subject VeriSign

rem Import the certificate
cscript /nologo %CstoreFile% import %CertFile%

rem Skip if Capicom is permanently installed
regsvr32 /u /s % DllFile%

 

Általános hibaüzenetek:

ActiveX component can’t create object: ‘CAPICOM.Store’: CAPICOM.dll nem lett regisztrálva.
The specified network password is not correct: A tanúsítványhoz rossz jelszót adtunk meg.
0 certificate(s) successfully imported/deleted: A tanúsítvány érvénytelen, vagy már létezik/törölve lett.

 

Kategóriák:General, PKI

Cert install 2.

február 16, 2010 Hozzászólás

Folytatom az előző cikkem:

2. Certutil használata

 

A parancs használatát a súgó leírja, mi a következő két opciót fogjuk használni:


-addstore: hozzáadja a tanúsítványt a tárolóhoz
-f: felülírja a már meglévőt

 

Tároló helye:

enterprise: a helyi számítógép vállalati beállításjegyzék-tanúsítványtárolójának használata
user: a HKEY_CURRENT_USER kulcsainak vagy tanúsítványtárolójának használata
GroupPolicy: a csoportházirend tanúsítványtárolójának használata

 

Tárolók:

Ennél a parancsnál a tanúsítványtároló neve van a legkevésbé részletezve (viszont a –store /?-el pár példa lekérdezhető). Ez a következők közül kerülhet ki:

ca (alapértelmezett): Intermediate Certification Authorities, magyarul Közbenső szintű hitelesítésszolgáltatók
my:  Personal, magyarul Személyes
root:  Trusted Root Certification Authorities, magyarul Megbízható legfelső szintű hitelesítésszolgáltatók

 

Létrehozhatunk egyéni tárolókat is, például spc:  Software publisher certificates.

 

Ennek alapján a futtatandó parancsunk az alábbi:

 

certutil -f -enterprise -addstore root “.VeriSign.cer”

 

Természetesen, mint említettem, ha a fenti sort akarjuk futtatni, akkor emelt szintű jogokkal kell megtegyük. Érdekességképpen, ha a tároló helye –user, akkor rákérdez a telepítésre, ha –enterprise, akkor nem kérdez (mindkettő root tároló esetén).

 

Kategóriák:General, PKI