Procedura znovupodepsání kořenového zprostředkujícího certifikátu třídy 3

Zde je navrhovaná procedura pro generování nového certifikátu třídy 3 s ne-MD5 haš algoritmem. Důvodem k tomu je, že od června 2011 Mozilla odmítne přijmout jakékoli certifikáty (nepodepsané samy sebou), které jsou podepsány MD5. Tato procedura je v podstatě obnovením certifikátu třídy 3 a byla testována na testovacím serveru týmu Software Assessment Team. https://cacert1.it-sls.de

Procedura musí být vykonána u podepisujícího. Napřed uvedu proceduru krok za krokem bez vysvětlení, pak podám vysvětlení ke každému kroku.

V konfiguračním souboru "/etc/ssl/openssl-ca.cnf" změňte hodnotu nastavení "my_policy_oid" na "1.3.6.1.4.1.18506" (řádek 7). Viz OidAllocation.
Zálohujte starý certifikát třídy 3 (např. zkopírováním "cp /etc/ssl/class3/cacert.crt /etc/ssl/class3/cacert_md5.crt")
Generujte žádost o podpis (CSR) pro třídu 3 (pokud už existuje, přeskočte další krok): jděte do adresáře "/etc/ssl/" a proveďte "openssl req -config openssl-ca2.cnf -out class3/cacert.req -new -key class3/cacert.pem". Po dotazu zadejte heslo privátního klíče certifikátu třídy 3. Všechny dotazy na organizaci atd. jen potvrďte klávesou Enter.
Generujte ze žádosti podepsaný certifikát: "openssl ca -config openssl-ca.cnf -in class3/cacert.req -out class3/cacert.crt -notext -days 3650 -md sha256 -extensions v3_ca" (na 10 let). Vyžádá si heslo k privátnímu klíči kořenového certifikátu. Po ověření, že vytištěné informace jsou správné, je možno potvrdit dotaz, zda má být operace provedena.
Ověřte, že vygenerovaný certifikát je podobný starému (např. porovnáním výstupu z "openssl x509 -text -noout"). Je velmi důležité, aby se řádky "Subject" (předmět) a veřejný klíč RSA přesně shodovaly. Může se změnit:
- * Pořadové číslo
- * Algoritmus podpisu (nyní by měl být "sha256WithRSAEncryption")
- * Platnost
- * X509v3 identifikátor klíče předmětu (Subject Key Identifier)
- * X509v3 identifikátor klíče autority (Authority Key Identifier)
- * URL zásad CA (pro Netscape)
- * Komentář (pro Netscape)
- * Podpis
Zkopírujte nový certifikát na nějaké médium, abychom ho mohli později použít
Právě v tomto bodě může podepisující z nějakého důvodu uváznout (podívejte se na chyby do log-souborů a nohup.out). Na testovacím serveru se to stalo. Nevím, čím to bylo, ale zastavil jsem podepisovatele [robota] a komunikační[?] modul (CommModule) webové databáze ("/etc/init.d/commmodule stop"), odstranil jeho pracovní adresář ("rm -r <cesta_k_podepisovateli>/CommModule/work/"), odstranil soubory *.crl.patch ve webové databázi ("rm /home/cacert/www/www/class3-revoke.crl.patch /home/cacert/www/www/revoke.crl.patch") a znovu restartoval oba konce.
Použití. Je hodně míst, kam je nutno uložit nové "otisky prstů" (formuláře CAP, stránka kořenových certifikátů, materiál pro marketing, atd.), takže je vhodné vyčkat s nasazením několik dní, připravit si záplaty pro všechna relevantní místa (to nelze udělat bez znalosti nových "otisků prstů", což je opravdu těžké udělat předem) a pak je nasadit všechny najednou. Nasazení by mělo vypadat takto: uložit, jak je, do /home/cacert/www/www/certs/class3.crt, potom "openssl x509 -in /home/cacert/www/www/certs/class3.crt -outform DER -out /home/cacert/www/www/certs/class3.der" a "openssl x509 -in /home/cacert/www/www/certs/class3.crt -text -out /home/cacert/www/www/certs/class3.txt"

A zde jsou vysvětlení ke každému kroku:

Uvedený OID (Object ID, identifikátor objektu) je falešný (pokud nebudeme mít co do činění s Kerberosem). Hodnota 1.3.6.1.4.1.18506 je naše vlastní báze OID (viz OidAllocation) a není optimální, možná by byla lepší hodnota 1.3.6.1.4.1.18506.2.3.1, ale pak by zase starý certifikát měl také původní hodnotu a myslím, že by stejně žádný klient neimplementoval tyto zásady (protože je to pekelně komplikované), takže raději použijme starou hodnotu.
<prázdné>
Správné hodnoty údajů Organizace atd. by již měly být předdefinovány v konfiguračním souboru.
Předpokládám, že životnost 10 let je zde v pořádku. Starý certifikát měl delší životnost, ale protože stejně chceme přejít na jiné kořenové certifikáty, nastavme termín. Zvolil jsem SHA-256 místo SHA-1, protože ve SHA-1 jsou známé závady, které nejsou dosud kritické, ale nechceme, abychom to celé museli dělat znovu za pár let. Mohli jsme také použít SHA-512.
Předmět a veřejný klíč musejí zůstat stejné, protože jinak prostě nemůžeme pokračovat v podepisování CRL (seznamu odvolaných certifikátů) pro staré certifikáty a také by ty staré certifikáty nemuselo jít ověřovat. Pořadové číslo se mění, protože pořadová čísla v rámci CA musí být jedinečná. Mění se algoritmus podpisu (Signature Algorithm) - kvůli tomu se to celé dělá. Platnost se mění, protože certifikát je platný od aktuálního data (tj. data, kdy byl vydán). Položky: X509v3 identifikátor klíče předmětu (Subject Key Identifier), X509v3 identifikátor klíče autority (Authority Key Identifier), URL zásad CA pro Netscape a komentář pro Netscape ve starém certifikátu nebyly, ale rozhodl jsem se je přidat do nového, protože jinak by se toho v souboru openssl-ca.cnf muselo změnit více, nebudou překážet (jsou také v kořenovém certifikátu), a mít identifikátory je užitečná vlastnost (budeme-li někdy chtít provést změnu klíče, pomohou identifikátory klientům zvolit, který certifikát použít - starý nebo nový, pro ověření certifikátu koncového uživatele).
<prázdné>
Opravdu nevím, co způsobilo popsané zaseknutí, snad to byl postranní efekt nějaké jiné práce, kterou jsem dělal simultánně.
Nejdůležitějším místem je stránka kořenových certifikátů, e-mailových doplňků a formulářů CAP. Naštěstí většina formulářů CAP a e-mailových doplňků, pokud vím, obsahuje pouze kryptografický otisk ("otisk prstů") kořenového certifikátu třídy 1, ale jsou také pravděpodobně některá umístění, kam jsem se nepodíval. Musíme také napsat něco do blogu, napsat oznámení do seznamu adresátů a všemožných jiných komunikačních kanálů. Gále musíme sdělit všem majitelům serverových certifikátů, že by měli změnit své řetězové soubory (nevím, zda je nutná nějaká akce i pro e-mailové certifikáty) a ovšem všichni uživatelé, kteří importovali zprostředkující kořenový certifikát třídy 3, by si ho měli aktualizovat. Jinak možná uvidí v červnu 2011 podivná chybová hlášení.