7,540
edits
Changes
Created page with "=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, vagyi..."
=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.
==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=
==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.
<pre>
# 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
</pre>
==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:
<pre>
# mkdir /root/SSL
# cd /root/SSL
</pre>
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.
2.2.a admin.berki.org
I 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 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.
II 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 -key admin.berki2.org-server.key -out admin.berki2.org-server.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
III 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 -req -in admin.berki2.org-server.req -CA berki-ca.pem -CAkey berki-ca.key -set_serial 100 -days 3650 -outform PEM -out admin.berki2.org-server.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
2.2.b 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.
2.3 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.
2.3.a Kliens kulcsok legyártása
I 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.
II 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
III 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
2.3.b 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
3 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
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.
==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=
==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.
<pre>
# 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
</pre>
==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:
<pre>
# mkdir /root/SSL
# cd /root/SSL
</pre>
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.
2.2.a admin.berki.org
I 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 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.
II 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 -key admin.berki2.org-server.key -out admin.berki2.org-server.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
III 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 -req -in admin.berki2.org-server.req -CA berki-ca.pem -CAkey berki-ca.key -set_serial 100 -days 3650 -outform PEM -out admin.berki2.org-server.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
2.2.b 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.
2.3 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.
2.3.a Kliens kulcsok legyártása
I 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.
II 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
III 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
2.3.b 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
3 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
