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…

Forrás: https://asteriksz.wordpress.com