Tanúsítvány kiszolgáló telepítése Ubuntu alapon

Elméleti háttér

A tanúsítványkibocsátó (Certificate Authority, CA) fő feladata a digitális tanúsítványok kiadása, aláírása és visszavonása. A CA olyan hitelesítő szervezet, amely azonosítja a tanúsítványkérelmezőket, és garantálja, hogy a tanúsítványokhoz tartozó nyilvános kulcsok és az azokkal azonosított entitások (például szervezetek vagy személyek) valódiak és hitelesek.

A CA-k hatékonyan működnek a digitális tanúsítványok rendszerében, mert megbízható források, amelyeket a böngészők és más szoftverek előre engedélyeznek. A CA-k által ellenőrzött (aláírt) tanúsítványokkal rendelkező webhelyek biztonságosan kommunikálhatnak az interneten keresztül, mivel a böngészők és a szoftverek megbízható forrásból származó kulcsokat használnak a titkosítás és a digitális azonosítás érdekében. A CA-k a digitális tanúsítványok kiadásán keresztül hozzájárulnak az internetbiztonsághoz és a digitális adatvédelemhez.

A tanúsítványkibocsátóknak (CA) több típusát különböztetjük meg:

Központi CA (Central CA): A központi CA a hitelesítő szervezet, amely a tanúsítványok kiadásáért és visszavonásáért felelős. Ez általában egy nagyvállalat vagy állami szervezet, amely saját CA-t működtet.

Hierarchikus CA (Hierarchical CA): A hierarchikus CA a központi CA ágai, amelyek lehetővé teszik a különböző szervezeteknek vagy részlegeknek a saját tanúsítványaik kiadását. Ez az elrendezés lehetővé teszi az egyszerűbb és hatékonyabb tanúsítványkezelést.

Önálló CA (Standalone CA, Private CA): Az önálló CA olyan tanúsítványkibocsátó, amely nem hierarchikus CA-hoz tartozik, hanem önállóan működik. Általában kisebb vállalatok vagy magánszemélyek használják.

Közösségi CA (Community CA): A közösségi CA olyan tanúsítványkibocsátó, amelyet a közösség működtet. Ez az elrendezés lehetővé teszi a tanúsítványok széles körű elterjedését az interneten.

Rövid élettartamú CA (Short-lived CA): A rövid élettartamú CA olyan CA, amely csak rövid időtartamra, általában csak egy ülésre működik. Ez a típusú CA kisebb szervezetek vagy személyek számára lehet hasznos, akiknek csak rövid időre van szükségük tanúsítványra.

A CA rendszerint a PKI (Public Key Infrastructure) infrastruktúrát használja. A PKI infrastruktúrában az egyes felhasználók és szervezetek (illetve az ő általuk üzemeltetett szerverek, szolgáltatások, entitások) azonosítására nyilvános és titkos kulcsokat használnak. A nyilvános kulcsokat megosztásra kerülnek, míg a titkos kulcsokat a tulajdonosok titokban tartják. A CA által aláírt tanúsítványok segítségével a felhasználók és a szervezetek ellenőrizhetik az egyes kulcsok hitelességét és megbízhatóságát.

A rendszer résztvevői

A következőkben egy webszerver biztonságos elérésén keresztül nézzük meg a rendszer felépítését és konfigurálását, mely az alábbi 4 résztvevőt tartalmazza:

1. A kliens: Ez futtatja a böngészőt, melyen keresztül a biztonságos weboldalt megnézzük.
2. A webszerver: Ez nyújtja a biztonságos webszolgáltatást https protokollon keresztül.
3. A névszerver: Ez oldja fel a webszerver domain nevét IP címre.
4. A tanúsítványkiszolgáló (CA): Ez hitelesíti a webszerver nyilvános kulcsát a kliens számára.

Használt fogalmak

Titkos és nyilvános kulcs (private key, public key)

A nyilvános és titkos kulcsok együtt alkotják a Public Key Infrastructure (PKI) alapját, megteremtve ezzel a kétoldalú hitelesítés és titkosítás lehetőségét. Minden entitás két kulccsal rendelkezik, a nyilvános és a titkos kulccsal. A nyilvános kulcs lehetővé teszi az üzenetek titkosítását, amelyet csak a nyilvános kulcshoz tartozó titkos kulcs felhasználásával lehet visszafejteni. A nyilvános kulcsokat bárki szabadon elérheti, míg a titkos kulcs csak annak a félnek a birtokában van, aki azt generálta. A titkos kulcsokat szigorúan titkosan kell tartani, mert az, aki birtokában van, hozzáférhet az összes üzenethez, amelyet az adott nyilvános kulcs segítségével titkosítottak. Egy hasonlattal élve, olyan ez mint a levelezés. Mindenki aki elektronikus leveleket fogad, rendelkezik egy email címmel és egy jelszóval. Aki ismeri az email címemet, az tud nekem levelet küldeni. (Mindenki, aki ismeri a publikus kulcsomat, tud nekem titkosított üzenetet küldeni.) Mindenki aki ismeri az email címhez tartozó jelszót, az el tudja olvasni az email címre küldött leveleket. (Mindenki aki ismeri a titkos kulcsot, meg tudja fejteni az hozzá tartozó nyilvános kulccsal titkosított üzeneteket.) Ahogyan a jelszavunkra vigyázunk, úgy kell vigyázni a titkos kulcsunkra is. Ahogyan az email címünket terjesztjük, úgy kell terjeszteni a nyilvános kulcsunkat is. És ahogyan az email címünkről meg kell győződnie a küldő félnek, hogy hozzánk tartozik, ugyanúgy a publikus kulcsunkról is meg kell győződnie, hogy hozzánk tartozik. Éppen ez utóbbira szolgál a tanúsítvány.  A bemutatott példában ilyen nyilvános és titkos kulcsot a webszervernek és a tanúsítványkiszolgálónak is generálunk, de a https kapcsolat kialakításakor a kliensen is létrejönnek automatikusan ezek a kulcsok. (Általában a PKI használatakor hosztoknak is van ilyen kulcspárja, és minden alkalmazásnak is, amely használja a PKI-t. )

Tanúsítvány aláírási kérelem (Certificate Signing Request – CSR)

Amikor egy entitás létrehozza a nyilvános kulcsát, akkor azt közzéteszi, hogy számára egy másik fél titkosítva küldhessen üzenetet. A bizalom növelésére a nyilvános kulcs tulajdonosa a nyilvános kulcsot egy megbízható szervezettel (a CA-val) digitálisan aláíratja. Ez az aláírás jelzi ezután mindenkinek (akik megbíznak a CA-ban), hogy a nyilvános kulcs ténylegesen a tulajdonosához tartozik. (Olyan ez, mint a papír alapú világban a pecsét vagy az aláírás. Egy hivatal a pecsétjével, egy személy az aláírásával igazolja, hogy ami azon a papíron van, az megfelel a valóságnak.) Ezt az aláírást az adott entitásnak kell kezdeményeznie a CA felé, és ennek érdekében hozza létre a tanúsítvány aláírási kérelmet (CSR). A CSR tartalmazza az entitás nyilvános kulcsát és az ahhoz tartozó további információkat. Ilyen információ például a Common Name (CN), amely az entitás domain neve vagy IP-címe lehet, a kérelem kiállítójának neve és a szervezeti egysége, vagy az aláírási algoritmus, amelyet az entitás használni kíván. A példánkban ilyen CSR-t a webszerver fog előállítani. (Ha én szeretném, hogy egy papír alapú dokumentumot egy hivatal lepecsételjen, aláírjon, készítenem kell egy kérvényt, amelyen keresztül ezt az igényt benyújtom. Ez a kérvény jelen esetben a tanúsítvány aláírási kérelem.)

Tanúsítvány

A tanúsítvány a PKI infrastruktúrában használt olyan digitális dokumentum (fájl), amely egy entitás – például egy webszerver – nyilvános kulcsát tartalmazza. A tanúsítvány tartalmazhatja emellett még az entitás nevét, a kulcs tulajdonosának azonosító adatait, a tanúsítvány kiállítójának (CA) nevét, a tanúsítvány CA általi aláírását, illetve a tanúsítvány érvényességi idejét. Amennyiben a CA-ban megbízunk, akkor az entitásban is megbízhatunk, hiszen a CA aláírásával bizonyítja, hogy a nyilvános kulcs megbízható féltől származik. (A tanúsítványt maga az entitás is aláírhatja, ilyenkor beszélünk önaláírt tanúsítványról. Ha magában az entitásban megbízunk, akkor az önáláírt tanúsítványában is megbízhatunk. Persze akkor minek kellett aláírnia?) A példánkban ilyen CA által aláírt tanúsítványa a webszervernek lesz. Fontos látni tehát, hogy nem maga a nyilvános kulcs kerül közzétételre, hanem a belőle készített tanúsítvány, amely tartalmazza a nyilvános kulcsot is. Meg kell azonban jegyezni, hogy arra is van lehetőség, hogy egy entitás a tanúsítványa helyett közvetlenül a nyilvános kulcsát tegye közzé. Ez előző email-es példával élve tegyük fel, hogy János szeretné az email címét (a nyilvános kulcsát) elterjeszteni. Én megkapom ezt az email címet (nyilvános kulcsot), de élek a gyanúval, hogy ha erre a címre írok (ezzel a nyilvános kulccsal titkosítok), azt nem János fogja elolvasni (a titkosított dokumentumot más fogja megfejteni). Vagyis én azt hiszem, hogy Jánosnak írok, de közben azt más olvassa. Ezért megkérem Eszter-t (ő jelen esetben a CA), akiben én megbízok, hogy győződjön meg arról, hogy valóban János-hoz tartozik ez az email cím, és ha igen, akkor azt tanúsítsa (elektronikus aláírásával). Amennyiben ezt a tanúsítványt én megkapom, akkor már megbízom János email címében. Persze János is aláírhatta volna ezt a tanúsítványt (ezt hívjuk önaláírt tanúsítványnak), de hát ha eddig nem bíztam meg János-ban, miért bíznék meg pont az aláírásában? Persze felmerülhet a kérdés, hogy Eszter-ben (a CA-ban) miért bízom meg? Neki is lehetne egy tanúsítványa, amit pedig Judit írt alá (akiben szintén megbízok). De Juditban miért bízok meg? Mert az ő tanúsítványát pedig Anna írta alá. És ez a lánc folytatódhat, ezt neveztük korábban hierarchikus CA-nak. Persze a sor végén kell lennie valamilyen első CA-na (ez a root CA), akiben mindenki aláírás nélkül vagy önaláírtan megbízik.

CA publikus tanúsítványa

A CA az entitás nyilvános kulcsát (pontosabban a tanúsítványát) a titkos kulcsával írja alá. Mivel ezt az aláírást a CA nyilvános kulcsával ellenőrizhetjük le, minden olyan kliensnek el kell juttatnunk a CA nyilvános kulcsát, amelyek az entitás nyilvános kulcsának aláírását le akarja ellenőrizni. Nem csupán maga a nyilvános kulcs, hanem a nyilvános kulcsot más információkkal együtt tartalmazó tanúsítvány lesz a klienshez eljuttatva. Ne keverjük össze a fogalmakat! Vegyük elő az előző email-es példát. János (ő az entitás, a webszerver) nyilvános kulcsát (pontosabban a nyilvános kulcsát tartalmazó tanúsítványát) Eszter (ő a CA) aláírja a titkos kulcsával. Én, aki meg akarok győződni János nyilvános kulcsának valódiságáról, látom János aláírt tanúsítványában Eszter aláírását, és ennek az aláírásnak a valódiságát kell leellenőriznem. Ehhez használom Eszter nyilvános kulcsát (tanúsítványát).

