Expirace interního kořenového certifikátu

[czechsys]

Cau,

mam interni CA kde bude expirovat root certifikat behem tohoto roku. Konfigurace je Root V1 -> Intermediate V1 -> Leaf V1 zivotnosti do Datum V1. Budu to poprve menit a jeste na stovkach systemu.

V ramci oddeleneho pokusu, ktery nema vliv na aktualni konfigurace, jsem udelal prodlouzeni "renewal" s tim, ze jsem na zkousku zvolil nahrazeni. Nahradil jsem tedy postupne od korene certifikaty:
Root V1 -> Root V2
Intermediate V1 -> Intermediate V2
Leaf V1 -> Leaf V2
(ostatni certifikaty v celem strome zustaly beze zmeny na V1)

Datum generovani je od Datum V2, kde Datum V2 < Datum V1 a zaroven do V2 je daleko za zivotnosti V1.

Nasadil jsem Intermediate V2 + Leaf V2 do jednoho testovaciho webu. Na klientovi jsem mel Root V1, certifikat byl akceptovan jako validni (Root V1 -> Intermediate V2 -> Leaf V2), coz jsem necekal. Chtel bych si overit, ze to spravne chapu - prodlouzeni(nahrazeni) Root + Intermediate + Leaf certifikatu v retezci zachovava duveryhodnost celeho celeho stromu vuci korenovemu certifikatu ? Tedy:

a] pokud klient ma Root V1, bude duverovat i systemum, ktere nasadi komplet V2?
b] pokud klient ma Root V2, bude duverovat i systemum, ktere jsou momentalne na V1?

Pokud by platily body a] a b] najednou, tak by to velmi usnadnilo prechod na V2.

Jo a kdyby to nekoho zajimalo, Safari neakceptoval Leaf V2 s zivotnosti 5Y, akceptoval jen s zivotnosti 2Y. Tedy, omezeni platnosti na interni certifikaty na 825D.

[Reklama]

[messagebus]

Nevim, co presne myslite tim "renewal nahrazenim", ale pokud se "Issuer", "Subject Key Identifier", "Authority Key Identifier" a hlavne klice CA (at ut Root ci Intermediate) nezmenily, muzete mit dva (i vice) soucasne platnych Root a Intermediate CA certifikatu, stale jde o stejnou CA a system si je pro dany certifikat najde, overi podpisy (a interval platnosti) a sestavi retezec az ke korenovemu CA v trusted store at uz jde o operacni system ci firefox apod. Takze zkontrolujte vyse uvedene a za predpokladu nezmenenych klicu plati a) i b) z vaseho dotazu soucasne.

A jeste pro jistotu: keyID z "Authority Key Identifier" (pokud existuje) Leaf certifikatu musi byt stejne jako "Subject Key Identifier" certifikatu CA vydavatele.

A vezmete prosim v uvahu, ze nejsem Buh a radeji si to jeste overte a otestujte Ale principialne to tak je.

[czechsys]

ad "renewal nahrazenim"

Delam to v XCA. Pokud nepouziji nahrazeni, vytvori se certifikat V2 vedle V1 na stejne urovni stromu. Certifikacni struktura podepsana danym V1 tak zustane napojena na V1. Pokud pouziji nahrazeni, tak V1 je nahrazen novym V2 a struktura se propoji na dany V2.

[alfi]

Nedávno jsem to řešil taky - vedle Root V1 je třeba nastavit Root V2 a mezi sebou je nejde přímo propojit.

Root V2 podepíše novou Intermediate a Leaf, do všech strojů-serverů se dočasně nasadí současně Leaf V1 i Leaf V2. Po přidání Root V2 do všech klientů se může Root V1 zrušit. Leaf V2 může být spolupodepsaný i Root V1 nebo Intermediate-V1, ale nic moc to nepřinese - stejně je potřeba nové podpisy pro Leaf V2 změnit na každém serveru. Důležité je začít včas (reminder do kalendáře za 10 let ) - po expiraci Root V1 a bez nasazení Root V2 se to celé rozbije

certifikat byl akceptovan jako validni (Root V1 -> Intermediate V2 -> Leaf V2)

Pokud je Intermediate V2 (spolu)podepsán Root V1, tak to fungovat bude. Ale jen po dobu platnosti Root V1

[Filip Jirsák (forum)]

