7,540
edits
Changes
→Kulcsok legyártása
SHA-1-es aláírás (Chrome 53)
:[[File:ClipCapIt-170311-230151.PNG]]
SHA-2-es aláírás:
:[[File:ClipCapIt-170311-230344.PNG]]
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 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
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
</pre>
{{note|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.
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:
<pre># 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
Ezzel előáll a szerver tanúsítványa:
admin.berki2.org-server.cer
</pre>
{{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. }}
Kulcs neve
Hol van
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é.