A kliens és a szerver közötti biztonságos csatorna kialakításáért a TLS/SSL protokoll felelős. Igazából ez két külön protokoll, először az SSL-t készítették el, majd ennek továbbfejlesztésével jött létre az TLS. Az adatátvitel biztonsága érdekében a következőket valósítják meg:

• Titkosítják a kommunikáció adatait. Ezzel biztosítja a kommunikáció bizalmi jellegét.
• Ellenőrzik az adatok sértetlenségét, vagyis, hogy az adatok megsérültek-e az átvitel során. Ezt nevezzük integritásvédelemnek.
• Biztosítja a felek azonosítását, tehát a két fél meggyőződhet arról, hogy a másik oldalon az van, akire számít.
• Gondoskodik a titkosításhoz és hitelesítéshez szükséges kulcsok biztonságos generálásáról és cseréjéről.

Észrevehetjük, hogy eddig is alapvetően ezen utolsó feladatról a kulcsokról volt szó. Nézzük meg az alábbi ábrán, hogyan történik ez:

Az ábrából is jól látható, hogy a titkos kulcsok nem hagyják el a tulajdonosuk (a webszerver és a CA) gépét, a nyilvános kulcs (illetve a belőlük készült tanúsítvány) viszont szabadon vándorolhat.

Megvizsgálva azt láthatjuk, hogy a szerver titkos kulcsa eddig mintha részt sem vett volna a folyamatban. Ez azért sincsen így, mert a nyilvános kulcs és a titkos kulcs kizárólag párban létezik, tehát ha valamelyikkel dolgozunk, akkor a másikkal leellenőrizhető, hogy ténylegesen a párjával történt a művelet (Ha titkosítunk a nyilvános kulccsal, a titkos kulccsal fejtjük meg. Ha aláírunk a titkos kulccsal, a nyilvános kulccsal ellenőrizzük le az aláírás hitelességét. Az egyiknek nincsen értelme a másik nélkül.) Az viszont igaz, hogy eddig a fenti folyamatban a szerver titkos kulcsának nem jutott tényleges szerep. (A CA titkos kulcsának igen, hiszen azzal írtunk alá.) Annak érdekében, hogy az adatforgalom számára kialakítsuk a biztonságos csatornát, már fogjuk használni a szerver titkos kulcsát is. Nézzük meg, hogyan.

Nagyon fontos azt látnunk, hogy a fenti ábra nem a https kapcsolatról szól (kizárólag egy ponton, ahol a szerver CA által aláírt tanúsítványa automatikusan letöltődik), hanem a hitelesítés során az egyes résztvevők, és az egyes kulcsok vagy tanúsítványok szerepéről. A https kapcsolat (és sok más biztonságos protokoll) ezeket csak felhasználja. Mint írtuk, a háttérben ezeket a folyamatokat a TLS/SSL protokoll irányítja. Nézzük ezeknek a főbb lépéseit a kiegészítve már a biztonságos adatcsatorna kialakításával:

