Tento článek vysvětlí, jak používat certifikáty vydané certifikační autoritou třetí strany (CA), například Let's Encrypt, Comodo, Symantec, Digicert atd. Rovněž se bude zabývat obecným fungováním certifikátů.
Synopse
Certifikáty slouží dvěma hlavním účelům: Šifrovat komunikaci mezi dvěma entitami a potvrdit autenticitu entity. První může být uděleno takzvaným certifikátem s vlastním podpisem, ale k ověření entity potřebujete globálně důvěryhodný certifikát vydaný kořenovým nebo zprostředkujícím CA. Tento článek vysvětlí, jak certifikáty obecně dosahují tohoto ověřování, jak změnit formát certifikátu tak, aby fungoval s jinými zařízeními, včetně našich bran firewall, jak importovat certifikát do brány firewall a jak by se mělo s certifikáty zacházet, aby se zabránilo bezpečnostním rizikům.
Obsah
- Jak certifikát funguje?
- Certifikáty podepsané svým držitelem
- Práce s certifikáty
- Import certifikátů do bran firewall USG / ATP
- Zabezpečení certifikátu
Jak certifikát funguje?
Každý certifikát se skládá ze dvou částí: Certifikát (nazývaný také veřejný klíč) a soukromý klíč. Certifikát lze veřejně sdílet a obsahuje pouze informace o účelech, pro které byl certifikát vydán, a na který subjekt byl certifikát vydán - může to být váš FQDN, e-mailová adresa nebo jiná hodnota.
Certifikáty mají omezenou dobu platnosti - to pomáhá v situacích, kdy se po několika desetiletích někde vykopá nějaký starý certifikát se soukromým klíčem. Pokud byla platnost nekonečná, mohl by certifikát stále používat ke škodlivým účelům každý, komu se ho dostane do rukou. Od roku 2021 se doporučuje nepoužívat dobu platnosti delší než jeden rok. S příchodem mechanismů automatického opětovného vystavení, jako je CertBot, se toto období může zkrátit, aby se dále zlepšilo zabezpečení.
Certifikáty lze odvolat v případě, že došlo k úniku soukromého klíče - a jako preventivní opatření by po každém narušení zabezpečení, které narušilo hardware obsahující soukromé klíče, mělo následovat odvolání certifikátu a následné nové vydání nových certifikátů.
Certifikáty lze vydávat různým subjektům, například FQDN, e-mail, dokonce i IP adresa nebo křestní jméno. I když je technicky možné mít zástupné certifikáty FQDN a ty jsou často upřednostňovány uživateli, mějte na paměti, že v případě úniku soukromého klíče z konkrétní služby ověřuje zástupný certifikát celý FQDN - v důsledku toho únik privátní klíč na webovém serveru, který se používá pouze pro firemní prezentaci, lze také použít pro útoky MITM mezi serverem Exchange nebo systémem CRM. Udržování nezávislých certifikátů pro každou subdoménu pomáhá zmírnit dopad úniku, dokud nebude certifikát odvolán.
I když je také možné vydávat certifikáty na IP adresu, je to zastaralé. Důvodem je to, že adresy IP lze snadno změnit ve srovnání s plně kvalifikovaným jménem.
Základní princip certifikátů je poměrně jednoduchý. V příkladu chce Alice získat přístup na Bobův server, ale problém je v tom, že tam nikdy nebyla, aby si nikdy nemohli vyměnit nějaké společné tajemství za ověření. Jak si může Alice být jistá, že se skutečně připojuje k Bobovi? Tady vstupuje do hry Charlie. Alice zná Charlieho a přidala jeho certifikát do úložiště kořenových certifikátů. Proto Alice považuje Charlieho za důvěryhodnou entitu. Pokud má Bob svůj vlastní certifikát a soukromý klíč vydaný Charliem, může se ověřit u Alice a nezáleží na tom, že Alice s Bobem nikdy předtím nebyla v kontaktu, protože Bobovi Charlie důvěřuje, a protože Alice důvěřuje Charliemu, ona důvěřuje také Bobovi . Tomu se říká Chain of Trust.
Pojďme se podívat na Chain of Trust pro náš webový certifikát Support Campus:
Všimněte si, že existuje také další entita s názvem R3. Toto se nazývá Intermediate CA, zatímco DST Root CA X3 je Root CA. Certifikát může mít pouze jednu kořenovou CA, ale může existovat více zprostředkujících CA. Intermediate CA je subjekt, kterému bylo uděleno oprávnění vydávat certifikáty pro své zákazníky. Dokud má váš počítač v seznamu důvěryhodných kořenových certifikátů certifikát DST Root CA X3, bude považovat support.zyxel.eu za důvěryhodný.
Certifikáty podepsané svým držitelem
Ve výchozím nastavení používají naše brány firewall (a mnoho dalších zařízení) k navázání šifrovaného připojení TLS certifikáty s vlastním podpisem. Takový certifikát je hlášen známou chybovou zprávou prohlížeče: 
Existují dva důvody, proč se to stalo. Prvním důvodem je, že certifikát je v zásadě kořenový certifikát CA, který se ve vašem systému nenachází. Pouhá instalace jako kořenové CA do vašeho počítače ale nebude stačit, protože certifikát není vydán pro vaši IP nebo doménu. Certifikát je však vhodný pro zabezpečené připojení a jeho použití nepředstavuje žádné bezpečnostní riziko, pokud nedojde k úniku jeho soukromého klíče - jediným problémem zde je, že totožnost nelze potvrdit.
Práce s certifikáty
V průběhu let bylo vyvinuto mnoho formátů certifikátů. Certifikáty však stále používají stejný princip a všechny formáty lze převést do jiných formátů.
Formáty certifikátů
Nejstarším formátem by byl PEM, který obsahuje kódovaný klíč ASCII. Důvodem je původní použití v šifrovaných e-mailech, kde by se mohl binární certifikát poškodit. PEM jsou v unixových systémech běžné a je pravděpodobné, že vám váš CA poslal certifikát spolu se soukromým klíčem ve formátu PEM. Obvykle používá příponu souboru .pem nebo .cer.
DER je binární forma certifikátu formátu ASCII PEM. Všechny typy certifikátů a soukromých klíčů lze kódovat ve formátu DER. Tento formát podporuje ukládání jediného certifikátu a neobsahuje soukromý klíč pro zprostředkujícího / kořenového CA. Mají příponu .der nebo .cer a nejčastěji se používají na platformách Java.
PKCS # 7 je binární formát, který umožňuje obsahovat certifikáty nebo celý certifikát Chain of Trust v jednom souboru. V tomto formátu však nelze uložit žádný soukromý klíč. Tento formát CA nejčastěji používají k poskytnutí úplného řetězce důvěry. Používá příponu .p7b.
PKCS # 12, také známý jako PFX, je formát, který může obsahovat také celý řetězec důvěry a soukromý klíč. Tento formát obvykle poskytují CA, protože jej lze zabezpečit heslem. Běžně používá příponu .p12 nebo .pfx.
Nástroje certifikátu
Windows mají zabudovaný systémový nástroj CLI certutil, který lze použít k převodu certifikátů. Pluginy pro správu v konzole Microsoft Management Console také umožňují správu certifikátů.
Open-source nástroj s názvem OpenSSL je také schopen zpracovávat a převádět certifikáty. Binární soubory jsou k dispozici pro Windows, Linux a macOS (a mnoho dalších platforem)
Užitečné příkazy certutil:
Merging PEM into PFX:
C:\temp>certutil –MergePFX cert.cer cert.pfx
NOTE: as certutil doesn't allow to specify private key path, the key must be present
in the same directory as certificate, have the same name and .key extension.
Užitečné příkazy OpenSSL:
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Import certifikátu do brány firewall USG / ATP
Aktuální design (stav z června 2021) je omezen na import certifikátů bez mezilehlých klíčů. Pokud certifikát obsahuje zprostředkující klíč, bude soubor nesprávně analyzován a pokus o použití takového certifikátu může mít za následek nedostupnost služby (například WebGUI). Je dobré získat certifikát ve formátu .pem a exportovat jej do formátu .pfx pomocí certutil nebo OpenSSL. Certifikát lze importovat spolu s jeho heslem v následující nabídce:
Configuration > Objects > Certificates > My Certificates
Zabezpečení certifikátu
Každý certifikát má svůj vlastní soukromý klíč. Zatímco certifikát je veřejná informace, se soukromým klíčem je třeba zacházet jako s tajemstvím - a nikdo by jej neměl sdílet. Ani u nás ve společnosti Zyxel - jediným platným způsobem je použití nástrojů vzdálené pomoci, jako je TeamViewer. Když ukládáte soukromý klíč ve formátu pem, dvakrát zkontrolujte oprávnění pro přístup k soukromému klíči, abyste zabránili jeho úniku. Při exportu certifikátů vždy používejte šifrování hesla ve formátu pfx, abyste zajistili alespoň určitý stupeň zabezpečení. Jakékoli certifikáty s uniklým soukromým klíčem by měly být okamžitě zrušeny.
Zřeknutí se odpovědnosti:
Vážený zákazníku, pamatujte, že k poskytování článků ve vašem místním jazyce používáme strojový překlad. Ne všechny texty mohou být přeloženy přesně. Pokud existují otázky nebo nesrovnalosti ohledně přesnosti informací v přeložené verzi, přečtěte si prosím původní článek zde: Původní verze