Copyright © 1997 RNDr. Libor Dostalek
 
 

Certifikační autorita

Certifikační autorita je poměrně složitý mechanizmus. Můžeme se také omezit na pouhé konstatování, že CA vydává certifikáty. Podobně jako automobilka vyrábí automobily, ale podíváte-li se podrobněji na automobilku, pak uvidíte, že se skládá z motorárny, karosárny, lakovny atd.

CA se skládá za tří základních částí: registrační autority, certifikační autority a správní autority.

Legenda k obrázku:
 
Zákazník příjde na Registrační autoritu (RA) s žádostí o certifikát (1) např. na disketě. Registrační autorita může prověřovat totožnost žadatele (v případě CA tříd 2 a 3). Shledá-li RA vše v pořádku, pak žádost podepíše klíčem RA a předá k vyřízení CA (2). CA verifikuje podpis RA a  vystaví certifikát, který předá zpět RA (3) společně s certifikátem CA, případně řetězcem certifikátů až k root CA. Registrační autorita předá (např. na disketě) žadateli (4): 
  • Vydaný certifikát.
  • Certifikát CA, případně certifáty všech nadřízených CA.
  • Může předat i CRL.
CA předá vydaný certifikát také správní autoritě (5), která jej může uložit do adresáře (6). Uživatelé Internetu si pak mohou certifikát získat např. protokolem LDAP, případně Secure LDAP (tj. LDAP over SSL). 

 

Zákazník CA se zpravidla nazývá uživatelem CA bez ohledu na to, zda-li požaduje vydání uživatelského (klientského) certifikátu, certifikátu pro server nebo dokonce certifikátu pro podřízenou CA.

Uživatel komunikuje s Registrační autoritou (RA), která v případě certifikační autority třídy 2 a 3 kontroluje totožnost uživatele. V případě CA třídy 1 není zpravidla nutné, aby se uživatel dostavil na RA osobně - vše probíhá elektronickou cestou.

Mechanizmus prověřování totožnosti uživatele definuje CA opět v dokumentu "Certifikační politika CA".

Správní autorita je zodpovědná za údaje vystavené v adresáři. Jelikož se pohybujeme v oblasti doporučení řady X, tak bychom měli napsat, že ostatní uživatelé získávají informace z adresáře protokolem DAP (Directory Access Protocol) specifikovaný doporučením X.519. Jak jsme však již uvedli, v Internetu se používá zjednodušený protokol DAP - Lightweit DAP neboli LDAP specifikovaný RFC1777.

Pokud uživatelé Internetu získávají z adresáře celé certifikáty, tak ty jsou elektonicky podepsané CA, avšak z adresáře je možné získávat i jiné údaje, pak je nutné, aby se LDAP-server autentizoval (tj. abychom si byli jisti, že komunikujeme s tím pravým serverem), v takovém případě je jistější použít protokol Secure LDAP (musím však mít certifikát adresářového serveru).
 

Certifikát CA a řetězec certifikátů

Chci-li používat nějaký certifikát, pak: Všiměte si, že na to abych mohl certifikát používat, tak nepotřebuji komunikovat s CA, potřebuji pouze znát veřejný klíč CA, abych mohl certifikát verifikovat. Takže před tím, než mohu použít nějaký certifikát, pak musím mít k dispozici certifikát CA, která jej vystavila. CA tedy ani nemusí být připojena k Internetu (k síti).

S certifikátem CA mohou nastat tři situace:

  1. Certifikát CA je podepsán samotnou CA (tou samou), čili certifikát CA je podepsán soukromým klíčem CA, který přísluší k veřejnému klíči uvedenému v certifikátu CA. Čili issuer a subject v certifikátu jsou téměř shodné (slovo téměř sovisí s tím, že v případě, že CA chce vydávat certifikáty s jednoznačným polem subject, pak při dalším vydání certifikátu musí provést mírnou změnu do pole subject aby zajistila jednoznačnost).

    2.  

     

    Certifikát podepsaný tou samou CA se nazývá root (kořenový) certifikát. Díky tomu, že je root certifikát podepsán sám sebou, tak musíme být opatrní na distribuci takových certifikátů. Zpravidla se distribuují jako součást software. V případě, že je získáváme jinou cestou, pak je na místě si telefonicky prověřit jejich fingerprint. Fingerprint je krátký kontrolní součet z certifikátu (nebo veřejného klíče nehraje-li se na certifikáty), který většina software umí spočítat a obsluha certifikační autority Vám jej ráda zarecituje do telefonu.


     

  2. Certifikát CA je podepsán jinou (nadřízenou) CA. Nadřízená CA může mít svůj certifikát podepsán od CA ještě vyšší instance atd. V řetězci CA je pak nejvyšší CA - root CA, která si podepisuje svůj certifikát sama sobě.

    3.  

     

    Chtějí-li komunikovat dva uživatelé mezi sebou, pak si vzájemně vymění řetězce certifikátů. Řetězcem certifikátů rozumíme posloupnost certifikátů od certifikátu uživatele, přes certifikát CA, která uživateli certifikát vydala, až po root CA.
     

  3. Poslední a méně běžnou možností je křížová certifikace, tj. certifikační autority si podepíší své certifikáty vzájemně.

    4.  

     


    Uživatel-1 věří certifikátu certifikační autority CA-1. Před tím, než uživatel-1 může komunikovat s uživatelem-2, tak si vzájemně vymění řetězce certifikátů, které verifikují. Na předchozím obrázku je znázorněno, jak uživatel-1 obdržel řetězec certifikátů od uživatele-2 a chce jej verifikovat.

    V případě, že uživatel-1 chce verifikovat certifikát uživatele-2, který je podepsán certifikační autoritou CA-2, tak na začátku komunikace od uživatele-2 obdrží dvojici certifikátů:

    Uživatel-1 verifikuje certifikát CA-2 za pomoci certifikátu CA-1, kterému věří a následně verifikuje certifikát uživatele-2.
