SSL - 1 (certifikáty)

24. 2. 2006 | Rastislav Stanik | Bezpečnost | 20351×

Co je SSL, jak se liší od GPG? Představení certifikačních autorit a vytvoření vlastní CA pomocí OpenSSL.

• Úvod
• Certifikačná autorita
• Certifikát
• Elektronický podpis
• Od CUI ku GUI
• Bezpečný web
• Odvolávam, čo som odvolal...

Úvod

Tento článok je jemným úvodom do problematiky bezpečnej elektronickej komunikácie. Ten, kto chce komunikovať v prostredí internetu bezpečným spôsobom, má na výber dve technológie. Jednou je použitie systému PGP resp. jeho implementácie GPG. Jeho charakteristikou je to, že dôveryhodnosť komunikácie je založená len na vzťahu odosielateľa a príjemcu. V istých situáciách však tento spôsob nie je vyhovujúci. Ak chceme komunikovať so štátnymi inštitúciami alebo servermi, ktoré sú prakticky mimo náš dosah, otvára sa priestor pre systém bezpečnostných certifikátov. Z technického hľadiska je tento systém označovaný skratkou SSL - Secure Socket Layer - ak ho chceme používať, tak najlacnejšou cestou je použitie balíka OpenSSL.

V systéme SSL nie je nutné, aby sa príjemca a odosielateľ navzájom osobne poznali. Overenie ich totožnosti zabezpečuje certifikačná autorita - CA. Je to organizácia, ktorá vydáva bezpečnostné certifikáty. Sú to dátové konštrukcie umožňujúce používanie elektronického podpisu. Ak dostanem správu od používateľa XY a tá správa je podpísaná jeho certifikátom, ktorý vydala CA, tak CA ručí za to, že ten certifikát bol vydaný práve používateľovi XY a nikto okrem neho nemohol vytvoriť príslušný podpis. Certifikáty tiež obsahujú kryptografické údaje, ktoré je možné použiť na šifrovanie dát pri elektronickej komunikácii.

Vo svete existuje mnoho certifikačných autorít. Sú to organizácie, ktoré na požiadanie vydajú certifikát, ktorý potom možno použiť na bezpečnú elektronickú komunikáciu. Medzi najznámejšie patrí RSA Security Inc. či VeriSign Inc. Ich certifikáty často používajú banky a medzinárodné internetové obchody. Certifikačná autorita ako organizácia musí dodržiavať prísne bezpečnostné pravidlá - počnúc fyzickým zabezpečením priestorov, kde sa činnosť CA vykonáva, cez off-site zálohy, až po bezpečnostné previerky pracovníkov a podobne. S tým sú prirodzene spojené náklady, ktoré CA často prenáša na svojich klientov. Vydanie certifikátu je preto spravidla platená služba. Existujú ale aj CA, ktoré vydávajú certifikáty za nízku cenu resp. zadarmo. Medzi najznámejšie CA tejto triedy patrí Thawte. Na Slovensku aj v Čechách platí už niekoľko rokov Zákon o elektronickom podpise, ktorý pre účely právne záväzného elektronického podpisu vyžaduje použitie štátom uznanej certifikačnej autority. Povolenie na činnosť CA vydáva Národný bezpečnostný úrad. Ten takisto vydáva bezpečnostné predpisy pre činnosť CA, vykonáva ich kontrolu a funguje ako "koreňová CA" - podpisuje certifikáty komerčných certifikačných autorít. Na Slovensku medzi akreditované CA patrí napr. CA EVPÚ v Novej Dubnici. (V Čechách certifikáty vydáva napr. aj Česká pošta, ale nie som si istý či tieto certifikáty spĺňajú všetky náležitosti vyžadované českou legislatívou.)

Certifikačná autorita