1. A kapcsolat kezdetéhez a kliens számítógépen a böngésző címsorába írjuk a webszerver URL-jét: https://www.iktblog2.hu
2. A szerver válaszában elküldi a saját tanúsítványát, amely többek között tartalmazza a szerver nyilvános kulcsát a CA titkos kulcsával aláírva. (A titkos kulcs nincsen benne!)
3. A kliens leellenőrzi, hogy a szerver tanúsítványa ténylegesen a CA által van-e aláírva. Ehhez felhasználja a CA tanúsítványát, amely a böngésző (vagy a gép) tanúsítványtárolójába van importálva.
4. Amennyiben az ellenőrzés sikeres, tehát a kliens meggyőződött arról, hogy ténylegesen a CA írta alá a szerver tanúsítványát, a kliens generál egy szimmetrikus titkosító kulcsot. Ezt nevezzük pre-master kulcsnak. Ennek a kulcsnak semmi köze a PKI infrastruktúra publikus és a titkos kulcsaihoz. Ebből a pre-master kulcsból és egyéb kiegészítő információkból lesz egy végleges master kulcs generálva a későbbiekben. Ezt a pre-master kulcsot viszont először valahogy el kell juttatni a szerverre.
5. A kliens a pre-master szimmetrikus kulcsot először titkosítja a szerver nyilvános kulcsával (amit megkapott a szerver tanúsítványában), és elküldi a szervernek. Amennyiben ezt az információt bárki ellopja, nem tud vele mit kezdeni, mert dekódolásához a szerver titkos kulcsára van szükség.
6. A szerver a saját titkos kulcsával dekódolja a pre-master kulcsot. Ekkor a szerver és a kliens is rendelkezik ugyanazzal a pre-master szimmetrikus kulccsal.
7. Ekkor mind a kliens, mind a szerver oldalon elkezdődik master kulcs generálása. Mivel mind a két oldal ugyanazt a pre-master kulcsot használja kiindulásként, a használt algoritmus mindkét oldalon ugyanazt a master kulcsot eredményezi. Ezt a kulcsgenerálást nevezzük a TLS/SSL-ben kulcscserének (key exchange), melynek több módszere is létezik: Diffie-Hellman kulcscsere, RSA-alapú kulcscsere, Diffie-Hellman Ephemeral eljárás, Elliptic Curve Diffie-Hellman Ephemeral eljárás. (Ezeknek a kulcscsere protokolloknak a része a pre-master kulcs generálása és átvitele is.) Ezen protokollok tárgyalása messze túlmutat ezen írás keretein. Felmerülhet a kérdés, hogy miért generálja le mindkét oldal a master kulcsot? Nem lenne jobb, ha csak a például a szerver generálná le, és aztán átküldené a kliensnek? A válasz az, hogy habár lehet, hogy kevesebb erőforrásra lenne így szükség, de akkor a master kulcsot mozgatni kellene a hálózatban, és hiába a titkosított csatorna, ha az valahogy feltörhető, akkor a kulcs illetéktelen kezekbe kerülhetne. A legbiztonságosabb, ha a kulcs nem is kerül ki a hálózati kommunikációba.
8. Most, hogy mind a két oldal rendelkezik egy master szimmetrikus kulccsal, megkezdődhet már a webszerver és a böngésző biztonságos kommunikációja, mely a weblap letöltéséből és interakciójából áll egy olyan titkosított csatornán, melyet az előző lépésben generált kulccsal hoznak létre. Vegyük észre! A PKI infrastruktúra által biztosított biztonságos (titkosított) csatorna létrehozása nem a weblap számára jött létre, hanem csak annak a pre-master szimmetrikus kulcs biztonságos átvitelét biztosítja, amelyből generálják a master szimmetrikus kulcsot, és amellyel kialakítják azt a biztonságos csatornát, melyen keresztül a weblap adatait forgalmazzák. Vagyis a tényleges adattartalom titkosítása és megfejtése ugyanazzal a master szimmetrikus kulccsal történik. Ez a master szimmetrikus kulcs időnkét frissítésre kerül. Az új master kulcsot viszont általában már csak a szerver hozza létre, és a korábbi master kulccsal titkosítva küldi át a a kliensnek a szimmetrikus csatornán.

Az alábbi ábrán lehet nyomon követni a leírt folyamatot:

Ennyi elméleti bevezetés bőven elegendő. Kezdjük el a konfigurálást!

A konfigurálás

Ennyi elméleti bevezető után nézzük meg, hogy hogyan hozunk létre Linux-os környezetben egy ilyen többszereplős rendszert. A konfigurálás a következő főbb lépésekben történik meg:

