www.SAMURAJ-cz.com 

18.12.2017 Miloslav Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Převod Microsoft Certification Authority z SHA1 na SHA2

Čtvrtek, 04.02.2016 22:44 | Samuraj - Petr Bouška |
Již je tu rok, kdy (řekněme) oficiálně končí podpora hashovacího algoritmu SHA-1 v certifikátech. Doporučení je, co nejdříve přejít na SHA-2. Pokud interně využíváme Microsoft Certification Authority, tak je také dobré provést tuto změnu. Naštěstí to (ve většině případů) není nic složitého a jde pouze o pár změn na stávající certifikační infrastruktuře. O této oblasti se na internetu hodně píše, ale nenalezl jsem nějaký souhrnný článek, takže jej přináším zde.

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).

Nastavení CA - Hash algorithm a Provider

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.

Signature hash algorithm v certifikátu

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.

Vystavení nového certifikátu - Renew CA Certificate

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

Renew CA Certificate - nový privátní klíč?

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).

Nové vlastnosti Cryptographic settings

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"
zobrazeno: 5910krát | Komentáře [4]

Autor:

Související články:

Active Directory a protokol LDAP

Správa počítačové sítě ala Microsoft, to je Active Directory. Jedná se o velice rozsáhlou skupinu technologií a služeb. Základem jsou adresářové služby, adresáře a komunikační protokol LDAP.

Protokol SSL/TLS

Protokol Secure Sockets Layer a jeho nástupce Transport Layer Security se hojně využívají na internetu pro zabezpečení komunikace jiného protokolu (třeba HTTPS, SMTPS, XMPP) pomocí šifrování.

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže. Pokud chcete poradit s nějakým problémem či diskutovat na nějaké téma, tak použijte fórum.

Komentáře

  1. [1] Michal Glaser

    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?

    Úterý, 14.02.2017 12:43 | odpovědět
  2. [2] Samuraj

    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.

    Středa, 15.02.2017 09:55 | odpovědět
  3. [3] Michal Glaser

    odpověď na [2]Samuraj: :-) Díky!

    Středa, 15.02.2017 15:32 | odpovědět
  4. [4] Václav Panenka

    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.

    Středa, 05.04.2017 10:20 | odpovědět
Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O


Ochrana proti SPAMu, zdejte následující čtyři znaky image code

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách