V minulém dílu tohoto seriálu jsme si popsali, jak jsou na platformě MS Windows některé kořenové certifikáty (zařazené do programu MRCP společnosti Microsoft) instalovány automaticky, aniž by o tom uživatel byl i jen informován. Z našich tří certifikačních autorit, které mají akreditaci od státu, se to týká jen společnosti I.CA (a nikoli dalších dvou, tj. PostSignum a eIdentity).
Dnes si už ukážeme, jak si takovéto kořenové certifikáty instalovat sami, z vlastní vůle a vlastního rozhodnutí.
Instalace kořenových certifikátů je ale úkolem, který má dvě důležité části:
- první je získání samotných kořenových certifikátů dostatečně důvěryhodným způsobem. Tedy tak, abychom mohli mít jistotu, že jsme skutečně získali „ty pravé“ certifikáty.
- druhou je samotné nainstalování certifikátů do správného úložiště, do správné „přihrádky“ (složky) ve správném úložišti, a nastavení správných účelů využití certifikátů.
Jak získat certifikáty dostatečně důvěryhodným způsobem?
O tom, jaký způsob získání kořenových certifikátů je dostatečně důvěryhodný, se zde na Lupě diskutovalo již několikrát. Sám jsem – v článku o známém problému se serverovým certifikátem webového portálu ISDS – propagoval jako dostatečně důvěryhodné pouze získání příslušných certifikátů přímo od příslušné certifikační autority, v její „kamenné provozovně“. Tj. nechat si je nahrát na nějakou flashku či disketu, případně vypálit na CD.
To je ostatně i doporučení, které zákazníkům dávají i samotné certifikační autority. A že to funguje, mohu potvrdit i z vlastní zkušenosti: když jsem si nechával vystavit nové osobní certifikáty od CA PostSignum, nahráli mi všechny své kořenové certifikáty na mou flashku (se žádostí o nové certifikáty), a to zcela automaticky, ještě než jsem si o to stačil říct.
Nicméně ne vždy a ne každému se vyplatí jít přímo na pracoviště příslušné autority a zde přesvědčovat obsluhu, aby mu certifikáty nahrála. Jaké tedy jsou možné alternativy?
Samozřejmě je zde ta nejjednodušší možnost: stáhnout si certifikáty přímo z webu příslušné certifikační autority. To nabízí každá z nich – ale žádná vám nezaručí, že když si na svém browseru zadáte adresu příslušné stránky, že se dostanete skutečně na „ty jejich“ stránky, a ne na nějaké jiné (podvržené) stránky – které by vám pak, místo správných certifikátů, podstrčily nějaké jiné.
Jistě, pravděpodobnost takovéhoto podvrhu je velmi malá. Ale problém je v tom, že ji nelze zcela vyloučit.
Třeba pro testování a „učení se“ může takovéto stažení přímo z webu certifikační autority postačovat. Ale pro reálné použití (spoléhání se na podpisy a jejich platnost) je to opravdu nedostatečně věrohodný způsob získání certifikátů. Pokud ho někdo využije a následně se spoléhá na platnost ověřovaných podpisů, činí tak jen na vlastní nebezpečí.
Rozumnější přístup je stáhnout si certifikáty z nějakého „možná ne zcela důvěryhodného zdroje“ (přímo z webu příslušných certifikačních autorit) a následně si ověřit, že jde skutečně o „ty správné“ certifikáty. Znovu zdůrazňuji, že nejde o to, že by weby certifikačních autorit nebyly důvěryhodné a nabízely podvržené certifikáty – problém je v tom, že uživatel Internetu nemá stoprocentní jistotu, že se dostal na skutečné stránky certifikační autority, a ne na nějaké podvržené stránky s falešnými certifikáty.
Rozumnou jistotu toho, že si stáhl „ty pravé“ certifikáty, může uživatel získat následnou kontrolou jejich pravosti. V našem případě, kdy máme na mysli kontext datových schránek, by bývalo nejjednodušší, kdyby Česká pošta do tiskopisu s přihlašovacími údaji (tzv. PIN zásilky) vložila údaje, potřebné pro ověření kořenových certifikátů (svých i ostatních dvou akreditovaných autorit). Jenže to Česká pošta neudělala.
Proto je nutné získat potřebné údaje pro ověření jinde. Jednou z možností je obrátit se na MV ČR, které má jako orgán dohledu (nad certifikačními autoritami) dokonce povinnost pravidelně ověřovat jejich kořenové certifikáty a publikovat výsledky tohoto ověření. Jenže jak je získat?
Jednoduchá cesta je přes web: najdeme zde jak tzv. otisky příslušných certifikátů (přes které si můžeme zkontrolovat pravost těch již stažených), tak i samotné certifikáty (tj. můžeme si je stáhnout i z webu MV ČR). Ale opět jsme u stejného problému: ne že by web MV ČR nebyl důvěryhodný – ale my stále nemáme stoprocentní jistotu, že jsme se dostali skutečně na webové stránky MV ČR a ne na nějaké falešné stránky, které se za stránky MV ČR jen vydávají. Pravděpodobnost je opět velmi malá, ale nelze ji zcela vyloučit.
Nicméně existuje ještě další možnost, při které se už přesměrování na falešné webové stránky bát nemusíte: MV ČR své zjištění publikuje i „na papíře“, v tištěném Věstníku ministerstva vnitra. Naposledy v částce 24 ročníku 2008, ze 3. března 2008. Takže stačí zajít do příslušné prodejny a vytištěný věstník si koupit.
Případně můžete zkusit si do certifikační autority zavolat telefonem a nechat si požadovaný otisk certifikátu nadiktovat.
Nebo další možnost, pro kontrolu a tím i zvýšení bezpečnosti: na věstník MV ČR, dostupný v PDF přímo z webu MV ČR, se můžete podívat i skrze online prohlížeč společnosti Google (zde přímý odkaz na Věstník). A pravděpodobnost, že servery Googlu jsou někým uvedeny v omyl přesně stejným způsobem jako váš browser, je opět podstatně menší.
Formáty certifikátů a otisků
Než se dostaneme k samotnému ověření shody (certifikátu a jeho otisku), musíme si ještě říci, že jako uživatelům nám mohou být certifikáty nabízeny v různých formátech (a v souborech různých formátů, resp. s různými příponami). Některé formáty jsou určeny pro čtení (jednoduché a člověku srozumitelné zobrazení obsahu certifikátu), jiné jsou zase určeny pro potřeby instalování do úložišť našich počítačů.
Příklad ukazuje následující obrázek (z webu PostSignum):
Tzv. otisk certifikátu, přes který chceme kontrolovat jeho pravost, je ovšem počítán z certifikátu v určitém konkrétním formátu – a tak jeden a tentýž certifikát má více různých otisků. A aby to bylo ještě složitější, i otisk se dá počítat více různými způsoby. Dnes se používají hlavně dva způsoby, označované jako SHA-1 a MD5.
Příklady otisků (v terminologii Microsoftu, v Internet Exploreru označované jako „miniatury“) pak vypadají následovně:
SHA-1: 4DF1 599E 7B2A A1F7 EA66 6DF5 D998 D0C9 08CE 23C9
MD5: FBC2 D601 D3BF 6C34 BDAE 9EA7 30AE AF3B
Celkovým výsledkem je ale to, že pro jeden a tentýž certifikát existuje (a je ze strany MV ČR ověřeno) více otisků (pro různé formáty a způsoby výpočtu). Viz následující ukázka z věstníku, pro kořenový certifikát CA PostSignum:
Pro naše potřeby (instalace certifikátů na platformě MS Windows) využijeme formát DER (Distinguished Encoding Rules) – a nenecháme se zmást tím, že tento formát certifikátu (DER) bývá distribuován jako obsah souborů s jinou příponou, resp. typem, a to .cer, případně .crt apod. Důležitý je formát obsahu, resp. samotného certifikátu, tj. DER.
Jednotlivé certifikační autority, které na svých webech nabízí ke stažení své certifikáty, k nim snad vždy samy nabízí i jejich otisky – viz následující obrázek pro CA PostSignum. Spoléhat se na ně je ale zatíženo stejným nebezpečím, jako stažení samotných certifikátů (nemáme jistotu, že je stahujeme ze správného webu). Nicméně křížová kontrola otisků (z webu i z věstníku) určitě neuškodí.
Jak ověřit otisk certifikátu?
Předpokládejme nyní, že už máme stažené ty certifikáty, které chceme nainstalovat jako důvěryhodné (ve formátu DER), a máme (nejlépe „na papíře“) k dispozici i jejich otisky. Jak nyní ověříme shodu?
Jedna možnost je ta, že certifikát „předhodíme“ našemu browseru (či jiné aplikaci, která s certifikáty umí pracovat), a necháme si otisk spočítat a ukázat od ní. Příklad s Internet Explorerem (který otisk označuje jako „miniaturu“) a Firefoxem ukazují následující dva obrázky:
Tento přístup ale znamená, že důvěřujeme příslušné aplikaci (zde: Internet Exploreru či Firefoxu), že nám vypočítala a ukázala správný otisk. Pravděpodobnost, že bychom používali nějakou podvrženou aplikaci, která nám schválně ukazuje jiný otisk než jaký certifikát doopravdy má, je sice malá – ale opět ji nelze zcela vyloučit.
Můžeme si ale nechat otisk spočítat nějakou další aplikací. Ministerstvo vnitra nám k tomu dokonce nabízí „jí prověřenou“ aplikaci Datahash, kterou si můžeme stáhnout z jejích stránek. Ve skutečnosti jde o aplikaci, kterou k danému účelu nechalo vyvinout ještě bývalé Ministerstvo informatiky ČR. Podmínkou je ale nainstalovaná podpora Javy.
Stejně tak ale můžete svěřit výpočet otisku nějaké jiné utilitě. Na následujícím obrázku vidíte výsledek výpočtu otisku konkrétního certifikátu skrze tuto jednoduchou utilitu (nevyžadující Javu).
Které certifikáty instalovat?
Chceme-li, aby námi používaná aplikace správě vyhodnocovala certifikáty vydané tuzemskými akreditovanými certifikačními autoritami, již víme že musíme nainstalovat všechny potřebné certifikáty do toho úložiště, se kterým naše aplikace pracuje. Tedy do systémového úložiště v MS Windows (v případě Internet Exploreru), a do vlastního úložiště Firefoxu (v případě tohoto browseru). Obdobně pro další aplikace.
A jen pro připomenutí: produkty Microsoftu používají systémové úložiště v MS Windows, zatímco aplikace od ostatních producentů mohou používat vlastní úložiště. Vždy je třeba si to o příslušné aplikaci zjistit.
Konkrétních certifikátů, které musíme nainstalovat, ale bývá více – a korespondují se strukturou (dílčích) certifikačních autorit daného poskytovatele certifikačních služeb. Již jsme si to jednou ukazovali, na konkrétním příkladu autority PostSignum od České pošty. Její certifikáty jsou uspořádány hierarchicky: existuje jeden „kořenový“ certifikát CA PostSignum (správně: kvalifikovaný systémový certifikát kořenové certifikační autority PostSignum), kterým jsou podepsány „vydávající“ certifikáty dvou dceřiných certifikačních autorit: kvalifikované autority (Postsignum QCA), a komerční autority (Postsignum VCA).
Teprve tyto „vydávající“ (anglicky: issuing“) certifikáty jsou používány pro vydávání příslušných druhů certifikátů koncovým zákazníkům: kvalifikovaná certifikační autorita vydává kvalifikované certifikáty (použitelné pouze pro podpis), zatímco komerční certifikační autorita vydává komerční certifikáty, použitelné pro ostatní účely).
Představu hierarchie ukazuje následující obrázek:
Pro nás je podstatné to, že vždy musíme mít správně nainstalovánu celou příslušnou „certifikační cestu“: chceme-li správně vyhodnocovat kvalifikované certifikáty od CA PostSignum (tj. od její dceřiné PostSignum QCA), musíme nainstalovat jak „kořenový“ certifikát (certifikát kořenové CA PostSignum), tak i „vydávající“ certifikát (certifikát PostSignum QCA). Navíc se zachováním jejich hierarchického uspořádání (viz dále).
Chceme-li správně vyhodnocovat i komerční certifikáty, vydané CA PostSignum, musíme „pod“ kořenový certifikát správně nainstalovat i „vydávající“ certifikát komerční PostSignum VCA. Tedy celkem tři certifikáty.
V případě certifikační autority eIdentity je situace obdobná, jen názvy (a samozřejmě i samotné certifikáty) jsou jiné, viz obrázek:
To u I.CA je situace odlišná. Tato certifikační autorita nemá u svých certifikátů hierarchické uspořádání (s jedním kořenovým certifikátem a několika podřízenými certifikáty, skutečně používanými pro vydávání certifikátů koncovým zákazníkům). Místo toho má pro každou oblast své činnosti samostatný kořenový certifikát. Viz obrázek.
Zde tedy budeme instalovat (právě a pouze) příslušné kořenové certifikáty. Tedy: budeme je instalovat „ručně“ jen těm aplikacím, které nepoužívají systémové úložiště MS Windows (kam se tyto kořenové certifikáty instalují automaticky, viz minulý díl). Tedy například pro Firefox do jeho úložiště, ale už nikoli „pro“ Internet Explorer.
Navíc je v případě I.CA situace o něco komplikovanější v tom, že tato certifikační autorita používá pro stejné oblasti více kořenových certifikátů – s různou platností v čase. Tudíž bychom měli instalovat všechny ty, které jsou stále ještě platné.
Kam certifikáty instalovat?
Dalším důležitým požadavkem, kterému musíme vyhovět, je nainstalování do správné „přihrádky“ v rámci úložiště, do kterého instalujeme.
Zde si musíme opět naznačit, že každé úložiště může mít několik složek (jak se „přihrádkám“ říká v terminologii Microsoftu) – a že význam nainstalovaného certifikátu se liší podle toho, do které složky ho nainstalujeme.
Takže třeba kořenové certifikáty těch certifikačních autorit (či: „certifikačních úřadů“, v terminologii Microsoftu), které považujeme za důvěryhodné, musíme instalovat do složky „Důvěryhodné kořenové certifikační úřady“ v rámci systémového úložiště MS Windows. To se týká konkrétně „kořenového“ certifikátu CA PostSignum a CA eIdentity, a dále všech kořenových certifikátů I.CA (důvody viz výše).
Naproti tomu „vydávající“ certifikáty CA PostSignum i eIdentity (tj. certifikáty příslušných kvalifikovaných a komerčních autorit) je třeba umístit jinam – konkrétně do složky „Zprostředkující certifikační úřady“.
Znovu si ale zdůrazněme, že právě uvedené se týká pouze systémového úložiště MS Windows. Jiná úložiště, používaná dalšími aplikacemi, mohou mít zcela jinou strukturu „přihrádek“ (složek).
Například u Firefoxu, kde musíme kořenové i vydávající certifikáty umístit do stejné složky (pro „autority“). Hierarchický vztah mezi certifikáty si pak toto úložiště již „domyslí“ (resp. zjistí) samo.
Logická vs. fyzická úložiště
Pro úplnost si ještě dodejme, že konkrétní úložiště certifikátů může být jediným logickým celkem, ale ve skutečnosti může být tvořeno několika (dílčími) fyzickými úložišti. Nejčastěji je nejméně jedno „fyzické“ úložiště realizováno uvnitř počítače programovými prostředky, a další mají podobu čipových karet či USB tokenů, které si uživatel vkládá do příslušných čteček, snímačů, portů atd. až v momentě potřeby jejich obsahu.
Smysl existence různých fyzických úložišť je snad vcelku zřejmý: čipové karty, USB tokeny a další „externí“ nosiče slouží zejména k uložení vlastních certifikátů a souvisejících privátních klíčů. Zvyšuje se tím bezpečnost, což je dáno i konstrukcí těchto nosičů (když privátní klíč z nich obvykle ani nejde vyexportovat).
Pro naše momentální potřeby (pro instalaci kořenových certifikátů certifikačních autorit) ale nejsou takovéto externí fyzická úložiště zajímavá: my řešíme instalaci certifikátů, které jsou plně veřejné (a bez odpovídajících privátních klíčů – ty si musí chránit příslušná certifikační autorita jako oko v hlavě, a nám je pochopitelně nedává).
Nás tedy budou zajímat „interní“ fyzická úložiště, realizovaná programovými prostředky uvnitř našeho počítače. Například u systémového úložiště v MS Windows prostředky tohoto operačního systému (a v případě Firefoxu jeho programovými prostředky).
I v rámci těchto „interních“ fyzických úložišť však někdy musíme umět správně rozlišit. Vynecháme-li potřebu správce sítě, který spravuje certifikáty a úložiště na více počítačích, můžeme se i jako koncoví uživatelé dostat do situace, kdy na svém počítači nejsme sami. Tedy kdy pracujeme na počítači, který má více (skutečně používaných) uživatelských účtů – a pak potřebujeme rozlišit, zda se naše vyjádření důvěry (skrze instalaci certifikátů) má týkat skutečně jen nás (našeho uživatelského účtu na daném počítači), nebo všech uživatelů na daném počítači.
Na platformě MS Windows a pro systémové úložiště se tato volba odehrává tak, že si při vkládání certifikátů necháme zobrazit fyzická úložiště – a pak volíme mezi „Registry“ (pak jde jen o náš uživatelský účet), a „Local Computer“.
Vše ukazuje obrázek, na kterém vidíte i momentálně připojený USB token (jako možnost „Karta smart card“). Povšimněte si také nutnosti zatrhnout volbu „Zobrazit fyzická úložiště“). A ještě jedna poznámka: aby se vám zobrazila možnost „Local Computer“, umožňující instalovat certifikáty způsobem ovlivňujícím všechny uživatelské účty na daném počítači, musíte mít aktuálně práva správce.
Účely certifikátu
Ještě další věcí, o které potřebujeme vědět před instalací certifikátů, je existence různých účelů jejich využití. Svým způsobem jsme na to již narazili: certifikáty můžeme chtít používat k různým účelům – jako koncoví uživatelé můžeme naše osobní certifikáty používat například k přihlašování k naší datové schránce (tj. k identifikaci a autentizaci klienta vůči serveru), či k podepisování dokumentů, které chceme skrze datovou schránku odeslat (což jako fyzické osoby nemusíme, ale třeba právnické osoby jednající více jednateli současně musí). Jiné certifikáty (ty komerční) pak můžeme vyžívat pro šifrování naší korespondence a mnoho dalších účelů.
Podobně mohou být k různým účelům využívány i certifikáty certifikačních autorit: jsou to vlastně kvalifikované systémové certifikáty, a jako takové mohou být používány například k vydávání (podepisování) osobních či systémových certifikátů koncovým zákazníků, k podepisování seznamů odvolaných certifikátů, k vytváření časových razítek apod.
Celá problematika „účelů“ je dosti komplikovaná – ale pro naše praktické potřeby (týkající se zejména užívání datových schránek) vystačíme s následující představou: každý certifikát si v sobě nese pevně nastavený výčet účelů, ke kterým je určen. Nicméně každá aplikace, která s ním pracuje, obecně pracuje se svou vlastní představou o těchto účelech, neboli s vlastním výčtem účelů použití. A v praxi se (asi bohužel ) mohou lišit i v tom ohledu, že aplikace používá certifikát k širšímu rozsahu účelů, než jaký předpokládá samotný certifikát.
Ukažme si to nejprve na příkladu Firefoxu, který to má vyřešeno relativně jednoduše. U certifikátů certifikačních autorit rozlišuje tři účely, viz následující obrázek:
Právě u kořenových certifikátů bychom to ale měli chápat spíše ve smyslu dědičnosti. Třeba u „identifikace serveru“ jde o to, zda „podřízené“ certifikáty (tj. certifikáty vydané koncovým zákazníkům) smí nebo nesmí být použity pro potřeby identifikace serveru.
Konkrétně: pokud si kořenového certifikátu CA PostSignum a „vydávajícího“ certifikátu PostSignum VCA nezaškrtnete možnost „identifikovat server“, a následně vstoupíte s Firefoxem na webový portál ISDS (na adresu https://mojedatovaschranka.cz), Firefox si nedokáže odvodit důvěryhodnost zdejšího serverového certifikátu (pro účely „identifikování serveru“), a vrátí vám známou varovnou hlásku. Pokud si ale u nadřazených certifikátů zaškrtnete „identifikovat server“, již vás na portál ISDS pustí (protože si dokáže důvěryhodnost zdejšího serverového certifikátu, vydaného komerční autoritou PostSignum).
Na následujícím obrázku vidíte ilustrativní příklad první možnosti: kořenový certifikát PostSignum ani vydávající certifikát PostSignum VCA nemají zaškrtnut účel „identifikace serveru“. A tak Firefox sice správně rozpozná (komerční) serverový certifikát, kterým se identifikuje portál ISDS, a odvodí si že je vydán komerční autoritou PostSignum a je platný – ale už na tento certifikát nemůže „přenést“ možnost jeho využití pro potřeby identifikace serveru. A tak nedokáže jeho důvěryhodnost pro tento účel posoudit – a tak vypisuje známou hlášku, viz obrázek.
Pro názornost jsem pro potřeby uvedeného obrázku nainstalovat do svého Firefoxu toto malé rozšíření, které v pravém horním rohu nejspodnějšího okna ukazuje způsob dědění účelů u daného serverového certifikátu a jeho dvou nadřazených certifikátů.
Pro daný případ (přístup k ISDS) by řešením bylo zaškrtnout účel „identifikace serveru“ alespoň u kořenového serveru CA PostSignum. Pak by tento účel zdědil i vydávající certifikát komerční CA PostSignum (VCA), a od něj i konkrétní serverový certifikát. Stejně tak by v daném případě (ale jen v něm) zaúčinkovalo i nainstalování daného serverového certifikátu do složky „Servery“. A to vlastně hned dvakrát, jednou pro server na adrese login.mojedatovaschranka.cz a jednou pro www.mojedatovaschranka.cz.
V případě Internet Exploreru (resp. systémového úložiště certifikátů v MS Windows) je situace analogická. Jen „okénka“ jsou jiná, a s nimi je jiný (mnohem rozsáhlejší) i výčet možných účelů, ke kterým lze konkrétní certifikát do úložiště nainstalovat. Je možné povolit všechny tyto účely, nebo je všechny zakázat, nebo je nastavovat každý jednotlivě, viz obrázek.
Pro potřeby identifikace serveru (pro přístup na webový portál ISDS) je podstatný hned první uvedený účel – „ověření serveru“.
Systémové úložiště MS Windows má ještě jednu výhodu, kterou u Firefoxu postrádám, a to možnost označit jednotlivé certifikáty vlastním (popisným) názvem. Příklad vidíte na předchozím obrázku (viz horní kolonky „Popisný název“ a „Popis“), důsledek pak na následujícím obrázku (na výpisu certifikátu, viz kolonka „Popisný název“.
A ještě jedna malá poznámka: k ověřování elektronických podpisů na datových zprávách, které dostaneme od orgán veřejné moci skrze datovou schránku, budeme nejspíše používat Adobe Reader. Tomu bychom také mohli nainstalovat příslušné kořenové certifikáty do jeho vlastního úložiště certifikátů. Již jsme se ale zmínili, že Adobe Reader umí (pokud si to jeho uživatel přeje) pracovat s certifikáty v systémovém úložišti MS Windows.
Ovšem aby mohl Adobe Reader „zdejší“ certifikáty skutečně využít k ověření podpisu, měly by mít povolený („zaškrtnutý“ ) i účel „podepisování dokumentů“.
Konečně: instalujeme certifikáty
Nyní, když už známe všechny potřebné prerekvizity (alespoň na úrovni, potřebné pro běžného koncového uživatele), si již můžeme ukázat, jak konkrétně nainstalujeme konkrétní kořenové certifikáty.
Začít instalovat přitom můžeme více různými způsoby, například rovnou z webu (z nabídky certifikátů na webu). Vzhledem k doporučením v úvodu článku si ale raději ukážeme začátek pro situaci, kdy potřebné certifikáty již máme „u sebe“ (například na CD či flash paměti), a k ruce máme i otisky, pro ověření pravosti instalovaných certifikátů.
Nejprve si to ukažme na příkladu Internet Exploreru, skrz který instalujeme certifikáty do systémového úložiště MS Windows. Zde je nejjednodušší začít otevřením (systémového) úložiště, ke kterému se dostaneme Internet Exploreru: v hlavním menu položka „Nástroje“, pak „Možnosti Internetu“, pak záložka „Obsah“, možnost „Vydavatelé“ (nebo „Certifikáty“), a pak konkrétní záložka podle toho, jaký certifikát instalujeme (viz výše).
Příklad, pro instalaci kořenového certifikátu do složky pro „důvěryhodné kořenové certifikační autority“, ukazují následující obrázky.
Vyjdeme z požadavku na „Import“, což způsobí aktivaci průvodce. Ten uživatele provede výběrem souboru s certifikátem a následně nabídne možnost volby „přihrádky“ (resp. složky) pro instalování. Jelikož jsme záměrně začali požadavkem na import z konkrétní složky (pro důvěryhodné kořenové certifikační autority), průvodce to respektuje a i dále předpokládá, že chceme instalovat certifikát do této složky.
Raději tohoto průvodce nepouštějme k tomu, aby se rozhodoval za nás (tj. sám automaticky zvolil správnou složku). Moje zkušenost s MS Vista je taková, že průvodce se nerozhoduje správně a kořenové certifikáty PostSignum i eIdentity instaluje do jiné složky než by měl.
V tuto chvíli si ještě připomeňme členění úložišť: pokud chceme instalovat kořenový certifikát „jen pro sebe“ (jen pro uživatelský účet, který právě používáme), nemusíme nic měnit (implicitně instaluje do „Registry“). Pokud ale chceme instalovat certifikát „pro celý počítač“, musíme právě v tuto chvíli explicitně zvolit úložiště důvěryhodných kořenových certifikátů ve variantě „Local Computer“, viz již jednou použitý obrázek (ke kterému se dostaneme z poslední části předchozího obrázku volbou „Procházet“ úložiště).
Nyní nám průvodce již jen zrekapituluje naše volby.
Pokud mu své volby potvrdíme, následuje ještě jeden – nesmírně důležitý – krok: v případě, že instalujeme do složky pro kořenové certifikáty důvěryhodných certifikačních autorit, jsme dotázáni, zda skutečně chceme instalovat ten certifikát, který jsme právě vybrali. V rámci tohoto dotazu je nám zobrazen i otisk (miniatura certifikátu), a tak právě toto je ten rozhodující okamžik, kdy bychom si měli vzít k ruce údaje o otisku kořenového certifikátu, získané z dostatečně důvěryhodného zdroje, a porovnat údaje navzájem.
Pokud si jsme jisti shodou, můžeme vše potvrdit – a pokud je instalace úspěšná, systém nám to rád oznámí.
Podobně je tomu v případě Firefoxu: v jeho hlavním menu vyjdeme z položky „Nástroje“, přes „Možnosti“, záložku „Rozšířené“ a volbu „Certifikáty“ se již dostaneme k jeho úložišti certifikátů. Zde přejedeme do složky „Autority“ (která bude stejná i pro „vydávající“ certifikáty Postsignum a eIdentity). A opět volíme „Importovat“ (ve smyslu: do této složky“) – načež musíme vybrat správný soubor s certifikátem.
Nyní jsme (na rozdíl od Internet Exploreru) dotázáni Firefoxem na to, k jakým účelům chceme daný certifikát instalovat (význam viz výše). To Internet Explorer se nás při instalaci na účely neptal – a sám si nastavuje „všechny“. Pokud máme jiný názor, musíme mu to sdělit dodatečně.
Firefox nás zase explicitně nevaruje před instalací kořenových certifikátů. Možná proto, že ještě neví, že jde o kořenový certifikát (když na ně nemá speciální složku), a že to zjišťuje až při skutečnému ukládání. Proto na ověření pravosti certifikátů musíme pamatovat sami, nechat si zobrazit detaily certifikátu a porovnat je s otiskem získaným z důvěryhodného zdroje, viz obrázek.
Oprava
Na závěr bych rád opravil jednu chybu, které jsem se dopustil v minulém článku. Jde o to, že „předinstalované“ certifikáty certifikačních autorit ve Vistách je přeci jen možné odinstalovat. Jen je na to zapotřebí mít aktuálně práva administrátora. V roli běžného uživatele to skutečně nejde.
Nicméně stále platí, že i když si nějaký takovýto „předinstalovaný“ certifikát jako správce odinstalujete, Windows vám je obratem a bez vašeho vědomí zase doinstalují zpátky (v okamžiku, kdy jsou zapotřebí). Tato možnost jde vypnout (alespoň na Vistách Ultimate a Enterprise), ale lze ji také „selektivně přehlušit“ tím, že konkrétní certifikát nainstalujete mezi ty nedůvěryhodné (do složky pro nedůvěryhodné certifikáty). Pak se tento certifikát již nebude automaticky doinstalovávat (mezi důvěryhodné).
Tímto děkuji laskavým čtenářům, kteří na tyto skutečnosti upozornili pod minulým článkem. A pokud jde o tento článek či další díly: narazíte-li na nějakou nepřesnost či chybu, prosím upozorněte na ni a podělte se o správnou verzi. Získat a ověřit všechny informace není triviální, a já rozhodně nemusím vědět o všem a všemu rozumět správně.
ČLÁNKY DO MAILU