Difference between revisions of "Apache - SSL"
(→Kulcsok legyártása) |
(→Tanúsítvány igénylő készítése) |
||
| Line 150: | Line 150: | ||
A challenge password []: | A challenge password []: | ||
An optional company name []: | An optional company name []: | ||
| + | </pre> | ||
Ezzel előállt a domain-hez tartozó tanúsítvány igénylő, amit alá kell iratni a CA-val: | Ezzel előállt a domain-hez tartozó tanúsítvány igénylő, amit alá kell iratni a CA-val: | ||
| + | <pre> | ||
admin.berki2.org-server.req | admin.berki2.org-server.req | ||
</pre> | </pre> | ||
{{note|Itt is fontos a '''-sha256''' kapcsoló használata, hogy sha-2 tanúsítványt kapjuk majd. }} | {{note|Itt is fontos a '''-sha256''' kapcsoló használata, hogy sha-2 tanúsítványt kapjuk majd. }} | ||
| − | |||
===Tanúsítvány igénylő aláírása=== | ===Tanúsítvány igénylő aláírása=== | ||
Revision as of 11:36, 12 December 2017
Contents
Hogyan működik
Az SSL-el védett weboldalak esetén két célunk van. Az első, és legfontosabb, hogy titkosított csatornán kommunikáljon a szerver a klienssel, vagyis, hogy senki, semmilyen módon ne tudja lehallgatni a kommunikációt. A második célunk, hogy a kliens böngésző egyértelműen meg tudjon róla győződni, hogy a cél szerverrel kommunikál, és nem egy harmadik féllel.
Titkosított csatorna felépítése
Az SSL kapcsolat felépítésekor a szerver és a kliens felépít egy titkosított csatornát, amibe akkor sem lehet belehallgatni, ha valaki kezdettektől fogva lehallgatja a kapcsolatot. A kapcsolat felépítésére aszimmetrikus kulcsú titkosítást használ az SSL. A kapcsolat felépítése közben a kliens és a szerver megállapodnak egy olyan szimmetrikus kulcsban, amit csak ők ketten tudnak. A tényleges kommunikációt már ezzel a szimmetrikus kulccsal titkosítják. A titkos kapcsolat felépítése nagyon leegyszerűsítve a következő:
1. A kliens küld egy kérést a szervernek, hogy SSL-el kapcsolódni akar hozzá. 2. A szervernek van egy titkos és egy publikus kulcsa párja. Amit a publikus kulccsal valaki titkosít, azt csak a titkos kulccsal elehet dekódolni. A szerver visszaküldi a kliensnek a publikus kulcsát, valamint a titkosítási paramétereket, megállapodásokat. Természetesen ezt bárki láthatja aki hallgatózik a vonalon, de nem baj, nem tud vele semmit kezdeni. 3. A kliens generál egy szimmetrikus kulcsot, amit titkosít a szerver publikus kulcsával. Ezt visszaküldi a szervernek. A szimmetrikus kulcsot kizárólag a szerver tudja kiolvasni, mivel csak nála van meg az aszimmetrikus titkos kulcs. A szerver kititkosítja az üzenetet, kiolvassa belőle a szimmetrikus kulcsot. 4. A kliens és a szerver innentől kezdve a kliens által kitalált szimmetrikus kulcsot fogják használni az üzenetek titkosítására. Vagyis az aszimmetrikus szerver kulcsok csak arra kellenek, hogy a kliens eljuttassa a közös szimmetrikus kulcsot a szervernek, anélkül, hogy bárki erről tudomást szerezhetni.
A valóságban a kliens nem a végleges szimmetrikus kulcsot küldi el a szervernek, hanem egy paraméter halmazt, ami alapján a szerver és a kliens is létre tudja hozni ugyan azt a kulcsot. Miután a kliens és a szerver is létrehozták a kulcsot, küldenek egymásnak egy nyugtázó üzenetet az új titkosított kulccsal titkosítva, amivel jelzik egymásnak, hogy a titkos csatorna előállt.
file:///home/adam/tmp/img1.png
A szerver és kliens azonosítása
Azt kell látni, hogy a kliens vagy a szerver azonosítása csak azon alapszik, hogy a kliensnél, a szervernél és az úgynevezett Hitelesítési szolgáltatónál olyan információ van, ami csak neki lehet meg. Amikor a szerver, a kliens vagy a Hitelesítési szolgáltató ezt „bebizonyítja”, onnantól megbízunk a másik félben. Klimesként a szerverben, vagy szerverként a kliensben, ha kliens oldali azonosítás is történik.
Szerver azonosítása
Nagyon fontos, hogy a kliens meg tudjon arról győződni, hogy a szerver által visszaküldött publikus kulcsot tényleg a cél szerver küldte, és nem egy közbeékelődött támadó (men-in-the-middle). A szerver ezért nem csak a publikus kulcsát küldi el a kliensnek, hanem egy borítékot, amiben benne van a publikus kulcsa is, és a boríték alá van írva. Ezt a borítékot hívják tanúsítványnak. A tanúsítvány tanúsítja a kliens számára, hogy a tanúsítványban lévő kulcs tényleg a szerveré. A tanúsítványt úgynevezett Hitelesítési szolgáltatók (Certificate Authority, CA) bocsájtják ki. A szerver a következő képen juthat tanúsítványhoz (offline folyamat). Elsőként generál magának egy titkos kulcsot. A titkos kulcsból generál egy úgynevezett tanúsítvány igénylőt. Ebbe belegenerálja magának a titkos kulcshoz tartozó publikus kulcsát, valamit további információkat a szerverről (földrajzi hely, vállalat neve..). A legfontosabb információ a tanúsítvány igénylőben a teljes domain neve a szervernek, amit védeni akar. A tanúsítvány igénylőt a rendszergazda elküldi egy CA-nak, aki az igénylőből elkészíti a szerver tanúsítványát, amiben benne van a szerver publikus kulcsa, információk a szerverről, a tanúsítványhoz tartozó domain név, a tanúsítvány kibocsájtója, valamint a CA digitális aláírása. A CA által elkészített tanúsítványt és a szerver titkos kulcsát kell beállítani a szervernek. A CA is rendelkezik egy titkos és egy publikus kulccsal, csak pont fordítva használja őket mint a szerver. Ugyanis a tanúsítvány igénylőt a titkos kulccsal írja alá. A kliensek pedig a CA publikus kulcsával tudják ellenőrizni a digitális aláírást. A digitális aláírás egyértelműen bizonyítja, hogy a tanúsítvány tartalma nem volt módosítva, valamit, hogy az aláírást tényleg a CA készítette. A CA digitális aláírásának ellenőrzéséhez a kliens böngészőnek szüksége van a CA publikus kulcsára. A kliens böngészőjébe gyárilag benne vannak a hitelesítő szolgáltatók publikus kulcsai. Azokat a tanúsítványokat fogadja el a böngésző amikhez van publikus kulcsa az aláírás ellenőrzéséhez.
Saját aláírás használata
Ha az SSL-el védett oldal belső használatra való, akkor felesleges publikus tanúsítványt csináltatni. Készítünk saját használatra egy Hitelesítési szolgáltató titkos és publikus kulcsot. A CA titkos kulccsal aláírjuk a saját tanúsítvány igénylőnket. A Hitelesítési szolgáltatónk publikus kulcsát pedig importálni kell a felhasználók böngészőjébe, mint biztonságos Hitelesítési szolgáltató. Ekkor a böngésző el fogja fogadni a szerver által küldött tanúsítványt, mivel azt hitelesnek fogja gondolni az importált kulcs miatt.
Kliens azonosítása
Különösen védett tartalom esetében szükség lehet rá, hogy a szerver is azonosítani tudja a klienst. Ehhez a kliensnek is szükség van egy saját tanúsítványra. Ekkor a szervernek is be kell állítani egy Hitelesítési szolgáltatót, aki aláírta a kliens tanúsítványát. A szervernek pedig szükség van a Hitelesítési szolgáltató publikus kulcsára, aki aláírta a kliens tanúsítványát, amivel ellenőrizni tudja a tanúsítványt kapcsolódáskor. Ehhez minden képen szükséges hogy létrehozzunk egy saját Hitelesítési szolgáltatót. Ez lehet ugyan az, amit a saját szerver tanúsítványok legyártására használunk. Készítünk ebben az esetben is egy titkos kulcsot a kliensnek, majd abból egy tanúsítvány igénylőt, amit aláíratunk a saját Hitelesítési szolgáltatónkkal, amiből előáll a kliens tanúsítványa. A hitelesítési szolgáltató publikus kulcsát beállítjuk a szerverbe, hogy azzal ellenőrizze a hozzá beérkező kliens tanúsítványokat. A kliens titkos kulcsát és a tanúsítványt pedig össze kell csomagolni egy pkcs12 formátumba, hogy importálni lehessen a böngészőbe a saját kulcsok közé. A böngésző a szerver kérésére el fogja küldeni a beállított kliens tanúsítványt. A kliens és a szerver ekkor visszafelé is le tudja zongorázni a titkosított csatorna felépítését. Ekkor a szerver is visszaküld egy a kliens publikus kulcsával titkosított információt. Ha nem saját hitelesítési szolgáltatóval készítenénk el a kliens tanúsítványát, hanem egy mindenki számára elérhető szolgáltatóval, akkor bárki készíttethetne magának olyan tanúsítványt, amit a szerver elfogadna.
Hogyan támadnak
Ahogy azt már láttuk, a titkosított csatornát feltörni semmilyenek módon nem lehet. A támadó viszont ha beékelődik a kliens és a szerver közé, akkor felépíthet egy SSL kapcsolatot a szerverrel, eljátszva hogy ő a kliens, és egy SSL kapcsolatot a klienssel, mintha ő lenne a szerver. Ilyen esetben a böngésző figyelmeztetni fogja a felhasználót, hogy a tanúsítvány nem megfelelő, mivel valójában nem a szerverrel beszélget a kliens. A másik lehetőség, hogy a beékelődött felhasználó kiépíti az SSL kapcsolatot a szerverrel, de a felhasználó számára HTTP-n továbbítja a tartalmat. Ez csak akkor lehetséges, ha a felhasználó nem közvetlenül egy https-es linket ír be a böngészőbe, vagy nyit meg könyvjelzőből, hanem http oldalon kattint egy linkre, vagy a szerver http-ről https-re irányít át. Ha a felhasználó nem veszi észre, hogy HTTP-n kommunikál a böngésző, akkor kész a baj. Tehát a felhasználókat meg kell tanítani, hogy mindig ellenőrizzek, hogy https fölött vannak e, és ha a böngésző ssl hibát jelez, akkor nem szabad tovább menni.
Kulcsok legyártása
Warning
Most már a böngészők nem fogadják el az SHA-1-es tanúsítványokat, ezért nagyon fontos, hogy az összes kulcs és aláírás igénylő SHA-2-öt használjon. Ehhez az összes generálásba el kell helyezni a -sha256 kapcsolót.
SHA-1-es aláírás (Chrome 53)
SHA-2-es aláírás:
Saját Hitelesítési szolgáltató elkészítése
Elsőként létre fogunk hozni egy Hitelesítés szolgáltatót (CA). Ehhez le kell generálnunk a CA publikus és titkos kulcsát. A tanúsítványokat a titkos kulccsal fogjuk előállítani, míg a publikus kulcsot el kell juttatni a felhasználóink böngészőibe, mint megbízható hitelesítési szolgáltató, hogy a böngésző elfogadja a szerver tanúsítványát. Ezen felül a szerverbe szintnét be kell állítani a CA publikus kulcsát mint hitelesítési szolgáltató, hogy elfogadja a kliens tanúsítványát.
A titkos kulcs neve berki-ca.key, míg a publikus kulcs neve berki-ca.pem. Ezen felül adjuk meg, hogy a kulcs 3650 napig (10 évig) legyen érvényes. Generálás közben válaszolunk kell pár kérdésre. Ezek közül semelyiknek sincs nagy jelentősége. Kiemeltem amiket meg kell adni. Az itt megadott értékek látszódni fognak a böngészőben importált CA adataiként.
# openssl req -new -x509 -sha256 -days 3650 -nodes -out berki-ca.pem -keyout berki-ca.key Generating a 2048 bit RSA private key .................................................................+++ ...........+++ writing new private key to 'berki-ca.key' ----- 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) [XX]:HU State or Province Name (full name) []: Locality Name (eg, city) [Default City]:Budapest Organization Name (eg, company) [Default Company Ltd]:Berki Corpoation Organizational Unit Name (eg, section) []: Berki-CA Division Common Name (eg, your name or your server's hostname) []: ca.berki2.org Email Address []:info@berki2.org Ezzel létrejött a Hitelesítési Szolgáltató titkos és publikus kulcsa: berki-ca.key berki-ca.pem
Note
Láthatjuk, hogy hitelesítési szoláltató is SHA-2 -t használ.
Szerver kulcsok előállítása
Minden egyes domain-hez készíteni kell egy aszimmetrikus kulcs párt. Nem elég csak a fő domain-re létrehozni egy kulcsot, hogy azt használja az összes al domain, ugyanis a tanúsítványnak tartalmaznia kell a teljes domain nevet. A CA többek közözött azt bizonyítja az aláírásával, hogy a tanúsítvány valóban azt a domain-t védi, akivel a kliens beszélget. Első lépésként készíteni kell egy titkos kulcsot a teljes domain névre. Publikus kulcsot nem kell külön készíteni, a tanúsítvány igénylő generálásával előáll a publikus kulcs is. A tanúsítvány igénylőbe belekerül a szerver publikus kulcsa, valamint a szerver teljes domain neve. Ezt kell majd aláíratni a CA-val, hogy előálljon belőle a szerver tanúsítványa, amit majd el tud küldeni a kliensnek a szerver, ha SSL kapcsolatot akar vele kiépíteni. A titkos kulcsot sosem küldjük el a CA-nak. A CA csak a publikus kulcsot is tartalmazó tanúsítványt igénylőt kapja meg. Hozzunk létre egy mappát a root alatt, és ott hozzuk létre az összes kulcsot, majd a végén a helyükre másolhatjuk:
# mkdir /root/SSL # cd /root/SSL
A kulcsokat az openssl eszközzel fogjuk generálni. Nem ez az egyetlen módja a kulcsok generálásának, nagyon sok egyéb megoldás is létezik.
Titkos kulcs készítése
Elsőként előállítjuk a szerver 2048 bites titkos RSA kulcsát. Erre nagyon kell vigyázni, ez nem kerülhet rossz kezekbe. A kulcsot nevezzük el a domain név alapján, amihez a kulcs tartozni fog:
# openssl genrsa -out admin.berki2.org-server.key 2048 Generating RSA private key, 2048 bit long modulus ..................................+++ ...............................+++ e is 65537 (0x10001)
Ezzel előállt a szerver titkos kulcs: admin.berki2.org-server.key
A kulcsot nem titkosítottuk, és nem is adtunk hozzá passphrase-t. Ha belenézünk a fájlba,láthatjuk, hogy nincs titkosítva:
-----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAyZ4ZNz7TbN5p088mRv/JiogOmmS9m8R4gDD7112ayqVCGUzP ..... QG/XDR6Q/yNoeMbVI6rt5DPYvlyg1KfnnvGHuvnhkbA7Nfc1M+x73A== -----END RSA PRIVATE KEY-----
Lehetséges lenne titkosítani a titkos kulcs fájl tartalmát, de akkor minden olyan alkalmazásba, ami használja majd a titkos kulcsot, induláskor be kéne kézzel írni a jelszót, ami a szervernél nem megoldható, ezért plain text-ként fogjuk tárolni a titkos kulcsot is.
Tanúsítvány igénylő készítése
Készítünk egy tanúsítvány igénylőt a titkos kulcs alapján. A tanúsítvány igénylő generálása automatikusan elhelyezi a publikus kulcsot is a tanúsítvány igénylőbe, külön tehát nem kell publikus kulcsot generálni. A tanúsítvány igénylő generálás közben meg kell adni a leendő tanúsítványunk alap adatait. Ezek közül a legfontosabb a Common Name-ben megadott érték, ami a szerver teljes domain neve kell legyen, amihez a kulcs tartozni fog. Amennyiben ez eltér a tényleges domain névtől, a böngésző akkor sem fogja elfogadni a tanúsítványt, ha ismeri a tanúsítványt aláíró CA-t. A „ A challenge password” mezőnek semmi jelentősége. Egyes CA-k megkövetelhetik, hogy egy jelszót is küldünk át a tanúsítvány igénylőben, mely a jövőbeli azonosításunkat tenné lehetővé. Jelen esetben semmi jelentősége nem lesz, a tanúsítvány előállításában nem játszik szerepet.
# openssl req -new -sha256 -key admin.berki2.org-server.key -out admin.berki2.org-server.sha2.req 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) [XX]:HU State or Province Name (full name) []: Locality Name (eg, city) [Default City]:Budapest Organization Name (eg, company) [Default Company Ltd]:Berki Ugyvedi Iroda Organizational Unit Name (eg, section) []: BUI Common Name (eg, your name or your server's hostname) []:admin.berki2.org Email Address []:info@berki2.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Ezzel előállt a domain-hez tartozó tanúsítvány igénylő, amit alá kell iratni a CA-val:
admin.berki2.org-server.req
Note
Itt is fontos a -sha256 kapcsoló használata, hogy sha-2 tanúsítványt kapjuk majd.
Tanúsítvány igénylő aláírása
A tanúsítvány igénylőben benne van a szerver publikus kulcsa, és a teljes domain neve. A CA tanúsítja, hogy a domain név valóban a mi tulajdonunkban van, és hogy a domain név összetartozik a publikus kulccsal. Ehhez a CA a tanúsítvány igénylőben megkapott tanúsítvány adatokat, a domain publikus kulcsát, valamint CA publikus kulcsát beleteszi egy borítékba, amit aláír a titkos kulcsával. Így áll elő a domain tanúsítványa. Nagyon fontos, hogy adjunk egy egyedi sorszámot a tanúsítványnak a set_serial paraméterrel. Nem lehet két azonos sorszámú tanúsítványa egy CA-nak. Ha több tanúsítványunknak is ugyan azt a sorszámot adjuk, akkor a böngésző egyiket sem fogja elfogadni.
A tanúsítvány legyártásház meg kell adni a CA titkos és publikus kulcsát is, valamint a szerver tanúsítvány igénylőjét:
# openssl x509 -sha256 -req -in admin.berki2.org-server.sha2.req -CA berki-ca.pem -CAkey berki-ca.key -set_serial 100 -days 3650 -outform PEM -out admin.berki2.org-server.sha2.cer Signature ok subject=/C=HU/L=Budapest/O=Berki Ugyvedi Iroda/CN=admin.berki2.org/emailAddress=info@berki2.org Getting CA Private Key Ezzel előáll a szerver tanúsítványa: admin.berki2.org-server.cer
Note
Ha itt nem használtuk volna a -sha256 kapcsolót, akkor az SHA-2-es igénylő ellenére egy SHA-1-es tanúsítványt kaptunk volna.
Kinél milyen kulcs van
Kulcs neve Hol van Funkció admin.berki2.org-server.key szerver A szerver ezzel titkosítja ki a kliens által küldött szimmetrikus kulcsot, amit a session alatt használni fognak. admin.berki2.org-server.cer szerver A szerver tanúsítványa, mai tartalmazza a szerver publikus kulcsát, amivel a kliens titkosítja az általa kitalált szimmetrikus kulcsot, valamint a CA aláírását, ami alapján meggyőződhet a kliens, hogy a publikus kulcs tényleg a szerveré. berki-ca.pem Kliens böngészőjében A Hitelesítés szolgáltató publikus kulcsa. Ezt a kliens böngészőjébe kell elhelyezni, a megbízható Hitelesítés szolgáltatók listájába. Ezzel a kulccsal tud meggyőződni a böngésző arról a szerver által küldött tanúsítvány hiteles.
Kliens kulcsok
A kliens számára is készíthetünk tanúsítványt. Az apache-ba beállíthatjuk, hogy csak olyan klienssel építhet ki kapcsolatot, aki fel tud mutatni egy olyan tanúsítványt, amit az a hitelesítési szolgáltató írt alá, ami be van állítva a szerveren. A kliens tanúsítványát kiállító CA természetesen lehet ugyan az, amivel a szerver kulcsait aláírtuk. Első lépésként a kliens számára is generálni kell egy titkos kulcsot, majd abból egy tanúsítvány igénylőt, amivel a kliens publikus kulcsa is előáll. A kliens tanúsítvány igénylőjében nem számít, hogy milyen domain nevet adunk meg a Common name mezőben. A CA által előállított kliens tanúsítványt és a kliens titkos kulcsát be kell rakjuk a kliens böngészőjébe a saját tanúsítványok köz. Ehhez a CA által előállított tanúsítványt és a kliens titkos kulcsát össze kell majd csomagoljuk pkcs12 formátumba, mert a böngészők csak így fogadják el. A szerver kulcsával ellentétben nem kell domain-enként egy kliens kulcsot generálni. A szerver nem fogja ellenőrizni, hogy a kliens olyan domain-hez akar e csatlakozni, ami a Common name mezőben meg van adva.
Kliens kulcsok legyártása
A kliens titkos kulcsa
Első lépésként készítsük el a kliens 2048 bites titkos kulcsát. (Az RSA az alapértelmezett)
# openssl genrsa -out berki-client.key 2048 enerating RSA private key, 2048 bit long modulus ..........+++ ...............+++ e is 65537 (0x10001)
Ezzel előáll a kliens titkos kulcsa: berki-client.key
Itt sem használtunk passphrase-t, akárcsak a szerver titkos kulcsa, ez is plain text. Azonban a kliens titkos kulcsát nem fogjuk odaadni a klienseknek, hanem a tanúsítvánnyal együtt össze fogjuk csomagolni egy pkcs12 fájlba, amit viszont már jelszóval fogunk védeni.
Kliens tanúsítvány igénylője
A titkos kulcs segítségével generáljuk le tanúsítvány igénylőt. A tanúsítványban szereplő adatoknak a kliens esetében nincs semmi jelentősége, pusztán a tanúsítvány beazonosítását segítik. Akárcsak a szerver tanúsítvány igénylőjének az esetében, itt sincs funkciója a „A challenge password” mezőnek. Értéke irreleváns.
# openssl req -new -key berki-client.key -out berki-client.req 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) [XX]:HU State or Province Name (full name) []: Locality Name (eg, city) [Default City]:Budapest Organization Name (eg, company) [Default Company Ltd]:Berki Ugyvedi Iroda Organizational Unit Name (eg, section) []: BUI Common Name (eg, your name or your server's hostname) []:berki2.org Email Address []:info@berki.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Ezzel előállt a kliens tanúsítvány igénylője: berki-client.req
Tanúsítvány előállítása
Most a CA-val aláíratjuk a kliens tanúsítvány igénylőjét, amiből előáll a kliens tanúsítványa. Nagyon fontos, hogy egyedi sorszámot adjunk a tanúsítványnak. Mivel a szerver által küldött tanúsítvány, és a kliens tanúsítványa egyszerre lesz jelen a böngészőben, és a CA közös, ezért a böngésző nem fogja elfogadni egyik tanúsítványt sem, ha azonos a sorszámuk.
# openssl x509 -req -in berki-client.req -CA berki-ca.pem -CAkey berki-ca.key -set_serial 101 -days 3650 -outform PEM -out berki-client.cer Signature ok subject=/C=HU/L=Budapest/O=Berki Ugyvedi Iroda/CN=berki2.org/emailAddress=info@berki.org Getting CA Private Key Ezzel előállt a kliens tanúsítványa: berki-client.cer Utolsó lépésként a kliens titkos kulcsát és tanúsítványát összecsomagoljuk pkcs12 formátumba, amit majd importálni tudunk a böngészőbe. Itt mindenképpen adjunk meg jelszót. Ezt a jelszót fogja elkérni a böngésző a tanúsítvány importálásakor, ezzel védhetjük meg a tanúsítványunkat, és az abban lévő titkos kulcsot, hogy ne tudják illetéktelenek felhasználni. # openssl pkcs12 -export -inkey berki-client.key -in berki-client.cer -out berki-client.p12 Enter Export Password: ******* Verifying - Enter Export Password: *******
Ezzel előállt a kliens böngészőbe importálható tanúsítványa: berki-client.p12
Kinél milyen kulcs van
Kulcs neve Hol van Funkció berki-client.p12 Kliens böngészőjében A szerver böngészőjébe importált saját tanúsítvány, amiben össze van csomagolva a kliens titkos kulcsa, és a kliens CA által kibocsájtott tanúsítványa. A kapcsolat felépítésekor ezt a tanúsítványt küldi el a szervernek. berki-ca.pem Szerver A Hitelesítés szolgáltató publikus kulcsa. Ezt a szervernek kell megadni, mint megbízható Hitelesítés szolgáltató. Ezzel a kulccsal tud meggyőződni a szerver arról a kliens által küldött tanúsítvány hiteles, vagyis, hogy a klines az akinek mondaj magát.
Fontos, hogy a szerver órája jól járjon. Ha késik, akkor lehet hogy nem fogja elfogadni a kliens tanúsítványát, mondván, hogy még nem valid:
[client 192.168.10.104] Certificate Verification: Error (9): certificate is not yet valid
Importálás a böngészőbe
Ahhoz hogy a böngészőnk elfogadja az összes tanúsítványt, amit a saját CA-nkal aláírtunk, a saját CA-nk publikus kulcsát (berki-ca.pem) importálni kell a böngészőbe a megbízható Hitelesítés szolgáltatók közé. Firefox: - Preferences -> Advanced -> Certificates fül -> View Certificates gomb -> Authorities fül -> Import... gomb.
Ha a saját CA-nkat felvettük a megbízható szolgáltatók közé, akkor a böngészőnk az összes tanúsítványunkat el fogja fogadni, a kis lakat zöldre fog változni.
Ahhoz, hogy a szerver felé a böngésző autentikálni tudja magát, a saját titkos kulcsunkból és a saját tanúsítványunkból összecsomagolt pkcs12 fájlt importálni kell szintén a böngészőbe a saját tanúsítványaink közé (berki-client.p12). Firefox: - Preferences -> Advanced -> Certificates fül -> View Certificates gomb -> Your Certificates fül -> Import...
4 Apache SSL yum install mod_ssl openssl
<VirtualHost *:443>
....
########################## # SSL beállítások ##########################
# SSL parameterek ########################## SSLEngine on
# Here, I am allowing only "high" and "medium" security key lengths. SSLCipherSuite HIGH:MEDIUM
# Here I am allowing SSLv3 and TLSv1, I am NOT allowing the old SSLv2. SSLProtocol all -SSLv2
# Kliens autentikaco ########################## SSLVerifyClient require SSLVerifyDepth 1
# Certificate Authority (CA): SSLCACertificateFile /etc/httpd/conf/ssl/berki-ca.pem
# Server Certificate Chain: SSLCertificateChainFile /etc/httpd/conf/ssl/berki-ca.pem
# Szerver kulcsok ##########################
# Server Certificate: SSLCertificateFile /etc/httpd/conf/ssl/admin.berki2.org-server.cer
# Server Private Key: SSLCertificateKeyFile /etc/httpd/conf/ssl/admin-berki2.org-server.key
....
</VirtualHost>
5 Java keystore
