Hodně se o tom mluví již nějakou dobu, takže asi každý ví, že se certifikáty využívající pro podpis hashovací algoritmus SHA-1 (Secure Hash Algorithm 1) začínají označovat jako nebezpečné. Velké společnosti (a výrobci webových prohlížečů) se domluvili a budou omezovat podporu certifikátů s SHA-1. Zjednodušeně řečeno by všechny důvěryhodné CA měly od 1. 1. 2016 vydávat certifikáty s SHA-2 a od 1. 1. 2017 by certifikáty s SHA-1 neměly být podporovány. Podrobnější informace od MS Windows Enforcement of Authenticode Code Signing and Timestamping.
Nejvíce kontroluje certifikáty, včetně certifikačního řetězce, Google Chrome. Pokud má certifikát konec platnosti po roce 2016 a on, nebo jeho autorita, využívá SHA-1, tak je označen jako nebezpečný (varování je i u konce platnosti v roce 2016).
O tom, zda je SHA-1 opravdu nebezpečný, zde nebudeme diskutovat. Horší mi přijde situace se zranitelnými protokoly (jako je SSL 3) a slabými šiframi (které využívají třeba DES, MD5), které by prohlížeče měly spíše blokovat (něco opravdu blokují). Otázka je také podpora SHA-2 v různých OS a aplikacích. V dnešní době by ale obecně neměl být problém.
Pokud využíváme interní certifikační autoritu od společnosti Microsoft, tak je nejvyšší čas se těmto změnám přizpůsobit. Naštěstí se přechod dá provést docela jednoduše a rychle, s využitím stávajícího řešení a zachováním zpětné kompatibility. Celý problém bychom mohli rozdělit na tři kroky, které mohou být nezávislé.
- přepnutí hash algoritmu na autoritě pro vystavování certifikátů
- vystavení nového certifikátu pro certifikační autoritu
- distribuce nového CA certifikátu a odstranění původního na klientech
V článku vycházíme z topologie s dvoustupňovou hierarchií (two-tier) CA (Certification Authority). Máme standalone offline Root CA na samostatném Windows serveru. Ta vystavila certifikát pro Intermediate CA, která je integrována do Active Directory . A tato vystavuje uživatelské i serverové certifikáty podle různých šablon.
Přepnutí hash algoritmu pro vystavování certifikátů na SHA-2
Ověření aktuálního algoritmu a poskytovatele
Pokud máme starší certifikační autoritu, tak patrně využívá hashovací algoritmus SHA-1. Jaký algoritmus používáme, se můžeme podívat v MMC SnapInu Certification Authority, když klikneme pravým tlačítkem na naši autoritu a zvolíme Properties. Na záložce General v části Cryptographic settings vidíme používaný Hash algorithm. MS CA používá pro všechny certifikáty stejný algoritmus (nemůžeme některé vystavovat s SHA-1 a jiné s SHA-2).
Zároveň zde vidíme položku Provider. Je důležité, aby zde bylo Microsoft Software Key Storage Provider (KSP) nebo Microsoft Smart Card Key Storage Provider. To jsou Cryptography Next Generation (CNG), které podporují SHA-2. Pokud je zde třeba Microsoft Strong Cryptographic Provider, tak musíme nejprve provést migraci CSP na KSP, popsáno u MS Migrating a Certification Authority Key from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP).

Zároveň zde vidíme certifikát autority (může jich být více), který si můžeme tlačítkem View Certificate zobrazit a podívat se na použitý hashovací algoritmus pro jeho podpis.

