Archívum

Archive for the ‘PKI’ Category

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:

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