V niektorých situáciách nám postačí CA, ktorú si vytvoríme sami. Jediným problémom je, že musíme všetkých ľudí, s ktorými chceme komunikovať pomocou certifikátov vydaných našou CA, presvedčiť o dôveryhodnosti tejto CA. Certifikačné autority ako VeriSign, Thawte a pod., si svoju dôveryhodnosť získali mnohoročným pôsobením na trhu. Našťastie urobiť si vlastnú certifikačnú autoritu technicky nie je nijako zložité. Použijeme program OpenSSL. Pravdepodobne tak nesplníme podmienky, ktoré stanovuje Zákon o elektronickom podpise, ale pre účely nahliadnutia do problematiky to stačí. S použitím programu OpenSSL vytvoríme CA nasledovne:

V prvom rade vytvoríme súbor s parametrami pre vytvorenie DSA kľúča

openssl dsaparam -outform PEM -out CAdsaparamfile -genkey 1024
Generating DSA parameters, 1024 bit long prime
This could take some time
...+++++++++++++++++++++++++++++++++++++++++++++++++++*
.......+.....+.+..........+....+............+.+......................+..........
...+...........+...............+.........+.......+..........+...................
+..+.....+.+...........+....+.+.......+..............+....+................+....
.......+............+.............+..+......+.+...+.+....+.+....................
....+.......+.+................+............+.....+.....+..+....++++++++++++++++
+++++++++++++++++++++++++++++++++++*

Prvý parameter hovorí, že vytvárame DSA parametrický súbor. Ďalšie parametre hovoria, že výstup je vo formáte PEM, výstupný súbor bude mať meno CAdsaparamfile a generovaný kľúč bude mať dĺžku 1024 bitov. Balík OpenSSL používa konfiguračný súbor. Ten by mal byť spravidla umiestnený v /etc/ssl/openssl.cnf. Tam môžu byť preddefinované rôzne štandardné nastavenia. V tomto článku sa ho budem snažiť používať čo najmenej a pokiaľ možno, všetky požadované nastavenia definovať cez prepínače na príkazovom riadku.

Ďalším krokom je vytvorenie DSA kľúča:

openssl gendsa CAdsaparamfile -out CAdsaprivtekey
Generating DSA key, 1024 bits

Parametre tentoraz hovoria, že generujeme DSA kľúč s parametrami uvedenými v CAdsaparamfile a výstupný súbor sa bude volať CAdsaprivtekey.

Nasleduje predposledný krok - vytvorenie požiadavky na certifikát samotnej CA:

openssl req -new -x509 -key CAdsaprivtekey -out CAcertificate
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN. There are quite a few fields but you can leave
some blank. For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:SK
State or Province Name (full name) [Some-State]:Slovakia
Locality Name (eg, city) []:Trencin
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Rastos
Certificate
Authority
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:rastos CA
Email Address []:

V parametroch vidíme, že vyrábame požiadavku (request) pre vytvorenie nového certifikátu typu X509 s použitím DSA kľúča v súbore CAdsaprivtekey. Výsledný certifikát bude uložený do súboru s názvom CAcertificate. Tento certifikát budeme používať pre vytváranie certifikátov jednotlivých používateľov. Súbor s certifikátom je zakódovaný base64 kódovaním. Vyzerá takto:

-----BEGIN CERTIFICATE-----
MIIDuTCCA3mgAwIBAgIJANc8qEjrcbHnMAkGByqGSM44BAMwXjELMAkGA1UEBhMC
...
LAIUWMK6QHBbzNzOG4VznLxaXubHsKcCFDEXLLUV8REDXxLwTdQajeDWeerI
-----END CERTIFICATE-----

Ak chceme vidieť jeho obsah v zrozumiteľnej forme, pomôže nám tento príkaz:

openssl x509 -text -in CAcertificate -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            d7:3c:a8:48:eb:71:b1:e7
...

Pre fungovanie CA je potrebné urobiť ešte jeden krok - vytvoriť súbor, v ktorom bude OpenSSL udržiavať aktuálny zoznam vydaných a aj neplatných certifikátov a ich počet:

mkdir demoCA
touch demoCA/index.txt
echo 01 > demoCA/serial

Umiestnenie týchto súborov definuje konfiguračný súbor:

[ CA_default ]
dir             = ./demoCA              # Where everything is kept
database        = $dir/index.txt        # database index file.
serial          = $dir/serial           # The current serial number

Certifikát

Ak chce používateľ dostať certifikát od našej CA, musí nám najprv poslať požiadavku (request):

openssl req -new -out RScertrequest -keyout RSprivatekey
Generating a 1024 bit RSA private key
......................................++++++
.++++++
writing new private key to 'RSprivatekey'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will
be incorporated into your certificate request.
...

Všimnite si, že program si vypýtal "PEM pass phrase" - to je heslo, ktoré budeme používať pri vytváraní elektronického podpisu. Jeho bezpečnosť je dôležitým prvkom bezpečnosti celého systému.

Certifikačná autorita by si mala teraz overiť, že požiadavka skutočne patrí osobe, ktorá ju doručila a potom môže vytvoriť samotný certifikát:

openssl ca -in RScertrequest -out RScertificate.pem \
 -policy policy_anything -outdir . -cert CAcertificate \
 -keyfile CAdsaprivtekey -verbose -days 365
Using configuration from /etc/ssl/openssl.cnf
0 entries loaded from the database
...
Certificate is to be certified until Feb 11 21:22:57 2007 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
writing new certificates
writing ./01.pem
Data Base Updated

V tomto príkaze sú použité parametre, ktoré hovoria, že CA použije požiadavku RScertrequest na vytvorenie certifikátu podpísaného certifikačnou autoritou. Tento certifikát bude spôsobilý na všetky úkony (šifrovanie/podpisovanie/...) a bude vytvorený s použitím certifikátu CAcertificate a súkromného kľúča v CAdsaprivtekey a bude platný 365 dní. Súbor RScertificate.pem teda CA vráti žiadateľovi a ten ho môže odteraz používať pre komunikáciu pomocou SSL. Certifikačná autorita si ponecháva jednu kópiu z podpísaného certifikátu v súbore 01.pem. Z overeného certifikátu si môžeme vytiahnuť verejný kľúč, ktorý budeme potrebovať pri overovaní podpisu.

openssl x509 -noout -pubkey -in RScertificate.pem > RSpublickey

       

Komentáře

[Sinuhet]

BTW, uz se doporucuje delat 2048 bitove klice.

[Xerces]

Ahojda, já ten rozdíl stále nechápu Jaká je principiálně výhoda SSL oproti GNUPG? V článku se píše, že tím hlavním rozdílem, je to, že u SSL stačí znát CA aby si oba důvěřovali, ale u GNUPG přesi stačí si osobně vynměnit klíče a je to ještě bezpečnější. A když si mohu zajistit certifikát od CA, tak proč bych si nemohl zajistit GPG klíč od protistrany? Navíc GPG klíč mohu dále podepisovat a distribuovat, takže to funguje tak nějak přirozeně samo. To mě totiž vytáčí, že úřady začínají požadovat certifikáty, za které by bylo nutné platit CA a odmítají si vyměnit klíče osobně. Jaký je problém aby patřičný úřad byl defakto takovou CA?

[Pavel F.]

No protože každý úřad nebude mít lidi, kteří budou mít na starosti výměnu klíčů, ověřování, atd. Je to prostě něco jako outsourcing. Externí CA vydává certifikáty a úřady v dobré víře důvěřují těmto certifikátů, aniž by museli mít vlastní mechanismy pro ověřování pravosti, atd. Je to asi podobná námitka, jako kdybyste prohlásil, že občanské průkazy jsou nesmysl, že by stačilo, kdybyste se každému úřadu prokázal jinak, že se jedná zrovna o Vás. Také úřady v dobré víře důvěřují OP, že je vydala jiná autorita (stát) a nemusí Vás jinak ověřovat (pokud bezpečnostní prvky na OP souhlasí)