Případně můžeme využít řádkový příkaz certutil, který vypíše hodnotu registru, kde je nastavený algoritmus zapsán:
C:\>certutil -getreg ca\csp\CNGHashAlgorithm HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Intermediate CA\csp: CNGHashAlgorithm REG_SZ = SHA1 CertUtil: -getreg command completed successfully.
Nastavení algoritmu na SHA256
Změna použitého algoritmu se provede jednoduše změnou registru, k čemuž můžeme opět využít řádkový příkaz certutil
.
C:\>certutil -setreg ca\csp\CNGHashAlgorithm SHA256 SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Intermediate CA\csp: Old Value: CNGHashAlgorithm REG_SZ = SHA1 New Value: CNGHashAlgorithm REG_SZ = SHA256 CertUtil: -setreg command completed successfully. The CertSvc service may need to be restarted for changes to take effect.
Pozn.: SHA-2 je skupina hashovacích funkcí kam patří SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256. Často se využívá SHA-256, který používáme i zde.
Následně je třeba restartovat CA (pomocí GUI nebo příkazu níže) a můžeme zkontrolovat, že došlo ke změně ve vlastnostech CA.
C:\>net stop certsvc The Active Directory Certificate Services service is stopping. The Active Directory Certificate Services service was stopped successfully. C:\>net start certsvc The Active Directory Certificate Services service is starting. The Active Directory Certificate Services service was started successfully.
Všechny nově vystavené certifikáty již budou používat pro podpis hash algoritmus SHA256.
Vystavení nového certifikátu autority s SHA-2
Při provedení minulého kroku již vystavujeme certifikáty podepsané s hash algoritmem SHA-2. Při určitých kontrolách (například Google Chrome) se nekontroluje pouze algoritmus certifikátu, ale také certifikační řetězec, zda neobsahuje certifikát podepsaný SHA-1.
Pozn.: Z praxe to vypadá, že se kontrolují Intermediate certifikáty, ale Rootová CA může používat SHA-1.
Vyhledávání certifikátu CA
Proto potřebujeme nový certifikát pro naši certifikační autoritu. Když se na klientovi kontroluje certifikát, zda je pro nás důvěryhodný, tak se ve většině případů použije vyhledání certifikátu autority pouze pomocí jejího jména (pouze se speciálním nastavením se hledá ID). Proto, když vystavíme nový certifikát autority (se stejným jménem), tak tento můžeme použít i pro ověřování dříve vydaných certifikátů. Stačí jej vyměnit u klientů (případně na aplikačních serverech, když odesílají řetězec certifikátů spolu s vlastním serverovým certifikátem). Pokud má klient obě verze certifikátu, tak záleží, který se nalezne první. Vydaný certifikát je vždy validní, ale může psát chybu, že v cestě je SHA-1.
Vystavení nového certifikátu podřízené CA
V případě dvoustupňové hierarchie CA je první krok, že zapneme naši offline Root CA. A změníme hash algoritmus na SHA-2, jak bylo popsáno v minulé kapitole.
Následně vystavíme nový certifikát pro Intermediate CA. Oficiální popis Renew a subordinate certification authority. Pomocí MMC SnapInu Certification Authority klikneme pravým tlačítkem na naši autoritu a zvolíme All Tasks - Renew CA Certificate.

Dostaneme dotaz, zda chceme vygenerovat nový privátní klíč, což většinou není nutné.

V dalším kroku se již vytvořila žádost do souboru v kořeni disku C a v případě online autority můžeme rovnou odeslat. My vezmeme žádost a použijeme ji na Root CA. Pomocí MMC SnapInu Certification Authority klikneme pravým tlačítkem na naši autoritu a zvolíme All Tasks - Submit new request. Pokud máme nastaveno schvalování, tak na Pending Requests zvolíme Issue. Vystavený certifikát uložíme do souboru a přeneseme na Intermediate CA. Zde klikneme pravým tlačítkem na naši autoritu a zvolíme All Tasks - Install CA Certificate. Když se podíváme do vlastností autority, tak uvidíme o jeden certifikát více (a v jeho detailech, že je podepsán s SHA256).