Nyní se vrátíme k řetězci certifikátů tvořenému certifikáty od certifikátu uživatele, přes certifikát CA, která uživateli certifikát vydala až po root certifikát. Jestliže chcete takovýto řetězec používat pak musíte verifikovat  nejprve certifikát uživatele, pomocí certifikátu CA, která uživateli certifikát vydala, pak verifikovat certifikát této CA, pak nadřízené CA až k root CA:

Na závěr ještě jednou opakuji, že pro vzájemnou komunikaci dvou uživatelů (např. klientu a serveru) je třeba aby si minimálně server nechal vydat certifikát, ale pak již při své komunikaci nepotřebují aby do této komunikace vstupovala CA - ta si svou práci udělala tím, že certifikáty vydala. CA však může vstoupit do hry v případě, že by si uživatelé chtěli na CA ověřit, že certifikát protějšku není na CRL, tj. v případě, kdy uživatel chce od CA získat CRL.

Princip použití certifikátu

Pomocí certifikátu je možné prokazovat totožnost podobně jako občanským průkazem. U občanského průkazu se prokazuje totožnost na základě podobnosti člověka s jeho orazítkovanou fotografií. Pomocí certifikátu se prokazuje totožnost na základě znalosti (vlastnictví) soukromého klíče.

Nyní si ukážeme princip identifikace (prokázání totožnosti) pomocí certifikátu. Představme si, že spolu chtějí komunikovat dvě strany - např. klient a server. Nejprve si vymění své certifikáty, pomocí kterých se budou následně autentizovat. Přitom autentizace serveru bývá povinná, kdežto autentizace klienta nepovinná:

Nyní následuje autentizace serveru:

Princip autentizace klienta může být obdobný:

Avšak v praktické realizaci může být autentizace modifikována a dialog zjednodušen.

Nyní již každá strana bezpečně ví, že na druhém konci je ten pravý uživatel. Pokud certifikát obsahuje šifrovací klíč použitelný také k šifrování dat. Pak je možné, aby např. klient vygeneroval symetrický šifrovací klíč relace, zašifroval jej veřejným klíčem z certifikátu serveru (případně elektronicky podepsal) a předal serveru. Pak již obě strany mohou po přechodu na symetrickou šifru bezpečně komunikovat.

Proč dosud prakticky neexistuje světový systém CA?

Na první pohled se zdá jednoduché vybudovat takový systém - vždyť podobnou strukturu má DNS a tu se přece podařilo vybudovat.

Jenže kamenem úrazu je právě zodpovědnost. Zatímco v DNS Vám snadno někdo udělá delegaci na subdoménu nižší úrovně, protože když Vaše name servery nebudou korektně chodit, tak je to Váš problém a on z toho má nanejvýš ostudu. Nemůže však z toho mít nějakou materiální újmu.

Když ovšem podepíšete certifikát CA nižší úrovně, tak automaticky přejímáte zodpovědnost za všechny certifikáty, které tato CA vydá. Protože, když někdo věří vaší CA, tak automaticky bude verifikovat tyto certifikáty. Aby jedna firma automaticky ručila za něco co udělá jiná firma, tak to je potíž - asi by takové  vztahy musely být určeny zákonem.

Za co CA ručí a jaké provádí úkony

Pro mne to bylo překvapení, ale to nejdůležitější za co CA ručí je jednoznačnost vydaných certifikátů.

Konkrétně u certifikátů podle X.509 verze 1 ručí za to, že pro daný subject (rozlišitelné jméno uživatele) nebyl vydán jiný certifikát. Rovněž sériiové číslo certifikátu je jednoznačné.

Mne to překvapilo, ale jednoznačnost je přesně to, co je u certifikátů třeba a přitom to není až tak obtížné zaručit.

Dále CA může (pokud to specifikuje ve své certifikační politice) ručit za totožnost uživatele, který vlastní příslušnou dvojici veřejný/soukromý klíč (stále se snažím obcházet spojení "vlastník certifikátu", protože není zcela jasné zdali jím je uživatel nebo CA).

Avšak prokazovat totožnost fyzické nebo právnické osoby je nejenom nákladné, ale i obtížné. Vždyť i občanské průkazy byly vydány neoprávněným osobám, které na ně např. v restitucích získaly majetek.

CA, které ručí za totožnost, někdy specifikují do jaké výše škody ručí. Např. do milionu $. Tím nepřímo CA sdělují výši své důvěryhodnosti.

V každém případě CA ručí svým jménem, což může být větší ručení než milion $, protože ztráta jména znamená v této oblasti krach. Podobně jako mincovně by se nevyplatilo si vyrazit pár korun navíc.

CA mohou provádět i jiné notářské úkony než pouze vydávání certifikátů. To však bude aktuální až darovací, zakládací, zřizovací, převodní a jiné listiny jako např. závěť se budou vyhotovovat v elektronické podobě. Dalšími notářskými úkony může být časové razítkování dokumentů či elektronické ověřování transakcí.
 

Vadí zničení soukromého klíče CA?

Teoreticky ne, i když to může ohrozit právě jméno  CA. V případě zničení soukromého klíče CA (tj. klíče kterým prodepisuje vydávané certifikáty) je možné používat všechny vydané certifikáty.

Co tedy nelze? Nelze vydávat nové certifikáty. CA si musí vygenerovat novou dvojici veřejný/soukromý klíč a nový certifikát CA.

Vlastně je to podobná situace jako s razítkem. V případě jeho zničení se nechá udělat nové, ale v případě zcizení je to slušně řečeno nepříjemné.

Třídy CA