1. Felinstalláljuk az easy-rsa-t a CA-ra.
2. Létrehozzuk PKI könyvtárat az easy-rsa-val. (Ebben fogja tárolni a CA többek között a saját kulcsait, és az aláírt tanusítványokat.)
3. Létrehozzuk a CA-t a PKI könyvtárban, benne a CA titkos kulcsát, majd ebből a nyilvános kulcsát tartalmazó tanúsítványát.
4. A CA nyilvános kulcsát tartalmazó tanúsítványt eljuttatjuk ahhoz a klienshez, amely ellenőrizni akarja a CA titkos kulcsával aláírt tanúsítványokat.
5. A webszerveren létrehozunk egy tanusítványaláírási kérelmet (CSR-t).
6. A tanúsítvány aláírási kérelmet eljuttatjuk a CA-hoz.
7. A CA titkos kulccsával aláírjuk a tanúsítványt.
8. Az aláírt tanúsítványt visszajuttatjuk a webszerverre, és konfiguráljuk vele a https kapcsolatot.

1. Az easy-rsa felinstallálása

Először frissítjük a csomaglistákat, majd felinstalláljuk az easy-rsa csomagot. Az easy-rsa egy olyan szoftvercsomag, amelyet a Public Key Infrastructure (PKI) kulcsainak és tanúsítványainak generálásához és kezeléséhez használhatunk.

sudo apt update
sudo apt install easy-rsa

Az easy-rsa csomag állományai a /usr/share/easy-rsa könyvtárban találhatók. Erről a könyvtárról készítünk egy másolatot például valamelyik felhasználói könyvtárba, így az adott felhasználó lesz jogosult a kulcsok és a tanúsítványok kezelésére. A biztonság érdekében jobb, ha ezt nem rendszergazdai jogosultsággal tesszük! (A példánkban a user nevű felhasználó nevében dolgozunk.) A felhasználó könyvtárában nem az easy-rsa fájljainak fizikai másolatát helyezzük el, hanem csupán az azokra mutató szimbolikus linkeket. Ezt azért tesszük így, mert ha a csomagot frissítjük, a linkeken keresztül a felhasználói könyvtárban rögtön a frissített fájlok érhetők el.

