A kérdés bővebben

A cégünknél felmerült az igény arra, hogy saját PKI rendszerünk legyen. Először kísérleti jelleggel próbálkoznánk vele. Opensource alapon kellene a tesztelést elvégeznünk, de az is lehet, hogy az éles rendszert is abban valósítanánk majd meg.

Milyen javaslatok – esetleg ellenjavallatok – vannak a dologgal kapcsolatban, és milyen szoftvereket kellene használnunk?

Válasz

Én OpenSSL binárist használnék parancssorból, de nagy mennyiségű tanúsítványszám esetén ez hamar áttekinthetetlenné válna, így valamilyen grafikus (pl. XCA) vagy webes (pl. PHPki, openWebPKI) alkalmazáskiterjesztést kellene választani abban az esetben, ha a kibocsátandó tanúsítványok száma nagy, és visszavonások is szükségesek.

A szervezet méretétől és strukturáltságától függően lehet választani egyetlen CA-t, amivel minden tanúsítványt hitelesítünk, vagy egy root-CA-t, és több, szervezet szintű sub-CA-t. Ez utóbbi esetben a root-CA-val csak sub-CA-kat hitelesítünk, így minden tanúsítványról kideríthető, hogy mely szervezethez tartozik, vagy milyen célból lett kiadva (pl. VPN).

A titkosítás mértéke legyen legalább 2048 bites, a lejárati idő pedig se nem túl hosszú, se nem túl rövid legyen (ezt a belső folyamatok életciklusa is meghatározza). Minél magasabb szintű egy tanúsítvány, annál hosszabb lejárati időtartamra lesz szükség.

Nagyon fontos, hogy amikor a legfelsőbb szintű tanúsítvány lejár, akkor az összes olyan tanúsítvány érvényét veszti, amit avval hitelesítettünk.

Egy példa:
A root-CA élettartama 10 év, a sub-CA-ké 5 év, a kibocsátott tanúsítványoké 1 év. Indulás után 4,5 év múlva új ügyféltanúsítvány kell, de csak olyan sub-CA-nk van, amivel maximum fél évig lesz az érvényben. Emiatt célszerű új sub-CA-t kiállítani, és az új kérést avval hitelesíteni.

Tehát új sub-CA fog kelleni akkor, amikor már nem tudunk vele teljes élettartamot garantálni a tanúsítványnak. És ez a root-CA-ra is igaz, azaz - a fenti példa vonatkozásában –, ha kevesebb, mint öt év van vissza, és új sub-CA-t kéne kiadnunk, akkor új root-CA-ra lesz szükség.

A szervezet böngészőinek és rendszereinek a tanúsítványtárába a root-CA-t kell csak importálni, így az összes tanúsítvány hiteles lesz a szervezet eszközein – azonban egyes szolgáltatások, amik SSL-t használnak, a tanúsítványbeállításoknál igényelni fogják a sub-CA-k jelenlétét is (pl. webszerverek).

Ha a levelezésben SMIME hitelesítést vagy titkosítást kell alkalmazni, az ügyfeleknek az egyéni publikus kulcsokon felül érdemes a root- és sub-CA-k publikus kulcsát is megadni, hogy a tanúsítványhibákat elkerüljük.

A leglényegesebb azonban az, hogy soha ne hitelesítsünk önaláírt tanúsítványok segítségével olyan szolgáltatásokat, amiket nem szervezeten belül használunk (publikus weboldalak, levelezőszerverek, stb.). Ilyen célra mindig szerezzünk be harmadik fél által hitelesített tanúsítványokat – pl. hazai vonatkozásban a NetLock foglalkozik ilyesmivel.