Hlavní navigace

Jak na OpenSSL II

Michal Kára 2. 5. 2003

Minule jsme si řekli něco o principech SSL. Dnes se podíváme na generování certifikátů, a to jak jednotlivého certifikátu, tak i mnoha různých, podepsaných vlastní certifikační autoritou.

Jak na to – osamělý vlk

Pokud potřebujete pouze jeden certifikát, nemusíte si příliš dělat starosti, prostě jej vygenerujete příkazem, jako například:

openssl req -new -x509 -nodes -out
 cert.pem -keyout key.pem -days 1098

Nyní si rozeberme jednotlivé části příkazu:

  • openssl – utilita openssl je hlavním pomocným programem stejnojmenného balíku, slouží pro manipulaci s certifikáty, klíči, testování, …
  • req – budeme pracovat s certifikační žádostí
  • -new – žádost nebudeme načítat ze souboru, ale vytvoříme novou
  • -x509 – nebude se vytvářet certifikační request, ale už rovnou certifikát podepsaný sám sebou (self-signed)
  • -nodes – soukromý klíč nebude zašifrován (viz předchozí díl)
  • -out cert.pem – certifikát zapsat do uvedeného souboru
  • -keyout key.pem – klíč zapsat do uvedeného souboru
  • -days 1098 – certifikát bude platit 3 roky

Při provádění příkazu budeme požádáni o zadání doplňujících informací, jména, organizace, adresy, emailu. A také jména (CN). To je nejdůležitější pole, zde se vyplní jméno serveru, pro který má být certifikát vystaven, například www.sajta.cz.

Tímto jsme vytvořili certifikát podepsaný sám sebou. Když jej použijeme například pro WWW server, bude browser pravděpodobně upozorňovat, že je certifikát nedůvěryhodný. V Mozille je možno přímo z tohoto dialogu akceptovat navždy takovýto certifikát, do Internet Exploreru se musí složitě importovat (alespoň, co vím). O tom více dále.

Vygenerované soubory

Nyní se ještě podíváme do souborů, které jsme vytvořili. cert.pem obsahuje:

-----BEGIN CERTIFICATE-----
(binární data vyjádřená v tištitelných znacích ASCII)
-----END CERTIFICATE-----

key.pem má podobný obsah, jen místo CERTIFICATE je tam RSA PRIVATE KEY (protože openssl bez dalších voleb vytváří RSA klíč). Jak ale zjistíme, co je v tom „binárním blábolu“ uloženo? Opět nám pomůže příkaz openssl. Zadáme:

openssl x509 -in cert.pem -text

a

openssl rsa -in key.pem -text

Dotyčné příkazy vypíší certifikát či klíč v přehledném (no, víceméně :-) formátu čitelném člověkem.

Ještě něco o parametrech:

  • openssl – opět stejná utilitka
  • x509 – budeme pracovat s certifikátem (ve formátu x509)
  • rsa – budeme pracovat s RSA klíčem
  • -in soubor – soubor, který se má číst
  • -text – výstup bude v textovém (člověkem čitelném) formátu

Modifikátor -text můžeme přidat už do příkazu pro vytvoření certifikátu, potom bude certifikát zapsán i v lidsky čitelném tvaru. Aplikacím, které s certifikáty pracují, přítomnost textového tvaru nevadí (tedy, neměla by :-), je zajímá jen to, co je mezi BEGIN CERTIFICATE a END CERTIFICATE.

Občas se můžeme setkat s tím, že aplikace vyžadují certifikát a klíč v jednom souboru. Toho docílíme jednoduchým spojením:

cat cert.pem key.pem >certkey.pem

Jak na to – certifikační autorita

Pokud chceme vydávat více certifikátů a chceme, aby klienti nebyli otravováni hláškami o nedůvěryhodných certifikátech, je vhodné si zřídit vlastní certifikační autoritu. Principiálně bude celý proces fungovat tak, že si vygenerujeme vlastní certifikát a klíč certifikační autority. Certifikát naimportujeme do počítačů, jež budou s našimi servery komunikovat. Potom můžeme začít generovat certifikáty pro jednotlivé servery, které budou podepsané touto certifikační autoritou a budou klientskými programy považovány za důvěryhodné.

Poznámka: Tento návod a postup je realizovatelný spíše ve firemních sítích. Nutit všechny uživatele instalovat certifikát by u veřejného serveru bylo trochu nepraktické, i když možné. Ale pokud chcete mít opravdu „profesionální“ řešení, nezbývá, než si nechat certifikát podepsat od některé „oficiální“ certifikační autority.

Konfigurace