Postup, který popisuje messagebus, je nejjednodušší na výměnu. Když zachováte klíč a Subject Key Identifier kořenového certifikátu, jenom mu prodloužíte platnost (tj. vydáte nový certifikát s delší platností, ale stejným klíčem a názvem), všechny certuifikáty podepsané původním rootem budou podepsané i novým rootem – takže intermediate certifikáty nemusíte měnit. Nevýhodou je, že se nemění klíč kořenové autority, tedy zejména nemůžete klíč zvětšit.

Tj. celé schéma by pak vypadalo takto:

Kód: [Vybrat]

R1(k1) --> I1 --> L1
R2(k2) ----^

Podstatou je, že R1 i R2 mají stejný klíč a stejný Subject Key Identifier.


Postup, který naznačil alfi (ale pak je popsaný špatně) je vytvořit úplně novou autoritu, nezávislou na původní. Klienti pak musí v době přechodu důvěřovat oběma kořenovým autoritám, protože některé servery budou mít už certifikáty vydané novou autoritou a jiné ještě starou. V tomto případně důrazně doporučuji novou autoritu pojmenovat jinak, než se jmenuje původní – bývá zvykem přidávat do názvu rok nebo měsíc a rok vytvoření. Když to tak neuděláte a budete mít dva certifikáty se stejným jménem, ale různým klíčem, budete pak neustále řešit, od které autority je vydaný který certifikát – protože ze samotného vydaného certifikátu to na první pohled nepoznáte.

Kód: [Vybrat]

R1(k1) --> I1(k2) --> L1
R2(k3) --> I2(k4) --> L2


Nebo se dá udělat kombinace obojího – vytvořit nový kořenový certifikát R2 s novým klíčem, jím podepsat I2, který ovšem bude mít stejný klíč a SUbject Key Identifier, jako má I1:

Kód: [Vybrat]

R1(k1) --> I1(k2) --> L1
R2(k3) --> I2(k2) ----^



Případně je možnost vytvořit novou autoritu, ale její kořenový certifikát (třeba dočasně) podepsat původním kořenovým certifikátem. Takhle dlouho fungoval Let's Encrypt – jejich kořenový certifikát měli podepsaný jinou autoritou, která měla certifikát na větším množství systémů. Překazit by to mohlo například to, pokud byste na původním kořenovém certifikátu měl omezenou délku certifikační cesty.

Kód: [Vybrat]

R1(k1) --> I1(k2) --> L1
  \------> R2(k3) --> I2(k4) --> L2


[Reklama]

[alfi]

Za mně to v obou případech znamená do všech klientů dostat R2 mezi důvěryhodné a do všech serverů dostat certifikáty (spolu)podepsané čímkoliv od R2, dřív než přestane platit R1. (já jsem to nestihl, tj. u mně to bylo jedno). Vždycky jde znovu podepsat něco z I1, L1, něčím z R2 nebo I2, L2 něčím z R1 pro usnadnění přechodu - a instalaci R2 tak rozložit v čase. Ale vždycky je třeba sáhnout do všech serverů i klientů

 

Nebo se dá udělat kombinace obojího – vytvořit nový kořenový certifikát R2 s novým klíčem, jím podepsat I2, který ovšem bude mít stejný klíč a SUbject Key Identifier, jako má I1:

Kód: [Vybrat]

R1(k1) --> I1(k2) --> L1
R2(k3) --> I2(k2) ----^


[Filip Jirsák (forum)]

Za mně to v obou případech znamená do všech klientů dostat R2 mezi důvěryhodné … dřív než přestane platit R1.

Ano. Bez toho se neobejdete – pokud spoléhající se software kontroluje platnost certifikátů považovaných za důvěryhodný kořen. Některý to dělá, některý ne, takže obecně musíte počítat s tím, že potřebujete platný kořenový certifikát CA.

a do všech serverů dostat certifikáty (spolu)podepsané čímkoliv od R2, dřív než přestane platit R1.

Obecně nikoli. Pokud vytvoříte úplně novou nezávislou CA, pak musíte vyměnit i koncové certifikáty. Pokud ale prodloužíte platnost kořenového nebo mezilehlého certifikátu (tj. vydáte nový certifikát se stejným klíčem), koncové certifikáty měnit nemusíte – měníte je podle konce jejich platnosti. (Pokud jste ovšem vydával koncové certifikáty s koncem platnosti oříznutým dle CA, budete je muset vyměnit stejně.)