[Marian K.]

Přesně tak. Například naše firma vydává podepsaný software, přičemž podpis se dělá pomocí certifikátu od Verisignu. Kdyby si každý uživatel tohoto SW měl napsat k nám o klíč a nejlíp si pro něj dojít osobně (aby měl jistotu, že někde uprostřed není někdo "zašitý"), asi bychom celý den nedělali nic jiného.

[Filip Jirsák]

že občanské průkazy jsou nesmysl, že by stačilo, kdybyste se každému úřadu prokázal jinak, že se jedná zrovna o Vás

Dovede-li se tato představa důsledně do analogie s PGP, musel byste s sebou přivést někoho (A), kdo vás zná. Ten (A) by s sebou přivedl někoho (B), kdo zná jeho (A). (B) by s sebou přivedl někoho... až někonec by byl někdo (X), koho zná úředník Podle 6 stupňu odloučení by vám měli stačit 4 lidi

[Petr Tomášek]

a jak myslite, ze to fungovalo predtim, nez byly obcanske prukazy? )

[GeBu]

To by mě taky hodně zajímalo. Jak to např. bylo ve středověku nebo v Římě, Řecku, Egyptě, Číně.

[Dan Ohnesorg]

Jak to fungovalo v Rime nevim, ale v Anglii nemeli do doby, nez zacali bojovat s terorizmem, zadne obcanske prukazy. Na jedne akci FFII jsme sedeli s anglicany a povidali si o tom, protoze "me to hlava nebrala". Oni zastavali nazor, ze jediny pripad, kdy potrebuji byt identifiovani jsou volby a tam se to resi tak, ze se volebni listky poslou kazdemu domu na adresu a kdyby na ne volil nekdo jiny, tak se na to prijde, protoze prece kdyz oni k tem volbam prijdou, tak zjisti, ze nekdo volil jejich jmenem.

Nicmene oni zalozni identitu maji, jen ne tak viditelnou. Nikdo se s nima nebavi bez platebni karty. Takze chcete elektromer = ukazte platebni kartu, chcete dostat podporu na dite, ukazte kartu a urad na ni posle penize. A ziskani karty funguje na principu znamosti, dite dostava kartu tak, ze s nim zajdou rodice do banky, kde je po mnoho let znaji a reknou, hele to je nase dite. Stejne tak na mistnich uradech, oni se proste vzajemne znaji a vsechno resi na jednom miste, takze maji jednu urednici co je zna na vsechno, od kolibky do hrobu.

Myslim ze pro nas je to ale stejne nepochopitelne. Dokazu si to prestavit na vesnicich, ale v Praze ne.

[GeBu]

To vypadá fakt zajímavě až neuvěřitelně. Zkusím ověřit.

[petr]

to jsou nesmysly ... vsichni meli v anglii do doby obcanek průkaz pojištění a měli sociální čísla s nějako kartou ... takže identifikaci měli ...

[Filip Jirsák]

Zatímco u PGP si musím vyměnit klíč s každou protistranou, u certifikátů SSL si zajistím jednou certifikát CA a pak už vím, že všechny certifikáty vydané touto CA mají ověřené údaje (dle politiky CA). Pokud třeba budu potřebovat komunikovat jen v ČR s certifikáty uznávanými zákonem, stačí mi 3 certifikáty současných CA a nemusím shánět 10 milionů GPG klíčů Druhá výhoda CA je ta, že ručí za certifikát přímo. U GPG víte, že Franta podepsal klíč Pepovi, Frantovi ho podepsala Jitka, Jitce Blanka, a s Blankou jste si klíš vyměnil. Budete všem těm lidem mezi opravdu věřit? Úřad jim samozřejmě věřit nemůže, a nelze se na tento řetězec spolehnout ani v žádném případě, který má mít nějakou právní váhu - všechny ty články řetězu by se totiž stali spoluručiteli, a to předem, aniž by věděli, za co vlastně ručí. Úřad si s vámi nemůže vyměňovat klíče a být "takovou" CA, protože úřad si nemůže dělat, co se mu zlíbí - vynakládat "jen tak" peníze na vytvoření důvěryhodné CA, zaškolovat lidi apod.

