V tomto článku sa dozviete, ako používať certifikáty vydané certifikačnou autoritou tretej strany (CA), ako napríklad Let's Encrypt, Comodo, Symantec, Digicert atď. Ďalej sa bude venovať všeobecnej práci s certifikátmi.
Synopsa
Certifikáty slúžia na dva hlavné účely: na šifrovanie komunikácie medzi dvoma entitami a na potvrdenie autenticity entity. Prvý možno udeliť takzvaným certifikátom s vlastným podpisom, ale na autentifikáciu entity potrebujete globálne dôveryhodný certifikát vydaný koreňovým alebo sprostredkujúcim CA. V tomto článku vám vysvetlíme, ako certifikáty všeobecne dosahujú túto autentifikáciu, ako zmeniť formát certifikátu tak, aby pracoval s inými zariadeniami, vrátane našich brán firewall, ako importovať certifikát do brány firewall a ako by sa malo s certifikátmi zaobchádzať, aby sa zabránilo bezpečnostným rizikám.
Obsah
- Ako certifikát funguje?
- Certifikáty s vlastným podpisom
- Práca s certifikátmi
- Import certifikátov do brán firewall USG / ATP
- Zabezpečenie certifikátu
Ako certifikát funguje?
Každý certifikát sa skladá z dvoch častí: Certifikátu (nazývaného tiež verejný kľúč) a súkromného kľúča. Certifikát je možné verejne zdieľať a obsahuje iba informácie o účeloch, na ktoré bol certifikát vydaný, a na ktorú entitu bol certifikát vydaný - môže to byť vaše FQDN, e-mailová adresa alebo iná hodnota.
Certifikáty majú obmedzenú dobu platnosti - pomáha to v situáciách, keď sa niekde po desaťročiach niekde vykopá nejaký starý certifikát so súkromným kľúčom. Ak by bola platnosť nekonečná, certifikát by mohol stále používať na škodlivé účely každý, komu sa ho dostane do rúk. Od roku 2021 sa odporúča nepoužívať obdobie platnosti dlhšie ako jeden rok. S príchodom automatických mechanizmov opätovného vystavenia, ako je CertBot, sa toto obdobie môže na ďalšie zlepšenie zabezpečenia ešte skrátiť.
Certifikáty je možné odvolať v prípade, že došlo k úniku súkromného kľúča - a ako preventívne opatrenie by po každom porušení bezpečnosti, ktoré by narušilo hardvér obsahujúci súkromné kľúče, malo nasledovať odvolanie certifikátu a následné opätovné vydanie nových certifikátov.
Certifikáty je možné vydávať rôznym subjektom, napríklad FQDN, e-mailom, dokonca aj adrese IP alebo krstnému menu. Aj keď je technicky možné mať zástupné FQDN certifikáty a tie sú často používateľom preferované, majte na pamäti, že v prípade úniku súkromného kľúča z konkrétnej služby, zástupný certifikát autentifikuje celý FQDN - v dôsledku toho únik privátny kľúč na webovom serveri, ktorý sa používa iba na prezentáciu spoločnosti, sa môže rovnako použiť na útoky MITM medzi serverom Exchange alebo systémom CRM. Udržiavanie certifikátov nezávislých pre každú subdoménu pomáha zmierniť dopad úniku, kým nebude certifikát odvolaný.
Aj keď je tiež možné vydávať certifikáty na adresu IP, je to zastarané. Dôvodom je to, že adresy IP sa dajú ľahko meniť v porovnaní s FQDN.
Základný princíp certifikátov je dosť jednoduchý. V príklade chce mať Alice prístup na Bobov server, problém však je, že tam nikdy nebola, aby si nikdy nemohli vymeniť nejaké spoločné tajomstvo na autentizáciu. Ako si môže byť Alica istá, že sa skutočne spája s Bobom? Tu prichádza na rad Charlie. Alice pozná Charlieho a pridala jeho certifikát do úložiska koreňových certifikátov. Preto Alice považuje Charlieho za dôveryhodnú entitu. Ak má Bob svoj vlastný certifikát a súkromný kľúč vydaný Charliem, môže sa overiť u Alice. Nezáleží na tom, že Alice s Bobom nikdy predtým nebola v kontakte, pretože Bobovi Charlie dôveruje a keďže Alice dôveruje Charliemu, ona dôveruje aj Bobovi. . Toto sa nazýva reťazec dôvery.
Pozrime sa na Chain of Trust pre náš webový certifikát Support Campus:
Všimnite si, že existuje aj iná entita s názvom R3. Toto sa nazýva Intermediate CA, zatiaľ čo DST Root CA X3 je Root CA. Certifikát môže mať iba jednu koreňovú CA, ale môže existovať viac sprostredkujúcich CA. Sprostredkujúca CA je entita, ktorej bolo udelené povolenie na vydávanie certifikátov pre svojich zákazníkov. Pokiaľ má váš počítač v zozname dôveryhodných koreňových certifikátov certifikát DST Root CA X3, bude považovať adresu support.zyxel.eu za dôveryhodnú.
Certifikáty s vlastným podpisom
Naše brány firewall (a mnoho ďalších zariadení) štandardne používajú na vytvorenie šifrovaného pripojenia TLS certifikáty s vlastným podpisom. Takýto certifikát nahlási známa chybová správa prehľadávača: 
Existujú dva dôvody, prečo sa tak stalo. Prvým dôvodom je, že certifikát je v podstate koreňový certifikát CA, ktorý sa vo vašom systéme nenachádza. Ale jednoduchá inštalácia ako root CA do vášho počítača nebude stačiť, pretože certifikát sa nevydáva pre vašu IP alebo doménu. Certifikát je však vhodný na bezpečné pripojenie a jeho použitie nepredstavuje žiadne bezpečnostné riziko, pokiaľ nedôjde k úniku jeho súkromného kľúča - jediným problémom je, že totožnosť nie je možné potvrdiť.
Práca s certifikátmi
V priebehu rokov sa vyvinulo veľa formátov certifikátov. Certifikáty však stále používajú rovnaký princíp a všetky formáty je možné prevádzať do iných formátov.
Formáty certifikátov
Najstarším formátom by bol PEM, ktorý obsahuje kódovaný kľúč ASCII. Dôvodom je pôvodné použitie v šifrovaných e-mailoch, kde by sa mohol poškodiť binárny certifikát. PEM sú bežné v systémoch Unix a je pravdepodobné, že vám vaša CA poslala certifikát spolu so súkromným kľúčom vo formáte PEM. Zvyčajne používa príponu súboru .pem alebo .cer.
DER je binárna forma certifikátu formátu ASCII PEM. Všetky typy certifikátov a súkromných kľúčov je možné kódovať do formátu DER. Tento formát podporuje ukladanie jedného certifikátu a nezahŕňa súkromný kľúč pre strednú / koreňovú CA. Majú príponu .der alebo .cer a najčastejšie sa používajú na platformách Java.
PKCS # 7 je binárny formát, ktorý umožňuje obsahovať certifikáty alebo celý certifikát Chain of Trust v jednom súbore. V tomto formáte však nemožno uložiť žiadny súkromný kľúč. Tento formát CA najčastejšie používajú na zabezpečenie kompletného reťazca dôvery. Používa príponu .p7b.
PKCS # 12, tiež známy ako PFX, je formát, ktorý môže obsahovať celý reťazec dôvery a súkromný kľúč. Tento formát zvyčajne poskytujú CA, pretože ho možno zabezpečiť heslom. Bežne používa príponu .p12 alebo .pfx.
Nástroje pre certifikáty
Windows majú zabudovaný systémový nástroj CLI certutil, ktorý možno použiť na konverziu certifikátov. Doplnky na správu v konzole Microsoft Management Console tiež umožňujú správu certifikátov.
Open-source utilita s názvom OpenSSL je tiež schopná spracovávať a prevádzať certifikáty. Binárne súbory sú k dispozícii pre Windows, Linux a macOS (a mnoho ďalších platforiem)
Užitočné prí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žitočné prí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án firewall USG / ATP
Súčasná podoba (stav z júna 2021) je obmedzená na import certifikátov bez medzikľúčov. Ak by certifikát obsahoval sprostredkujúci kľúč, bude súbor nesprávne analyzovaný a pokus o použitie tohto certifikátu môže mať za následok nedostupnosť služby (napríklad WebGUI). Certifikát je dobré získať vo formáte .pem a exportovať ho do formátu .pfx pomocou nástroja certutil alebo OpenSSL. Certifikát je možné importovať spolu s jeho heslom v nasledujúcej ponuke:
Configuration > Objects > Certificates > My Certificates
Zabezpečenie certifikátu
Každý certifikát má svoj súkromný kľúč. Aj keď sú certifikáty verejné informácie, so súkromným kľúčom je potrebné zaobchádzať ako s tajomstvom - a nikto by ich nemal zdieľať. Ani u nás v spoločnosti Zyxel - jediným platným spôsobom je použitie nástrojov vzdialenej pomoci, ako je TeamViewer. Pri ukladaní súkromného kľúča vo formáte pem dvakrát skontrolujte povolenia na prístup k súkromnému kľúču, aby ste zabránili jeho úniku. Pri exportovaní certifikátov vždy používajte šifrovanie hesla vo formáte pfx, aby ste zaistili aspoň istý stupeň bezpečnosti. Všetky certifikáty s uniknutým súkromným kľúčom by mali byť okamžite odvolané.
Zrieknutie sa zodpovednosti:
Vážený zákazník, pamätajte, že na poskytovanie článkov vo vašom miestnom jazyku používame strojový preklad. Nie všetky texty môžu byť preložené presne. Ak existujú otázky alebo nezrovnalosti týkajúce sa presnosti informácií v preloženej verzii, prečítajte si pôvodný článok tu: Originálna verzia