V rámci mých předchozích dvou článečků o certifikátech jsem se samozřejmě zmiňoval o vydávání certifikátů. Zde uvádím detailně postup vytvoření žádosti (certificate request) o certifikát pro nějaký web server - tedy SSL/TLS Server Authentication certifikát. I když je to povětšinou jen obrázková záležitost, snažil jsem se jednotlivá políčka co nejdetailněji vysvětlit.
Pozadí
Myslím "background". Ne to na čem sedíte :-) Takže jde ná o to, vytvořit si žádost o (zřejmě veřejný) certifikát pro váš server. Chcete ho asi na provoz SSL/TLS serveru pro HTTPS, nebo například pro Exchange SMTP server, nebo FTPS server, který máte ve Windows 2008 R2. Můžete ho také použít pro Terminal Services Gateway (Remote Desktop Gateway), nebo VPN server a DirectAccess server. Koupit si veřejný certifikát je ideální řešení pro služby, ke kterým budete přistupovat z venku. Potřebujete obvykle jen jeden, cena je cca 1000,- CZK ročně a tudíž je to za pár kaček velmi pohodlné řešní. Všichni tomu věří (mobilní zařízení, cizí počítače) a nebudete mít problémy s CRL (Certificate Revocation List).
Žádost se vydává do souboru .REQ. Tuto žádost byste potom vzali a odeslali na certifikační autoritu (Certificate Authority - CA). Žádost kterou vytvoříme bude svázána s počítačem, na kterém byla vytvořena. Znamená to, že byste tu žádost měli udělat na počítači s daným serverem, pro který výsledný certifikát chcete použít.
Žádost i výsledný certifikát lze samozřejmě přenášet (exportovat a importovat), ale to je zbytečná dřina, pokud to můžete udělat rovnou na tom správném serveru. Export a import se bude samozřejmě hodit pokud chcete certifikát duplikovat a používat ho současně na více serverech.
PProces je tedy následující:
- vygenerování žádosti do souboru .REQ (request). Spolu se žádostí se na počítači vytvoří a zůstane bezpečně uložen privátní klíč. V žádosti je jen veřejný klíč, soubor se žádostí tedy není nutno nijak chránit. Soukromý klíč (private key) máte uložen na disku počítače, kde jste žádost vygenerovali.
- doprava .REQ požadavku na certifikační autoritu. Například přes webové rozhraní a platba kartou apod.
- autorita požadavek zkontroluje a vydá vám certifikát (certificate), který si přinesete zpět ve formě .CER souboru. .CER soubor obsahuje veřejný klíč (public key) a další parametry zkopírované z požadavku. Parametry mohou být i pozměněné, podle toho co si autorita přeje, nebo naopak nepřeje.
- .CER soubor následně naimportujeme zpět do počítače, na kterém čeká původní požadavek - tedy přesněji řečeno jeho soukromý klíč (private key). Říkám "čeká", protože i původní požadavek bylo možno přenést na jiný stroj, ale to není moc běžné řešení.
- tím, že se .CER soubor naimportoval, nejspíš se automaticky spároval s původním soukromým klíčem z požadavku. Pokud se tak nestalo samo, musíme párování vynutit ručně pomocí programu CERTUTIL.
- a pak už ten certifikát jenom použijete pro danou službu.
Popředí
V tomto okamžiku již přecházíme od pozadí k popředí. Opět se nejedná o žádnou část těla, ale o postup, jak to přesně provést :-) Nejprve si spusťte MMC konzoli a přidejte do ní konzoli Certificates. Pozor, potřebujeme certifikáty počítače (Local Computer). Proč počítač? Služby, byť možná běží pod nějakým servisním účtem, stejně využívají certifikáty počítače.
Jakmile máte spuštěnu konzoli Certificates, podívejte se orientačně, jaké už máte certifikáty v Personal úložišti (certificate store). Já tam nemám žádné, takže si to zapamtuju, abych se v tom později vyznal. A rovnou si pustím průvodce na vytvoření žádosti.
Na další tabulce už si musíte trošku vybrat. Máte k dispozici dvě volby - (No template) CNG key a nebo (No template) Legacy key. Jedná se o volbu poskytovatele bezpečného úložiště privátních klíčů - buď novější CNG (Cryptography Next Generation), nebo starší CSP (Cryptographic Services Provider). CNG je technologie dostupná až od Windows Vista a ani dnes ji pořád ještě všechny aplikace nepodporují. Web server ano, Terminal Server a SMTP server také, ale VPN server například nikoliv. Klíč uložený v CNG také nelze jednoduše přenášet na starší počítače, například s Windows Server 2003, kde je k dispozici jen CSP. Kvůli kompatibilitě osobně volím vždy raději CSP, abych toho později nelitoval.
Pokud máte server, nebo stanici, na které právě tuto akci provádíte, v doméně, měli byste mít na výběr ještě řadu dalších možností. Mezi nimi bude například šablona Web Server. Tyto všechny šablony se načtou z Active Directory a jednu z nich můžete klidně použít, pokud víte, co obsahuje (například šablona Web Server ve výchozím stavu nedovoluje pozdější export soukromého klíče a je potřeba to stejně změnit). V našem případě ale půjdeme úplně manuální cestou a vyplníme všechno správně tak, jak to je potřeba.
Volba Suppress default extensions by platila právě pro ty ostatní možné šablony a vyházela by všechny jejich rozšiřující parametry - což byste nejspíš ani nechtěli, když už jste si tu šablonu vybrali.
Volby PKCS #10 a CMC jsou formáty výsledného .REQ souboru. Většina certifikačních autorit umí oba formáty, nechal bych to tedy buď jak to je. Nebo si vyberte to, co po vás požaduje vaše konkrétní certifikační autorita. Volbu mezi binárním (binary) formátem a textovým BASE-64 provedete až úplně na konci průvodce.
Následuje volba popisku (Description) a zobrazovaného jména (Friendly name). Obě věci nesouvisí nijak s PKI ani s obsahem certifikátu. Je to jen váš osobní popisek certifikátu. Certifikační autoritě je to úplně jedno. Můžete si tam tedy zadat cokoliv, nebo to úplně ponechat volné. Je to jen někdy příjemné, protože třeba IISko zobrazuje právě friendly name, pokud je u certifikátu nějaké nastaveno.
Na další záložce už ale jsou velmi důležité informace. Je zde možnost vyplnit políčka Subject a Subject Alternative Name (SAN) do budoucího požadavku (a potažmo tedy i výsledného certifikátu, i když tohle si autorita může změnit jak se jí zlíbí). Do pole Subject můžete dát jen jedno jméno. Do SAN můžete dát jmen neomezeně. Šlo by tam dát i jméno s hvězdičkou, například něco jako *.sevecek.com.
Některé prehistorické aplikace a klienti nerozumí políčku SAN a dívají se jen do Subject. Dal bych tedy to "nejběžnější" jméno do Subject. Pokud potřebujete více jmen, dejte je do SAN. Ale pozor, do SAN zopakujte ještě jednou hodnotu Subject. Windows 7 totiž například nekontrolují Subject pokud je v certifikátu přítomno i pole SAN. Časy se mění - Windows Vista, Windows 2008 a st a starší operační systémy tahle dvě pole ještě kontrolovala obě.
Zda chcete zadat jméno s hvězdičkou - to bych zvážil. Ani hodně moderních zařízení, jako jsou různé telefony Nokia a například ani Windows Phone 7, tomuhle nerozumí. Raději se zbavte problémů a prostě vyjmenujte všechna jména, která potřebujete. Čím více jmen, tím vyšší cena certifikátu. I hvězdičkový certifikát (wildcard certificate) je dražší, než certifikát s několika jmény.
Mezi jména si nezapomeňte přidat autodiscover, pakliže tuto službu chcete používat. Můžete tam dát i jméno bez www například, lidi občas tyhle předpony nezapisují do prohlížeče.
Na další záložce musíte zadat použití klíče (ng>Key Usage) a rozšířené použití klíče (Enhanced Key Usage). Oboje jsou běžné hodnoty v SSL/TLS certifikátech. Obvykle si navíc sem můžete zadat skoro cokoliv, autorita vám to stejně ale vyignoruje a vydá vám certifikát, ve kterém bude stejně přesně toto. Takže neriskujte, zadejte tam tyto hodnoty a máte to z krku.
Digital Signature je tam potřeba kvůli podpisu D-H klíčové výměny (Diffie-Hellman Key Exchange). Key Exchange potřebuje RSA algoritmus pro výměnu symetrických šifrovacích klíčů. Oboje SSL/TLS servery dělají, takže to tam prostě dejte. Rozšířené použití s hodnotou Server Authentication (OID 1.3.6.1.5.5.7.3.1) potom kontrolují klienti. Ono je to utvrzuje v tom, že se skutečně jedná o certifikát SSL/TLS serveru. Jen pro zajímavost, kdybyste se měli vy sami přihlašovat certifikátem na nějaký web, museli byste mít ve svém certifikátu použití Client Authentication (OID 1.3.6.1.5.5.7.3.2).
Na další tabulce jsou ale VELICE PODSTATNÉ věci. Musíte to dodržet, jinak vám to později nebude fungovat, nebo se to bude chovat podivně. Až to budete vyplňovat, dejte pozor, jakmile jednu z těch hodnot nějak pozměníte, průvodce vám pozmění sám i některé další. Raději to pořádně zkontrolujte dřív, než budete pokračovat. Vysvětlení až pod obrázky. Nejprve si to naklikejte.
A nyní tedy to slibované vysvětlení. MUSÍTE vybrat jednoho ze dvou poskytovatelů, kteří mají ve jméně Schannel. To je knihovna, která ve Windows dělá SSL/TLS šifrování. Všechny Win32 a .NET Framework programy a služby tuhle knihovnu používají. Pokud byste vybrali něco jiného, bude se to chovat divně. Takže bacha na Karla Vlacha!
Privátní klíč chcete mít exportovatelný, abyste si výsledný certifikát i s ním mohli vyexportovat a přenášet a kopírovat na další servery. Archivaci nejspíš nechcete. To je fíčura doménových certifikátů. Jakmile vyprší, systém si je skryje - zaarchivuje. Nejsou vidět ve výchozím zobrazení a nejsou použitelné k další práci. Jsou ale pořád uloženy v systému a daly by se případně použít k dešifrování starších dat. Zaprvé tohle nebude doménový certifikát. A za druhé, SSL cert certifikátem se žádná trvalá data nešifrují - "šifrují se tím" jen data po dobu jejich přenosu po síti.
Volbu Strong private key protection nechcete zaručeně. To se hodí na uživatelské certifikáty. Něco jako přihlašovací certifikáty do různých internetových služet - internetová bankovnictví apod. Když si zapnete Strong private key protection, budete muset při každém jeho použití potvrzovat dialogové okno, že to opravdu chcete. Dá se požadovat i zadání dodatečného hesla. Tohle uživatel zadávat může, když chce být lépe chráněný proti různým phishingům a dalším lovcům. Ale počítač ani služba ani server to zadat nedokáží, takže by pak ten váš certifikát prostě ani použít nedokázali. A nefungovalo by to.
Délku klíče obvyklé servery i klienti umí 2048. U starších klientů (výroba cca do 2003) by to ale mohlo dělat problémy, takže byste mohli zvolit jen 1024. Ale to by vám zase nejspíš certifikační autority nechtěly vydat, protože je to pro ně "málo bezpečné".
Klíč nesmí byt jen pro podpis (Signature). Kvůli RSA potřebujete i Key Exchange kvůli šifrování. Opět by to za určitých okolností způsobovalo problémy. Takže vyberte Exchange. A znovu upozorňuju, jakmile tohle přepnete, GUIčko se posere a popřepíná vám ostatní zaškrtávátka. Jak v blázincu.
Volba týkající se zabezpečení soukromého (privátního) klíče je někdy také důležitá. Například pro SQL server. Pokud víte, že vaše SSL/TLS služba běží pod nějakým servisním účtem a nikoliv pod účtem systému (SYSTEM, Network Service, Local Service). Měli byste přidělit danému účtu oprávnění (permission) READ. Tohle nemusíte dělat pro IIS App Pool ať si běží pod čímkoliv - protože IIS používá HTTPS driver v jádře a šifrování probíhá vždy pod účtem systému, bez ohledu na identitu App Poolu. Pokud nevíte, tím že tam dáte nějakého uživatele, rozhodně nic nezkazíte - kromě klasického Everyone :-)
Následuje už jen dokončení požadavku a jeho uložení do souboru. Formát bych nechal BASE-64, tedy obyčejný textový. Když si potom výsledný .REQ soubor otevřete v nějakém textovém editoru (například NOTEPAD), můžete si text normálně překopírovat přes schránku. Nejspíš všechny certifikační autority tento formát přijímají a navíc se dá jednoduše vložit přes webové rozhraní. To u binárního formátu není zaručeno.
V předchozích obrázcích bych jen upozornil na několik věcí. Hlavně si všimněte, že certifikát prozatím nemáte v Personal úložišti (certificate store). Máte jen jeho požadavek uložený v Certificate Enrollment Requests. Důležité je, že požadavek (request) je self-signed, je podepsán sám sebou. Nemáte čím jiným to podepsat. Platnost požadavku není důležitá. To klidně ignorujte. Certifikační autority ho přijmou i později.
A máte k němu privátní klíč. Až přijde zpátky certifikát z certifikační autority, naimportujete ho a ono se to samo spáruje.
Odneste požadavek na autoritu a přineste si výsledný .CER nebo .CRT soubor
A naimportujte si ho zase do úložiště počítače. Pozor! Až ho budete mít, importovat certifikát byste měli ale do Personal úložiště. Jinak to bude zmatené a nespáruje si to rovnou samo tenhle certifikát s jeho soukromým (privátním) klíčem.
Až budete mít certifikát zpět z autority a budete ho mít vložený do Personal úložiště, ověřte, že je v jeho vlastnostech vidět, že k němu máte soukromý (privátní) klíč. No pokud se to nespáruje, nebo i jen tak pro jistotu můžete vynutit párovací akci v příkazové řádce pomocí CERTUTIL. To už by potom mělo zaručeně zobrazovat hlášku You have a private key that corresponds to this certificate.
CERTUTIL -repairstore My
A to je pro dnešek už opravdu všechno. Můžete jít a certifikát použít v některé z vašich služeb!