mkdir ~/easy-rsa
ln -s /usr/share/easy-rsa/* ~/easy-rsa/
chmod 700 /home/user/easy-rsa

2. A PKI inicializálása

A következő lépésben a PKI (Public Key Infrastructure) hierarchiához szükséges könyvtárakat és fájlokat kell létrehoznunk az easy-rsa mappában:

cd ~/easy-rsa
./easyrsa init-pki

A parancs hatására létrejön a PKI könyvtár, melyben a későbbiek során eltárolásra kerülnek majd a PKI infrastruktúra fájljai (kulcsok, tanúsítványok, stb.).

3. A CA kulcspárjának generálása

Amikor a kulcspárt legeneráljuk, a nyilvános kulcshoz rögtön létrejön a tanúsítvány. A tanúsítványhoz viszont számos információt közölni kell a rendszerrel. Az easy-rsa használata esetén ezeket az információkat egy vars nevű szöveges állományban tároljuk el. Hozzuk tehát létre ezt a fájlt, és töltsük fel az alábbi tartalommal: (Értelemszerűen a környezeti változók értéke tetszés szerint megváltoztathatók.)

set_var EASYRSA_REQ_COUNTRY    "HU"
set_var EASYRSA_REQ_PROVINCE   "Budapest"
set_var EASYRSA_REQ_CITY       "Budapest"
set_var EASYRSA_REQ_ORG        "IKTBlogCA"
set_var EASYRSA_REQ_EMAIL      "admin@iktblog.hu"
set_var EASYRSA_REQ_OU         "IKTBlog"
set_var EASYRSA_ALGO           "ec"
set_var EASYRSA_DIGEST         "sha512"

Ezután már felépíthető a tanúsítványkiszolgáló:

./easyrsa build-ca

Az állományok legenerálásához még két kérdést tesz fel a program, meg kell adnunk a COMMON NAME-et és a jelmondatot. Mivel ezeket a kulcsokat a CA fogja használni, fogadjuk el a felajánlott EASY-CA nevet, míg a jelmondatnak tetszőleges értéket adhatunk. Ha a programot a nopass kapcsolóval indítjuk (easyrsa build-ca nopass), akkor nem kér jelmondatot. Ha bármilyen okból újra akarjuk generálni a kulcsokat, akkor használjuk újra az easyrsa init-pki parancsot, majd a kulcsgenerálást.

Számos állomány fog létrejönni, de közülük a két legfontosabb a ca.cert, mely a CA nyilvános kulcsát tartalmazó tanúsítvány (a pki könyvtárban lesz megtalálható), és a ca.key, mely a CA titkos kulcsa (a pki/private könyvtárban). A CA egy entitás (jelen esetben a webszerver) megbízhatóságát úgy jelzi, hogy az entitás tanúsítványát aláírja a titkos kulcsával (vagyis a ca.key-jel). A webszerver ezt az aláírt tanúsítványt küldi majd el a böngészőnek. A böngésző a CA tanúsítványával (vagyis a nyilvános kulcsával, a ca.cert állománnyal) ellenőrzi le, hogy az aláírás érvényes-e. Vagyis a ca.cert állományt el kell juttatni klienshez, és be kell tölteni a böngésző tanúsítványtárolójába.

4. A CA tanúsítványának eljuttatása a klienshez (a böngészőbe)

Ahogy olvastuk, a böngésző a webszerver tanúsítványában a CA digitális aláírását a CA tanúsítványával ellenőrzi le, vagyis rendelkeznie kell azzal. A következő lépésben így el kell juttatni a CA-tól a tanúsítványát (ca.cert) a böngészőbe. Ennek számos módja lehet: Letöltjük a CA weboldaláról, átvisszük valamilyen fizikai módon. Jelen esetben a legkönnyebb (mivel a CA-ba minden bizonnyal SSH-val bejelentkezhetünk a virtuális környezetünkben) az scp használata. Ha már a ca.crt átkerült a böngésző hosztjára, ott be kell tölteni a böngésző tanúsítványtárolójába. Chrome böngésző esetén ez a Beállítások → Adatvédelem és biztonság → Eszköztanúsítványok kezelése → Importálás menüpontban történik. Linux esetén a CA tanúsítványát a rendszer tanúsítványtárolójába kell tölteni az alábbi parancsokkal. (Tegyük fel, hogy a tanúsítványt a /tmp könyvtárába töltöttük fel korábban.)

sudo cp /tmp/ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

5. A tanúsítvány aláírási kérelem létrehozása a webszerveren

A tanúsítvány aláírási kérelem létrehozásához természetesen kell egy tanúsítvány, ami a webszerver nyilvános kulcsát tartalmazza. A nyilvános kulcsot viszont a titkos kulcs alapján hozzuk létre, így első lépésben a titkos kulcsot hozzuk létre, majd ebből generáljuk a nyilvános kulcsot.

Mindenekelőtt installáljuk fel az apache2-t és az openssl-t a webszerveren:

apt-get update
apt-get install apache2
apt-get install openssl

Ezután hozzuk létre a titkos kulcsot web-server.key néven:

openssl genrsa -out web-server.key

Majd a webszerver tanúsítvány aláírási kérelme (web-server.req) létrehozása következik. A parancs interaktívan rákérdez azokra az információkra, amelyeket korábban a CA-nál (hiszen ott is létrehoztunk tanúsítványt) a vars fájl változóiban állítottunk be.

openssl req -new -key web-server.key -out web-server.req

A tanúsítvány aláírási kérelem létrehozásához az alábbi információkat kell megadnunk:

• Country Name: A szervezet székhelyének kétbetűs országkódja.
• State or Province Name: Az az állam vagy megye, ahol a szervezet található.
• Locality Name: A szervezet székhelyének városa.
• Organization Name: A szervezet teljes vagy rövidített neve.
• Organizational Unit Name: A szervezeten belüli részleg neve.
• Common Name: Az a domain név, amelyre a tanúsítvány ki lesz állítva.
• Email Address: A domain név tulajdonosának email címe.
• Challenge password: A tanúsítvány visszavonásához használható mező. Üresen hagyható.
• Optional company name: Opcionálisan megadható szervezeti név. Üresen hagyható.

Amennyiben nem akarjuk ezeket az adatokat interaktívan megadni, a parancsba is beírhatjuk:

openssl req -new -key web-server.key -out server.req -subj /C=HU/ST=Budapest/L=Budapest/O=IKTBlog/OU=IKTBlog/CN=www.iktblog2.hu

Amennyiben egy korábban elkészített tanúsítvány aláírási kérelemből szeretnénk kiolvasni ezeket az információkat, az alábbi parancsot kell használni:

openssl req -in web-server.req -noout -subject

6. A tanúsítvány aláírási kérelem eljuttatása a CA-nak

Most, hogy elkészítettük a webszerver tanúsítvány aláírási kérelmét, azt át kell másolni a CA-ra. Ez megint a CA adottságain múlik, de például az scp parancs használatával ennyi a dolgunk: (A példában a CA IP címe a 192.168.0.109, és a user felhasználó nevében generáljuk az aláírást.)

scp ./web-server.req user@192.168.0.109:web-server.req

7. A tanúsítvány aláírási kérelem beimportálása és aláírása a CA-n

A CA-n a kérelmet először beimportáljuk (lépjünk be az easy-rsa könyvtárba előtte). A CA ezt a tanusítványt web-server néven azonosítja ezután.

./easyrsa import-req /home/user/web-server.req web-server

A CA ezt az alábbi üzenettel nyugtázza:

The request has been successfully imported with a short name of: web-server
You may now use this name to perform signing operations on this request.

Majd írjuk alá (a server kulcsszóval jelezzük, hogy szerver számára készül az aláírás):

./easyrsa sign-req server web-server

A képernyőn a következő üzenet jelzi a műveletet:

You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.
Request subject, to be signed as a server certificate for 3650 days:
subject=
    commonName                = www.iktblog2.hu
Type the word 'yes' to continue, or any other input to abort.
  Confirm request details: yes
. . .
Certificate created at: /home/user/easy-rsa/pki/issued/web-server.crt

Az aláírt tanúsítványt a CA pki/issued könyvtárában tárolja el a CA.

8. Az aláírt tanúsítvány visszajuttatása a webszerverre

Az aláírt tanúsítványt ismét az scp paranccsal tudjuk visszamásolni a webszerverre (A webszerver IP címe legyen 192.168.0.108):

scp pki/issued/web-server.crt user@192.168.0.0108:web-server.crt

Az apache2 konfigurálása a tanúsítvány használatára

Először is az apache2-n engedélyezzük az ssl használatát:

a2enmod ssl
service apache2 restart

Majd készítsünk el egy új konfigurációs fájlt a https-sel működő oldalunk számára:

nano /etc/apache2/sites-available/iktblog2.hu.conf

Töltsük fel ezzel a tartalommal:

<VirtualHost *:443>
   ServerName www.iktblog2.hu
   DocumentRoot /var/www/html
   SSLEngine on
   SSLCertificateFile /etc/ssl/certs/web-server.crt
   SSLCertificateKeyFile /etc/ssl/private/web-server.key
</VirtualHost>

Engedélyezzük ennek az új konfigurációs állománynak a használatát, majd indítsuk újra a webszervert:

a2ensite iktblog2.hu.conf
service apache2 restart

El is készültünk. Ha minden rendben ment, akkor már behívhatjuk https protokollal a böngészőbe a weboldalunk:

https://www.iktblog2.hu