[Xerces]

Děkuji, s těma OP jsem to pochopil a máte pravdu, jistá výhoda v tom bude. Pak bych ale měl jedno velké přání, aby stejně jako existuje jeden průkaz totožnosti, existoval jeden certifikát na veškerý kontakt s úřady. Prostě aby stačilo jednou za 10 let dojít pro certifikát a hotovo.

[lovec]

No .. mal by som niekolko nevela (desiatok) pripomienok: - To nie je specifickou vlastnostou SSL, ze prijemca a odosielatel sa nemusia poznat. To je vlastnost PKI. - Co ste napisali: "Ak dostanem správu od používateľa XY a tá správa je podpísaná jeho certifikátom," je upl na haluz .. sprava (presnejsie jej hash) sa podpisuje sukromnym klucom a v certifikate je ulozeny len k nemu zodpovedajuci verejny kluc. - CA nepotrebuju na svoju cinnost "povolenie na cinnost", ale akreditaciu od Narodneho bezpecnostneho uradu. - Garantom el. podpisu (podla ceskeho zanoka digitalneho) v ceskej republike nie je NBU, ale ministerstvo in formatiky. - NBU nevydava "bezpecnostne predpisy pre CA". Hlavnym predpisom CAcky je jej bezpecnostna politika. TU si v ydava sama. NBU moze na CA posobit len bez vyhlasky, alebo (ne)udelenim akreditacie. - CA EVPU nesidli v Dubnici nad Vahom, ale v Novej Dubnici. - Nie je pravda, ze konfiguracny subor "by mal byť spravidla umiestnený v /etc/ssl/openssl.cnf". Napriklad j a ho mam na linuxe v /usr/lib/ssl/openssl.cnf, na solarise bol defaultne ulozeny /usr/local/ssl/openssl.cnf. - paSinuhet: - 2048 bitove kluce sa vytvaraju prevazne pri sifrovani pomocou RSA. Ale velkost zatial nie je az tak kritic ka. Vacsina kvalifikovanych certifikatov je 1024 bitova (vzdy RSA, vyhlaska NBU ine algoritmy nepovoluje).

Xerces: S PGP skusenosti nemam, aj ked s el. podpisom robim uz 2 roky(robim = je to hlavna napln mojej prace). Jedna k na komunikaciu medzi serverom a klientom mozes pouzit len SSL. To je hlavnou naplnou tohto protokolu.

SSL nema vela spolocneho s el. podpisom. Ten sa robi podla standardu PKCS#7 (alebo doplnenie v norme ETSI). I na vec je, ze projekt OpenSSL si dal za jednu z uloh okrem vzniku open-source implementacie SSL protokolu aj podporu vzniku komplexnej kniznice zaoberajucej sa sifrovanim, podpisovanim a vsetkym co s tym suvisi. A teda umoznuje aj vytvarat a overovat aj podpis.Pass phrase nie je "heslo, ktoré budeme používať pri vytváraní elektronického podpisu". Je to o tom, ze privatny kluc je ulozeny v zasifrovanej pomocou symetrickej sifry. Kluc, ktorym je zasifrovany sa ziskal z tohto hesla. - Registracna a nie certifikacna autorita overuje, totoznost osoby, ktora ziada o vydanie certifikatu. - Certifikat sa nevytvara "pomocou CA certifikatu", ale pomocou sukromneho kluca CA. Certifikat CA je dobry len na to, aby v certifikate bolo mozne spravne uviest vydavatela. Tu si uz trosku PKI a PGP zacinaju "liezt" do kapusty. PKI je oficialny standard, pokryty strasnou haldou noriem o formate podpisu, certifikatov, CRL, casovych peciatok a co ja viem coho este. Je zalozeny na tom, ze existuje zopar certifikacnych autorit, ktore (cez nejake registracne autority, ale to nas teraz nezaujima) overia totoznost osoby a vydaju jej certifikat. CAcky nesu zodpovednost (aj hmotnu) za to, ze certifikat vydali komu mali a nie niekomu inemu.