OpenSSL má konfigurační soubor, většinou to je /etc/ssl/open­ssl.conf. Soubor je dlouhý a má spoustu voleb, zde proberu jen ty nejzajímavější:

Sekce [ ca ] (certifikační autority)

  • default_ca – Jméno výchozí certifikační autority (můžete jich mít i více,  ale to asi nevyužijete). Nechte, jak je.

Sekce [ CA_default ]

Obsahuje nastavení výchozí certifikační autority, zejména, kde jsou uloženy její soubory. Důležitým nastavením je adresář.  Jeho výchozí hodnotou je adresář demoCA v adresáři SSL (většinou /etc/ssl). Pod ním jsou všechny soubory a adresáře s certifikační autoritou související. Nové certifikáty se ukládají v adresáři newcerts, v adresáři private je klíč certifikační autority, certifikát je přímo v „rootu“ CA.

Příklad nastavení:

dir           = ./demoCA               # Kořenový adresář CA
certs         = $dir/certs             # Kam se ukládají vydané
                                       # (podepsané) certifikáty
crl_dir       = $dir/crl               # Kam se ukládají CRL
database      = $dir/index.txt         # Index databáze
new_certs_dir = $dir/newcerts          # Kam se ukládají nové
                                       # certifikáty
certificate   = $dir/cacert.pem        # Certifikát CA
serial        = $dir/serial            # Soubor se sériovám číslem
                                       # (pro počítání vydaných
                       # certifikátů)
crl           = $dir/crl.pem           # Aktuální CRL
private_key   = $dir/private/cakey.pem # Soukromý klíč CA
RANDFILE      = $dir/private/.rand     # Soubor pro generování
                                       # náhodných čísel

Dále asi budete chtít změnit počet dní, na které se certifikát podepisuje (default_days):

default_days = 3600

Pokud nejste rigorózní certifikační autorita, asi se bude hodit nastavit politiku (policy) na volnou:

policy = policy_anything

Význam jednotlivých politik spočívá v tom, jak přísné jsou na jednotlivé položky, jejich definici najdete pod položkou policy.

Důležitá je rovněž sekce [ req_distinguished_na­me ]. V ní se nastavují jména jednotlivých údajů (co se bude zobrazovat při vytváření certifikátů) a hlavně jejich výchozí hodnoty. Takže pokud si v této sekci nastavíte dobré hodnoty (jméno organizace a adresu), nebudete je muset při vytváření certifikátů opakovaně vypisovat, ale jen odklepnete výchozí. U některých (například e-mail) není nastavení výchozí hodnoty v defaultní konfiguraci SSL uvedeno, ale je možné, například:

emailAddress_default = webmaster@sajta.cz

Generování certifikátu CA

Nejprve vytvoříme adresář pro certifikační autoritu (viz konfigurace výše, například /etc/ssl/demoCA). V něm vytvoříme potřebné podadreasáře (certs crl newcerts private). Vytvoříme prázdný soubor index.txt (touch index.txt) a soubor serial s obsahem 01:

echo 01 >/etc/ssl/demoCA/serial

Dále si vygenerujeme certifikát samotné certifikační autority. Bude to certifikát podepsaný sám sebou, uděláme to podobně jako v příkladu výše:

openssl req -new -x509 -nodes -out
 cacert.pem -keyout cakey.pem -days 1098

Jako Common Name zadejte třeba Certifikační autorita.

Počet dní můžete klidně i zvýšit, ať nemusíte certifikát každé tři roky měnit :-) Soubory umístěte tam, kde mají být (certifikát v /etc/ssl/demoCA, klíč v /etc/ssl/demo­CA/private). Klíč pro jistotu ochraňte proti čtení ostatními uživateli (chmod 400 cakey.pem).

Instalace certifikátu

Aby byly podepsané certifikáty důvěryhodné, je třeba certifikát autority importovat jako důvěryhodnou CA (kořenový certifikát). Souboru s certifikátem dáme příponu .crt. Když jej potom otevřeme ve Windows, samy nám nabídnou jeho naimportování. V importovacím dialogu není potřeba nic měnit, stačí klikat na Dále, Dokončit a OK. Tento certifikát pak využívají všechny aplikace ve Windows (Outlook, Explorer, atd.)

Podobně, když dáme takovýto certifikát otevřít v Mozille, můžeme jej naimportovat jako důvěryhodný.

Ještě pár slov k přenosu certifikátu. Nejjednodušší je vystavit jej na WWW. Ovšem pokud ono WWW nebude samo zabezpečené důvěryhodným certifikátem, můžeme klidně stáhnout podstrčený certifikát. Pokud si chceme být opravdu jisti, musíme si buď nosit certifikát na disketě, nebo alespoň kontrolovat jeho signaturu.