Závěrečná otázka je, zda vystavit nový certifikát i pro Root CA nebo to není třeba.
Distribuce nového CA certifikátu na klienty a odstranění původního
Distribuce certifikátu pomocí Group Policy
Distribuce certifikátu certifikační autority do certifikačního úložiště Trusted Root Certification Authorities na klientech probíhá jednoduše pomocí GPO (Group Policy Object). Enterprise CA automaticky vkládá svůj certifikát do Default Domain Policy. V případě potřeby můžeme ručně zadat do libovolné GPO v cestě Computer/Policies/Windows Settings/Security Settings/Public Key Policies buď Trusted Root Certification Authorities nebo Intermediate Certification Authority Certificates.
Mazání certifikátu pomocí Startup skriptu
Jak jsme si řekli, pokud bude mít klient dva certifikáty pro stejnou CA, tak může někdy systém použít ten starý. Proto je potřeba starý certifikát u klientů odstranit. To ovšem standardně pomocí GPO nelze. U MS je nějaký článek How to remove a trusted Certificate Authority from computers in the domain, který se mi ale zdá zbytečně složitý. Zde si ukážeme využití řádkového příkazu certutil
, popis v Certutil. Pro smazání certifikátu se používá formát (pokud smaže zadaný certifikát, tak o něm zobrazí informaci):
certutil -delstore CertificateStoreName CertID
Je tu jen trochu zmatenější situace ohledně certifikačních úložišť (Certificate Store). Když použijeme MMC SnapIn Certificates, tak volíme certifikáty pro uživatele, počítač nebo službu. V daném místě již vidíme Personal, Trusted Root Certification Authorities, Intermediate Certification Authority Certificates a další. Když přidáme důvěryhodný certifikát CA, tak není ani jednoznačné, zda pro uživatele či počítač.
Když ale použijeme příkaz certutil
, tak musíme správně zadat úložiště. Nejjistější je provést mazání ve všech úložištích. Úložiště jsou user, enterprise, grouppolicy, service a computer (který je defaultní bez klíčového slova). K nim ještě určujeme umístění Root
pro Trusted Root Certification Authorities, CA
pro Intermediate Certification Authority Certificates a My
pro Personal.
Druhá věc je CertID
, v dokumentaci se uvádí, že může jít o řadu atributů certifikátu (nebo CRL). Já jsem měl úspěch při použití Thumbprint, ať včetně mezer (potom použito v uvozovkách) nebo bez nich. Smazání Intermediate certifikátu (ve všech úložištích) pak může vypadat následovně:
certutil -delstore CA "a0 03 a5 d4 fc 2e 5d 73 42 c3 f6 e2 fa b4 36 69 b1 7e c2 f5" certutil -delstore -enterprise CA "a0 03 a5 d4 fc 2e 5d 73 42 c3 f6 e2 fa b4 36 69 b1 7e c2 f5" certutil -delstore -user CA "a0 03 a5 d4 fc 2e 5d 73 42 c3 f6 e2 fa b4 36 69 b1 7e c2 f5" certutil -delstore -grouppolicy CA "a0 03 a5 d4 fc 2e 5d 73 42 c3 f6 e2 fa b4 36 69 b1 7e c2 f5"
Takovýto jednoduchý skript uložíme do cmd souboru a vytvoříme GPO se Startup skriptem (Computer Configuration - Policies - Windows Settings - Scripts - Startup), který aplikujeme na kontejner s klientskými počítači.
Na závěr ještě informace, když hledáme (kontrolujeme), kde se náš certifikát nachází, tak můžeme použít zobrazení obsahu určitého úložiště, například:
certutil -enterprise -viewstore CA
Nebo rovnou zkusit zobrazit informace o určitém certifikátu (podle Thumbprintu) v určitém úložišti. Pokud je nalezen, tak zobrazí jeho detaily.
certutil -store -user CA "a0 03 a5 d4 fc 2e 5d 73 42 c3 f6 e2 fa b4 36 69 b1 7e c2 f5"
Komentáře
Dobrý den,
jak se po změně na SHA-2 zachovaly již vydané certifikáty např. pro stanice (pro připojení do domény) a pro klienty (např. šifrování e-mailů, souborů a podobně) vdávané v rámci autoenrollmentu v Active Directory? Zůstaly v platnosti?
odpověď na [1]Michal Glaser: Jednu související informací popisuji v kapitole Vyhledávání certifikátu CA. Z toho plyne, že stávající certifikáty nemají žádný problém
. Musel bych je jedině ručně zneplatnit.
odpověď na [2]Samuraj:
Díky!
Dobrý den,
pokusil jsem se provést změnu z sha1 na sha256. Ale pokouším se přes web site vytvořit novou žádost pro Subordinate Certificate Authority, ale stále se mi nabízí pouze sha1.
Děkuji za skvělý článek
, přidávám syntaxi, která mi pomohla smazat root CA certifikát naimportovaný přes GPO Default Domain Policy na počítači (samozřejmě s jiným Thumbprintem), třeba někomu pomůže:
certutil -delstore -grouppolicy root "a0 03 a5 d4 fc 2e 5d 73 42 c3 f6 e2 fa b4 36 69 b1 7e c2 f5"