Projekt PGP je ovela volnejsi. Phil Zimmermann ho pojal tak, ze certifikaty nevydava nejaka neohrozena CA, ale kazdy si ho vyda sam. Na to, aby bolo mozne "verit" takto vydanemu certifikatu je vsak potrebne, aby sme ho ziskali z doveryhodneho zdroja. CO znamena, napriklad, ze nam ho da niekto fyzicky.

Ina moznost ako ziskat certifikat je ziskat ho od osoby, ktorej doverujete a jej kluc uz mate. Co je vsak skoro nemozne, ak sa chcete vybavovat s niekym, s kym ste sa este nestretli.

[rastos]

No .. mal by som niekolko nevela (desiatok) pripomienok:

Od toho tu tá diskusia je Nikde netvrdím, že som miestny expert na SSL. Je pravda, že článok je miestami nepresný. Ale cieľom je vysvetliť princípy. A neunudiť pritom čitateľa na smrť.

- To nie je specifickou vlastnostou SSL, ze prijemca a odosielatel sa nemusia poznat. To je vlastnost PKI.

To tiež nie je celkom presné. V článku poukazujem na to, že fyzické overenie toho, že certifikát C patrí osobe O robí certifikačná autorita a nie ten, kto skúma konkrétny elektronický podpis nejakého dokumentu.

- Co ste napisali: "Ak dostanem správu od používateľa XY a tá správa je podpísaná jeho certifikátom," je upl na haluz .. sprava (presnejsie jej hash) sa podpisuje sukromnym klucom a v certifikate je ulozeny len k nemu zodpovedajuci verejny kluc.

Správne.

- CA nepotrebuju na svoju cinnost "povolenie na cinnost", ale akreditaciu od Narodneho bezpecnostneho uradu.

Slovník vraví akreditácia == "úradné oprávnenie vykonávať istú činnosť"

- Garantom el. podpisu (podla ceskeho zanoka digitalneho) v ceskej republike nie je NBU, ale ministerstvo in formatiky.

Dobre vedieť. To som nevedel a o právnom pozadí v ČR som sa vyjadroval v článku dosť opatrne

- NBU nevydava "bezpecnostne predpisy pre CA". Hlavnym predpisom CAcky je jej bezpecnostna politika. TU si v ydava sama. NBU moze na CA posobit len bez vyhlasky, alebo (ne)udelenim akreditacie.

Tak dobre. Ja neprevádzkujem verejnú CA a ten, kto ju chce prevádzkovať musí vedieť viac, ako to čo je v tomto článku. NBÚ SR publikuje na svojich stránkach "metodika auditu SW aplikácií pre ZEP","vzor protokolu o kompilácii", "Schválené formáty" a niekoľko vyhlášok a predpisov popisujúcich najrôznejšie aspekty od technického zabezpečenia budov CA, cez off-site backup-y, disaster recovery a podobne. Ak sa cítiš dostatočne fundovaný, tak o tom napíš článok. Čitatelia budú vďační.

- CA EVPU nesidli v Dubnici nad Vahom, ale v Novej Dubnici.

Pravda je. Vzhľadom na to, že sme na českom serveri a väčšina čitateľov by mala problém nájsť to na mape - dúfam, že mi odpustia.