Vytvoření podepsaného certifikátu

Nyní budeme simulovat klasický proces podepisování. To funguje tak, že klient si vytvoří pár klíč-žádost o certifikát. Klíč si nechá (musí být držen v tajnosti) a žádost pošle certifikační autoritě spolu s domumenty, které prokazují, že to je opravdu on. Autorita si údaje ověří, a pokud je vše v pořádku, certifikát podepíše a odešle zpět.

Nejprve tedy vytvoříme žádost:

openssl req -new -nodes -out
 request.pem -keyout key.pem -days 1098

Získáme žádost a klíč. Teď si zahrajeme na certifikační autoritu. Použijeme k tomu mód „ca“ příkazu openssl:

openssl ca -in request.pem -out cert.pem

Parametry jsou jasné:

  • ca – mód certifikační autority
  • -in request.pem – vstupní soubor
  • -out cert.pem – výstupní soubor

Odklepneme, že chceme certifikát podepsat, a pak ještě jednou potvrdíme.

A sláva, ve výstupním souboru máme podepsaný certifikát. Dokonce obsahuje i lidsky čitelný formát, takže si to můžeme rovnou ověřit (pole Issuer).

Co se stalo v rootu CA

Pokud si prohlédneme soubory v rootu CA, můžeme si všimnout následujícího:

  • V souboru serial už není 01 ale 02.
  • V adresáři certs se objevil soubor se jménem 01 obsahující podepsaný certifikát.
  • V souboru index.txt se objevil řádek s údaji o certifikátu.

Takto si certifikační autorita udržuje přehled o všech jí podepsaných certifikátech.

Co dál

Certifikáty máme vygenerované. Příště se budeme zabývat jejich instalací na server a povíme si něco o různých problémech, na které můžeme při používání SSL narazit.

Našli jste v článku chybu?

6. 2. 2007 12:23

peter (neregistrovaný)
Dobry clanok, pouzijem ho vzdy, ked robim (par-krat rocne) nieco s certifikatmi. Akurat mi nikdy nesiel vygenerovat certifikat platny viac dni, nez je nastavene v openssl.cnf. Nakoniec som v manuali nasiel, ze prepinac "-days" sa ma pouzit pri "ca" mode (pri vytvarani podpisaneho certifikatu) a nie pri vytvarani requestu.

Teda: openssl ca -in request.pem -out cert.pem -days 1098

Peter



Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Vitalia.cz: Tesco: Chudá rodina si koupí levné polské kuře

Tesco: Chudá rodina si koupí levné polské kuře

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

Root.cz: 250 Mbit/s po telefonní lince, když máte štěstí

250 Mbit/s po telefonní lince, když máte štěstí

Vitalia.cz: Znáte „černý detox“? Ani to nezkoušejte

Znáte „černý detox“? Ani to nezkoušejte

DigiZone.cz: Recenze Westworld: zavraždit a...

Recenze Westworld: zavraždit a...

Podnikatel.cz: Babiše přesvědčila 89letá podnikatelka?!

Babiše přesvědčila 89letá podnikatelka?!

Podnikatel.cz: EET: Totálně nezvládli metodologii projektu

EET: Totálně nezvládli metodologii projektu

DigiZone.cz: Rádio Šlágr má licenci pro digi vysílání

Rádio Šlágr má licenci pro digi vysílání

Vitalia.cz: Chtějí si léčit kvasinky. Lék je jen v Německu

Chtějí si léčit kvasinky. Lék je jen v Německu

DigiZone.cz: Sony KD-55XD8005 s Android 6.0

Sony KD-55XD8005 s Android 6.0

Root.cz: Certifikáty zadarmo jsou horší než za peníze?

Certifikáty zadarmo jsou horší než za peníze?

Podnikatel.cz: Na poslední chvíli šokuje výjimkami v EET

Na poslední chvíli šokuje výjimkami v EET

Podnikatel.cz: Babiš: E-shopy z EET možná vyjmeme

Babiš: E-shopy z EET možná vyjmeme

Lupa.cz: UX přestává pro firmy být magie

UX přestává pro firmy být magie

Podnikatel.cz: Chtějte údaje k dani z nemovitostí do mailu

Chtějte údaje k dani z nemovitostí do mailu

120na80.cz: Horní cesty dýchací. Zkuste fytofarmaka

Horní cesty dýchací. Zkuste fytofarmaka

Vitalia.cz: Paštiky plné masa ho zatím neuživí

Paštiky plné masa ho zatím neuživí

Podnikatel.cz: Podnikatelům dorazí varování od BSA

Podnikatelům dorazí varování od BSA

Lupa.cz: Teletext je „internetem hipsterů“

Teletext je „internetem hipsterů“