Vždycky jde znovu podepsat něco z I1, L1, něčím z R2 nebo I2, L2 něčím z R1 pro usnadnění přechodu - a instalaci R2 tak rozložit v čase. Ale vždycky je třeba sáhnout do všech serverů i klientů

Není potřeba vždy podepisovat certifikáty nově – pokud jen prodloužíte platnost podepisujícího certifikátu (CA), certifikáty vydané tou CA nevydáváte znovu.

Je potřeba si uvědomit, že certifikát je podepsaný veřejným klíčem autority, ne celým certifikátem. Takže když máte jeden veřejný klíč ve více certifikátech CA (s různou platností), koncové certifikáty jsou podepsané všemi těmi certifikáty CA se stejným klíčem. Koncový software by se měl chovat tak, že za platný certifikát považuje takový, od kterého vede alespoň jedna certifikační cesta k nějakému certifikátu, kterému důvěřuje.

Samozřejmě ale pokud máte koncové certifikáty s platností oříznutou podle kořenového certifikátu, prodloužení kořenového certifikátu vám nepomůže. Těm koncovým certifikátům pořád skoční platnost tak, jak mají v sobě uvedeno.

(já jsem to nestihl, tj. u mně to bylo jedno)

V ideálním světě se přechod dělá tak, že začnete ještě dřív, než je období, na které certifikáty vydáváte. Takže když vydáváte certifikáty s platností na rok, začnete nejpozději rok před koncem staré autority vydávat certifikáty už z nové autority. Tj. novou autoritu musíte vytvořit třeba už rok a půl předem. Pak máte třeba 5 měsíců na to rozdistribuovat všude nový kořenový certifikát. Potom rok a měsíc předem před koncem starého certifikátu začnete vydávat certifikáty už jen z nové autority. V tu chvíli nejnovější certifikáty vydané starou autoritou expirují dřív, než expiruje samotná autorita – a nové už nevznikají. Měsíc před expirací staré autority už vyexpirují všechny certifikáty jí vydané, takže expirace samotné autority už nic neovlivní. (Ten měsíc navíc tam je jako rezerva – kdybyste začal vydávat certifikáty z nové autority a narazil na nějaký problém, máte ještě měsíc na to to vyřešit.)

[czechsys]

Nevim, co presne myslite tim "renewal nahrazenim", ale pokud se "Issuer", "Subject Key Identifier", "Authority Key Identifier" a hlavne klice CA (at ut Root ci Intermediate) nezmenily, muzete mit dva (i vice) soucasne platnych Root a Intermediate CA certifikatu, stale jde o stejnou CA a system si je pro dany certifikat najde, overi podpisy (a interval platnosti) a sestavi retezec az ke korenovemu CA v trusted store at uz jde o operacni system ci firefox apod. Takze zkontrolujte vyse uvedene a za predpokladu nezmenenych klicu plati a) i b) z vaseho dotazu soucasne.

A jeste pro jistotu: keyID z "Authority Key Identifier" (pokud existuje) Leaf certifikatu musi byt stejne jako "Subject Key Identifier" certifikatu CA vydavatele.

A vezmete prosim v uvahu, ze nejsem Buh a radeji si to jeste overte a otestujte Ale principialne to tak je.

Tak zkouseno, prodlouzeni (s nahrazenim za puvodni certifikat v XCA) Root, Intermediate, Leaf a dodrzeni:

Kód: [Vybrat]

A jeste pro jistotu: keyID z "Authority Key Identifier" (pokud existuje) Leaf certifikatu musi byt stejne jako "Subject Key Identifier" certifikatu CA vydavatele.

Toto bylo dodrzeno. Musel jsem jeste v XCA pri prodlouzeni nastavit, aby "serial" byl identicky, nebot byl soucasti keyID.

Pak otestovano:
Klient s Root V1 akceptoval vzdalenou sluzbu s Intermediate V2 + Leaf 2 jako validni.
Klient s Root V2 akceptoval vzdalenou sluzbu s Intermediate V1 + Leaf 1 jako validni.

Tedy v tomto pripade lze primo nahradit veskere vyskyty V1 za V2, aniz by bylo nutno nejdrive instalovat Root V2 na kazdem serveru v infrastrukture. Jen je skoda, ze nemuzu primo prejit na ecdsa, par serveru s omezenou podporou tu jeste je a uplne se mi nechce riskovat problemy.