7,540
edits
Changes
→Apache beállítások
A titkos kapcsolat felépítése nagyon leegyszerűsítve a következő:
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:ClipCapIt-170311-225559.PNG]]
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===
:[[File:ClipCapIt-170311-225655.PNG|right]]
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.
=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)
:[[File:ClipCapIt-170311-230151.PNG]]
SHA-2-es aláírás:
:[[File:ClipCapIt-170311-230344.PNG]]
==Saját Hitelesítési szolgáltató elkészítése==
berki-ca.pem
</pre>
{{note|Láthatjuk, hogy hitelesítési szoláltató is SHA-2 -t használ.}}
==Szerver kulcsok előállítása==
# 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.
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:
<pre>
# openssl genrsa -out admin.berki2.org-server.key 2048
...............................+++
e is 65537 (0x10001)
</pre>
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:
<pre>
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAyZ4ZNz7TbN5p088mRv/JiogOmmS9m8R4gDD7112ayqVCGUzP
QG/XDR6Q/yNoeMbVI6rt5DPYvlyg1KfnnvGHuvnhkbA7Nfc1M+x73A==
-----END RSA PRIVATE KEY-----
</pre>
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.
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.
<pre># 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
A challenge password []:
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:
<pre>
admin.berki2.org-server.req
</pre>
{{tip|Itt is fontos a '''-sha256''' kapcsoló használata, hogy sha-2 tanúsítványt kapjuk majd. }}
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.
{{note|A tanúsítványokhoz több kiegészítés (exctension) is létezik, melyek extra információkat engednek hozzáadni a tanúsítványhoz. A '''Google Chrome''' az 58-as verziótól kezdve csak olyan tanúsítványt fogad el amiben a '''"X509v3 Subject Alternative Name"''' kiegészítés tartalmazza a szerver domain nevét. Ha a tanúsítvány igénylőt valódi szolgáltató írja alá, akkor ő ezt bele fogja tenni. Ha magunknak írjuk alá, akkor fontos, hogy ezt megadjuk. }} 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. Az -extfile kapcsolóval adhatjuk meg a X509V3 kiegészítéseket tartalmazó fájl nevét. Itt fogjuk megadni a SubjectAlternativeName értékét. Itt vagy IP címet, vagy a DN: előtag után a domain nevet kell megadni. <pre># openssl x509 -sha256 -req -extfile <(printf "subjectAltName=DNS:admin.berki2.org") -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
</pre>
Ezzel előáll a szerver tanúsítványa:
<pre>
admin.berki2.org-server.cer
</pre>
{{tip|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===
{| class="wikitable sortable"
|-
! 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/szerverben || 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.
|}
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.
Első lépésként készítsük el a kliens 2048 bites titkos kulcsát. (Az RSA az alapértelmezett)
<pre>
# openssl genrsa -out berki-client.key 2048
enerating RSA private key, 2048 bit long modulus
...............+++
e is 65537 (0x10001)
</pre>
Ezzel előáll a kliens titkos kulcsa: berki-client.key
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.
<pre>
# openssl req -new -key berki-client.key -out berki-client.req
A challenge password []:
An optional company name []:
</pre>
Ezzel előállt a kliens tanúsítvány igénylője: berki-client.req
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.
<pre>
# 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
Enter Export Password: *******
Verifying - Enter Export Password: *******
</pre>
Ezzel előállt a kliens böngészőbe importálható tanúsítványa: berki-client.p12
Kulcs neve
Hol van
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:
<pre>
[client 192.168.10.104] Certificate Verification: Error (9): certificate is not yet valid
</pre>
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:
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:
Fel kell telepíteni az ssl modult az apache-hoz valamit az openssl programot, ha eddig ezt nem tettük volna meg.
# dnf install mod_ssl openssl
== Virtual ssl host elkészítése ==
<pre>
<VirtualHost *:443>
....
....
</VirtualHost>
</pre>
Ha valódi SSL szolgáltatót használunk, akkor gyakran meg kell adni egy tényleges ...
<br>
=NO-ip cert generálás=
Még mielőtt bármit is generálnánk, venni kell egy 1 éves cert-et a NOip oldalán. Amt még bármiféle generálás előtt ki kell fizetni.
:[[File:ClipCapIt-210829-215730.PNG]]
Most generálni kell egy '''Certificate Signing Request''' fájlt, amit majd fel kell tölteni a No-ip-re. Ehhez kel a szerver titkos kulcsa, semmi más:
<pre>
$ openssl req -new -sha256 -key wiki.berki.org-server.key -out wiki.berki.org-server-20210829.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) []:Pest
Locality Name (eg, city) [Default City]:Budapest
Organization Name (eg, company) [Default Company Ltd]:Berki corp
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:wiki.berki.org
Email Address []:info@berki.org
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
</pre>
A leges legfontosabb a '''Common Name''' mező, itt kell megadni a szerver teljes domain nevét.
<br>
Most előállt a '''wiki.berki.org-server-20210829.req''' fájl. Menjünk fel a no-ip felületére az '''SSL Certificates''' oldalra, ahol már vár ránk a félig megrendelt cert.
https://www.noip.com/support/knowledgebase/get-trustcor-premium-dv-ssl/
Itt kattintsunk az ADD csr gombra
:[[File:ClipCapIt-210829-220214.PNG]]
A megnyíló popup-ban másoljuk be a request teljes tartalmát, és a szerver típusa legyen: Apaceh mod ssl.
Ezen a ponton még nem fogja legenerálni a cert-t, most bizonyítani kell hogy tényleg miénk a domain. Ekkor létre fog hozni egy DNS txt rekordot, amit el kell helyezni a DNS beállításokban. De ha NO-ip-s domain nevünk van (ami jelen esetben igaz) akkor ezt ő kb 5 perc alatt elhelyezi a DNS-ben, nekünk ezzel külön nincs dolgunk.
Az SSL beállításokban a NO-ip oldalán a gomb Verify-ra változik:
:[[File:ClipCapIt-210829-220506.PNG]]
Ezt kell nyomkodni, addig amíg ki nem írja, hogy a dns verifikáció megtörtént, ekkor fogják csak aláírni a cert-et, amit majd emailben kb 10 perc után küldenek.
Az email-ben lesz egy letöltő gomb:
:[[File:ClipCapIt-210829-220604.PNG]]