- Nie je pravda, ze konfiguracny subor "by mal byť spravidla umiestnený v /etc/ssl/openssl.cnf". Napriklad j a ho mam na linuxe v /usr/lib/ssl/openssl.cnf, na solarise bol defaultne ulozeny /usr/local/ssl/openssl.cnf.

Ok. Podla zdrojákov, je default /usr/local/ssl - ale do hry vstupuje LSB, ktoré hovorí, že system-wide konfigurácia má byť pod /etc.

Xerces: S PGP skusenosti nemam, aj ked s el. podpisom robim uz 2 roky(robim = je to hlavna napln mojej prace). Jedna k na komunikaciu medzi serverom a klientom mozes pouzit len SSL. To je hlavnou naplnou tohto protokolu.

To bude vysvetľovať, prečo mám pocit, že Ťa ten článok zdvihol zo stoličky.

Pass phrase nie je "heslo, ktoré budeme používať pri vytváraní elektronického podpisu". Je to o tom, ze privatny kluc je ulozeny v zasifrovanej pomocou symetrickej sifry. Kluc, ktorym je zasifrovany sa ziskal z tohto hesla.

Správne. Uff. Je piatok vecer a ja mam dost. Bol by si ochotný urobiť reviziu druheho dielu članku?

[Robert Kupka]

- CA EVPU nesidli v Dubnici nad Vahom, ale v Novej Dubnici.

Pravda je. Vzhľadom na to, že sme na českom serveri a väčšina čitateľov by mala problém nájsť to na mape - dúfam, že mi odpustia.

Nie, my Novodubničania ti neodpustíme :) A Novú Dubnicu vôbec nie je ťažké na mape nájsť. Nájdeš ju aj na Google Earth.

Ak sa cítiš dostatočne fundovaný, tak o tom napíš článok.

Ty ho píšeš a vzhladom na množstvo nepresností, na ktoré ťa lovec upozornil, by si na svojej fundovanosti mal poriadne zapracovať.

Inak, dobrá téma.

[Vlastimil Ott]

Opraveno na "v Novej Dubnici", díky.

[Kumar]

Diky obema :) mam rad diskuzi dvou lidi kteri VI ze neco vi :) TOHLE je diskuze a ne blaboly o nesmyslnostech BRAVO :)))

[zorokuncak]

prosim vas, kdo je certifikacni autorita pro el. podpisy v CR? diki

[Karlik]

Dobry den, snazim se pochopit certifikaty a digitalni podpisy. Chtel bych totiz sve ucetni nechat vystavit digitalni podpis od CA PostSignum Ceske posty, aby mohla posilat oficialni maily na urady. Jsem z toho ale zmatenej a proto procitam vsechny navody, abych pochopil, jak to vlastne vsechno funguje. Nejde mi o to, abych do toho videl na 100 procent, ale spis nevim, na co ji mam upozornit, aby si hlidala jako oko v hlave atd. Vim, hlidejte si soukromy klic (ctu vsude), ale rarazi me uz jen import do mailovych klientu. Bojim se, aby se ji soukromej klic nevalel, kde nema a mela o nem absolutni prehled. Proto jsem si procital napriklad tento clanek X krat, i jsem si klice vygeneroval a vse funguje bez problemu. Muzete mi ale prosim rici (kdyz pominu me dotazy ohledne funkcnosti celeho mechanizmu overovani) co jsou tyto sobory:

RSpublickey (logicky z nazvu - verejny klic) musi ho mit i prijemce,ze? RSprivatekey (logicky z nazvu je to prave to oko v hlave - privatni klic) RScertificate.pem (co je ale toto? To je snad privatni klic vcetne verejneho klice? Tomu prave nejak nerozumim).

A soubor p12 je nejaky balik privatniho a verejneho klice, co akceptuji mailovy klienti?

Snad pochopite o co mi jde a pripadne mi poradite. Budu Vam moc vdecny. Karlik