A Continent TLS Client szoftver telepítéséhez a következőket kell tennie:
33. ábra: A Continent TLS Client szoftver telepítővarázslójának kezdőablakja.
34. ábra Ablak licencszerződés Continent TLS Client szoftver.
3. Jelölje be az „Elfogadom a licencszerződés feltételeit” négyzetet, majd kattintson a „Tovább” gombra. A képernyőn megjelenik a Continent TLS Client szoftverhez mellékelt licenckulcs papíron vagy elektronikus adathordozón történő megadására szolgáló ablak.
35. ábra: A Continent TLS Client szoftver licenckulcsának megadására szolgáló ablak.
4. Írja be licenckulcsés kattintson a "Tovább" gombra. A képernyőn megjelenik egy párbeszédablak a Continent TLS Client szoftver telepítési útvonalának kiválasztásához.
36. ábra: A Continent TLS Client szoftver telepítési útvonalának kiválasztására szolgáló ablak.
5. Hagyja meg az alapértelmezett telepítési útvonalat. Nyomja meg a "Tovább" gombot. A képernyőn megjelenik a "Start Configurator" párbeszédpanel.
37. ábra: A Continent TLS Client szoftver konfigurátorának elindítására szolgáló ablak.
6. Jelölje be a "Konfigurátor futtatása a telepítés befejezése után" jelölőnégyzetet.
38. ábra: A Continent TLS Client szoftver telepítésére vonatkozó készenléti ablak.
8. Kattintson a "Telepítés" gombra. Megkezdődik az alkatrész telepítése.
39. ábra: A Continent TLS Client szoftver telepítésének folyamata.
9. A képernyőn megjelenik a Continent TLS Client szoftver konfigurációs párbeszédablaka.
40. ábra A Continent TLS Client szoftver konfigurálása.
A szükséges szoftver konfigurálásához:
a) Az „Ügyfél TLS kontinens beállításai” részben hagyja meg a „Port” értéket alapértelmezés szerint 8080-al.
b) A "Védett szerver beállításai" részben a "Cím" mezőben adja meg a nevet TLS szerverek: lk.budget.gov.ru.
c) A "Védett kiszolgáló beállításai" részben a "Tanúsítvány" mezőben adja meg a jelen Útmutató 3.1. pontjában a helyi könyvtárba másolt TLS-kiszolgáló tanúsítványfájlját.
41. ábra: A Continent TLS Client szoftver konfigurálása. Tanúsítvány kiválasztása.
d) Ha a felhasználó munkaállomása nem használ külső proxyszervert, kattintson az "OK" gombra.
e) Ellenkező esetben adja meg a szervezet használandó külső proxyszerverének címét és portját.
42. ábra: A Continent TLS Client szoftverszolgáltatás beállítása. Külső proxyszerver beállítása.
f) Nyomja meg az OK gombot.
10. A képernyőn megjelenik a Continent TLS Client szoftver telepítésének befejezését szolgáló párbeszédpanel.
43. ábra: A Continent TLS Client szoftver telepítésének befejezését szolgáló párbeszédpanel.
11. Nyomja meg a "Befejezés" gombot.
12. A képernyőn megjelenik egy párbeszédpanel, amely arra kéri, hogy indítsa újra a felhasználó munkaállomását.
44. ábra: Párbeszéd a felhasználói munkaállomás újraindításának szükségességéről.
13. Nyomja meg a "Nem" gombot.
Szoftver Kontinens TLS VPN– a biztonságot nyújtó rendszer távoli hozzáférés a GOST titkosítási algoritmusokat használó webes alkalmazásokhoz. Continent TLS VPN implementációk kriptográfiai védelem HTTP-forgalom munkamenet szinten. Az információk titkosítása a GOST 28147–89 algoritmus szerint történik.
Távoli felhasználók azonosítása és hitelesítése
A felhasználók azonosítása és hitelesítése az x.509v3 szabvány nyilvános kulcsú tanúsítványaival történik (GOST R 31.11–94, 34.10–2001). A TLS VPN Continent ellenőrzi a kulcstanúsítványokat a tanúsítvány-visszavonási listákkal (CRL-ekkel). A tanúsítványokat egy külső tanúsító hatóság állítja ki.
A hitelesítési eljárások sikeres befejezése esetén a felhasználó kérése HTTP-n keresztül egy biztonságos hálózatra kerül a megfelelő webszerverre. Ebben az esetben a felhasználó minden HTTP-munkamenetéhez speciális azonosítók (kliensazonosító és IP-azonosító) kerülnek hozzáadásra.
A továbbított információk kriptográfiai védelme
A TLS VPN Continent a HTTP-forgalom kriptográfiai védelmét végzi munkamenet szinten. Az információk titkosítása a GOST 28147–89 algoritmus szerint történik. A hash függvény kiszámítása a GOST R 34.11–94, a GOST R 34.11–2012 algoritmus szerint történik. Az elektronikus aláírás létrehozása és ellenőrzése a GOST R 34.10–2001, GOST R 34.10–2012 algoritmusok szerint történik.
Védett szerverek elrejtése és címfordítás
A TLS VPN Continent szűri a kéréseket, és lefordítja a kérések címeit a webszerverekre vállalati hálózat. A címfordítás a „Continent TLS VPN” rendszergazdája által meghatározott szabályok szerint történik.
Hibatűrés és skálázhatóság
A TLS VPN Continent támogatja a nagy teljesítményű fürtrendszerben végzett munkát terheléselosztással (külső terheléselosztóval). A hibatűrés növelése redundáns csomópont hozzáadásával érhető el a fürthöz. Ugyanakkor a kiegyenlítő klaszter elemei korlátlanul növelhetők. Egy klaszterelem meghibásodása nem vezet a kapcsolatok megszakadásához, mivel a terhelés egyenletesen oszlik el a többi elem között.
Monitoring és eseménynaplózás
A TLS VPN-kontinensen az adminisztrátor mindig naprakész információkat kaphat a létrehozott kapcsolatok aktuális állapotáról és a munkájáról szóló statisztikákat. Az események naplózásra kerülnek a szerveren információ biztonság. Minden esemény elküldhető a megadott szerverre syslog formátumban további elemzés céljából, ami a SIEM rendszerekkel való integrációt a lehető legegyszerűbbé teszi.
Kényelmes kezelési eszközök
A kombináció a helyi és távoli eszközök webes felülettel és kényelmes grafikus felügyeleti konzollal rugalmas konfigurációt biztosít a TLS VPN Continent a biztonsági szabályzatok követelményeinek megfelelően.
Támogatott protokollok
A TLS VPN Continent támogatja a TLS v.1 és TLS v.2 protokollokat.
Felhasználói művelet bármely webböngészőn keresztül
A Continent TLS VPN Client alkalmazás segítségével a felhasználók bármely webböngészőből hozzáférhetnek a védett erőforrásokhoz. Continent TLS VPN Az ügyfél egy helyi proxy, amely elfogja a védett webszerverek böngészőforgalmát, és egy http alagútba csomagolja azt. Ennek köszönhetően a felhasználó bármilyen, a készülékére telepített webböngészővel dolgozhat.
Felhasználóbarát szoftverkliens használata
Felhasználóbarát szoftverkliens használata A Continent TLS VPN Client vagy a CryptoPro kliensként használható a felhasználó eszközén CSP verziók 3.6.1.
Az utóbbi időben egyre többet emlegetik a TLS-t és az SSL-t, egyre aktuálisabb a digitális tanúsítványok használata, sőt olyan cégek is megjelentek, amelyek készen állnak arra, hogy mindenki számára ingyenesen biztosítsák a digitális tanúsítványokat, hogy garantálják a forgalom titkosítását a látogatott oldalak és a kliens böngészője között. Erre persze a biztonság miatt van szükség, hogy a hálózaton senki ne tudja fogadni azokat az adatokat, amelyek a klienstől a szerverre és fordítva kerülnek. Hogyan működik mindez és hogyan kell használni? Ennek megértéséhez talán az elmélettel kell kezdeni, majd megmutatni a gyakorlatban. Tehát SSL és TLS.
Mi az SSL és mi a TLS?
Az SSL a Secure Socket Layer (Secure Socket Layer) rövidítése, amely a biztonságos socketek szintjét jelenti. TLS - Transport Layer Security, szállítási réteg biztonság. Az SSL egy régebbi rendszer, a TLS pedig újabb, és a Netscape Communications által kifejlesztett SSL 3.0 specifikáción alapul. Mindazonáltal ezeknek a protokolloknak a feladata ugyanaz - a biztonságos adatátvitel biztosítása két számítógép között az interneten. Ezt az átvitelt különféle webhelyekhez használják, pl Email, üzenetküldéshez és még sok máshoz. Elvileg bármilyen információt átadhat ilyen módon, erről bővebben alább.
A biztonságos átvitelt a továbbított információk hitelesítése és titkosítása biztosítja. Valójában ezek a protokollok, a TLS és az SSL ugyanúgy működnek, nincsenek alapvető különbségek. A TLS az SSL utódjának mondható, bár egyidejűleg, akár ugyanazon a szerveren is használhatók. Erre a támogatásra azért van szükség, hogy az új ügyfelekkel (eszközök és böngészők) és a TLS-t nem támogató régi kliensekkel is működjön. A protokollok megjelenési sorrendje így néz ki:
SSL 1.0 – soha nem tették közzé
SSL 2.0 – 1995. február
SSL 3.0 – 1996
TLS 1.0 – 1999. január
TLS 1.1 – 2006. április
TLS 1.2 – 2008. augusztus
Hogyan működik az SSL és a TLS
Az SSL és a TLS működési elve, mint mondtam, ugyanaz. A TCP / IP protokollon keresztül titkosított csatorna jön létre, amelyen belül az adatátvitel az alkalmazási protokollon keresztül történik - HTTP, FTP stb. Íme, hogyan ábrázolható grafikusan:
Az alkalmazásprotokoll TLS/SSL-be van csomagolva, amely viszont TCP/IP-be van csomagolva. Valójában az alkalmazás protokoll adatai TCP / IP-n keresztül kerülnek továbbításra, de titkosítva vannak. És csak az a gép tudja visszafejteni a továbbított adatokat, amelyik létrehozta a kapcsolatot. Mindenki számára, aki megkapja a továbbított csomagokat, ez az információ értelmetlen lesz, ha nem tudja visszafejteni.
A kapcsolat létrehozása több lépésben történik:
1) A kliens kapcsolatot létesít a szerverrel, és biztonságos kapcsolatot kér. Ezt úgy érheti el, hogy kapcsolatot létesít egy olyan porton, amelyet eredetileg SSL/TLS-re terveztek, például 443, vagy további kérés az ügyfél biztonságos kapcsolatot létesít a normál kapcsolat létrehozása után.
2) A kapcsolat létesítésekor a kliens megad egy listát azokról a titkosítási algoritmusokról, amelyeket "ismer". A szerver összehasonlítja a kapott listát azokkal az algoritmusokkal, amelyeket maga a szerver "ismer", és kiválasztja a legmegbízhatóbb algoritmust, majd megmondja a kliensnek, hogy melyik algoritmust használja.
3) A szerver elküldi a kliensnek a hitelesítésszolgáltató által aláírt digitális tanúsítványát és a szerver nyilvános kulcsát.
4) Az ügyfél kapcsolatba léphet a kiszolgáló tanúsítványát aláíró megbízható CA kiszolgálójával, és ellenőrizheti, hogy a kiszolgáló tanúsítványa érvényes-e. De lehet, hogy nem kapcsolódik. Az operációs rendszerben általában már telepítve vannak a hitelesítésszolgáltatók gyökértanúsítványai, amelyekkel szemben a szervertanúsítványok, például a böngészők aláírásait ellenőrzik.
5) A rendszer létrehoz egy munkamenetkulcsot a biztonságos kapcsolathoz. Ez a következő módon történik:
- A kliens véletlenszerű digitális sorozatot generál
- A kliens a szerver nyilvános kulcsával titkosítja és az eredményt elküldi a szervernek
- A szerver a privát kulccsal visszafejti a kapott sorozatot
Mivel a titkosítási algoritmus aszimmetrikus, csak a szerver tudja visszafejteni a sorozatot. Aszimmetrikus titkosítás használatakor két kulcsot használnak - privát és nyilvános. A nyilvánosan elküldött üzenet titkosításra kerül, a privát üzenet pedig visszafejtésre kerül. A nyilvános kulccsal nem lehet visszafejteni az üzenetet.
6) Ezzel titkosított kapcsolat jön létre. A rajta továbbított adatok titkosításra és visszafejtésre kerülnek a kapcsolat megszakításáig.
Gyökértanúsítvány
Csak fent említettem a gyökértanúsítványt. Ez egy jogosultsági központ tanúsítványa, amelynek aláírása igazolja, hogy az aláírt tanúsítvány a megfelelő szolgáltatáshoz tartozik. Maga a tanúsítvány általában számos információs mezőt tartalmaz, amelyek a tanúsítványt kibocsátó szerver nevével és a tanúsítvány érvényességi idejével kapcsolatos információkat tartalmaznak. Ha a tanúsítvány lejárt, akkor az érvénytelen.
Aláírási kérelem (CSR, tanúsítvány aláírási kérés)
Aláírt szervertanúsítvány beszerzéséhez létre kell hoznia egy aláírási kérelmet (CSR, Certificate Sign Request), és el kell küldenie ezt a kérelmet egy jogosultsági központnak, amely egy aláírt tanúsítványt küld vissza, amely közvetlenül a szerveren van telepítve, majd meglátjuk, hogyan tedd ezt a gyakorlatban alább. Először egy titkosítási kulcsot állítunk elő, majd ennek alapján egy aláírási kérelmet, egy CSR fájlt állítunk elő.
Ügyféltanúsítvány
Ügyféltanúsítvány generálható eszközhasználatra és felhasználói használatra is. Általában az ilyen tanúsítványokat kétirányú ellenőrzésre használják, amikor a kliens ellenőrzi, hogy a kiszolgáló valóban az, akinek állítja magát, és a szerver válaszul ugyanezt teszi. Ezt az interakciót kétirányú hitelesítésnek vagy kölcsönös hitelesítésnek nevezik. A kétirányú hitelesítés lehetővé teszi a biztonsági szint növelését az egyirányú hitelesítéshez képest, és helyettesítheti a bejelentkezési névvel és jelszóval történő hitelesítést.
A tanúsítványok generálására szolgáló műveletek lánca
Lássuk a gyakorlatban, hogy a kezdetektől fogva hogyan működnek a tanúsítványok generálásával kapcsolatos műveletek, és egyben a gyakorlatban is.
Az első lépés a gyökértanúsítvány létrehozása. A gyökértanúsítványt saját maga írja alá. Ezután más tanúsítványok is alá lesznek írva ezzel a tanúsítvánnyal.
$ openssl genrsa -out root.key 2048 RSA privát kulcs generálása, 2048 bit hosszú modulus ........+++ ................... ........................+++ e 65537 (0x10001) $ openssl req -new -key root.key -out root.csr Ön hamarosan felkérik, hogy adja meg azokat az információkat, amelyeket beépít a tanúsítványkérelmébe. Amit most beír, az úgynevezett megkülönböztetett név vagy elutasított név. Van jó néhány mező, de tudsz hagyjon üresen Egyes mezőknél alapértelmezett érték lesz. Ha „.”-t ír be, a mező üresen marad. ----- Ország neve (2 betűs kód) :RU állam vagy tartomány neve (teljes név) :N/A Helység neve (pl. város) :Szentpétervár Szervezet neve (pl. cég) :Cégem Szervezeti Egység neve (pl. szakasz) :Az informatikai szolgáltatás általános neve (pl. a szerver FQDN-je vagy az ÖN neve) :Cégem gyökértanúsítványának e-mail címe: [e-mail védett] Kérjük, adja meg a következő "extra" attribútumokat, amelyeket a tanúsítványkérelmével együtt el kell küldeni Kihívás jelszó : Opcionális cégnév :My Company $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Aláírás ok tárgy=/C=RU/ST=N/A/L=Szentpétervár/O=Cégem/OU=IT-szolgáltatás/CN=My Company gyökértanúsítvány/ [e-mail védett] Privát kulcs beszerzése
Így először egy privát kulcsot, majd egy aláírási kérelmet generáltunk, majd a saját kérésünket aláírtuk a kulcsunkkal és megkaptuk a 10 évre kiállított saját digitális tanúsítványunkat. A jelszó (kihívási jelszó) elhagyható a tanúsítvány generálásakor.
A privát kulcsot biztonságos helyen KELL tárolni, amivel bármilyen tanúsítványt aláírhat a nevében. Az így kapott gyökértanúsítvány segítségével azonosítható, hogy például a szerver tanúsítványát mi írtuk alá, nem pedig valaki más. Ezeket a műveleteket az engedélyezési központok hajtják végre, amikor saját tanúsítványaikat generálják. A gyökértanúsítvány létrehozása után megkezdheti a szervertanúsítvány generálását.
Tanúsítvány információinak megtekintése
A tanúsítvány tartalma az alábbi módon tekinthető meg:
$ openssl x509 -noout -issuer -enddate -in root.pem kibocsátó= /C=RU/ST=N/A/L=Szentpétervár/O=Cégem/OU=IT szolgáltatás/CN=Cégem gyökértanúsítványa/ [e-mail védett] notAfter=2025. január 22. 11:49:41 GMT
Látjuk, ki adta ki ezt a tanúsítványt, és mikor jár le.
Szerver tanúsítvány
Egy szerver tanúsítványának aláírásához a következőket kell tennünk:
1) Hozzon létre egy kulcsot
2) Hozzon létre egy aláírási kérelmet
3) Küldje el a CSR-fájlt az engedélyezési központnak, vagy írja alá saját maga
A szervertanúsítvány tartalmazhatja a kiszolgálótanúsítványt aláíró tanúsítványláncot, de tárolható külön fájlban is. Elvileg minden nagyjából ugyanúgy néz ki, mint a gyökértanúsítvány generálásakor
$ openssl genrsa -out server.key 2048 RSA privát kulcs generálása, 2048 bit hosszú modulus ................................ .................................................. +++ ...................+++ e 65537 (0x10001) $ openssl req -new -key server.key - out server.csr Ön hamarosan meg kell adnia azokat az információkat, amelyeket beépít a tanúsítványkérelmébe. Amit most beír, az úgynevezett megkülönböztetett név vagy elutasított név. Jó néhány mező van, de néhány mezőt üresen hagyhat Egyes mezőknél alapértelmezett érték lesz. Ha beírja a „.” mezőt, a mező üresen marad. ----- Ország neve (2 betűs kód) :RU állam vagy tartomány neve (teljes név) :N/A Helység neve (pl. város) :Szentpétervár Szervezet neve (pl. cég) :Cégem Szervezeti Egység neve (pl. szakasz) :Az IT-szolgáltatás általános neve (pl. a kiszolgáló teljes tartománynevének száma vagy az ÖN neve) :www.mycompany.com E-mail cím: [e-mail védett] Kérjük, adja meg a következő "extra" attribútumokat, amelyeket el kell küldeni a tanúsítványkérelmével. Kihívás jelszó : Nem kötelező cégnév : $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out szerver. pem -days 365 Aláírás rendben tárgy=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/ [e-mail védett] CA privát kulcs lekérése $ openssl x509 -noout -kiadó -tárgy -végdátum -in server.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=Cégem/OU=IT szolgáltatás/CN =Cégem gyökértanúsítványa/ [e-mail védett] tárgy= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/ [e-mail védett] notAfter=2016. január 25. 12:22:32 GMT
Így a szervertanúsítvány aláírásra kerül, és tudni fogjuk, melyik szervezet adta ki ezt a tanúsítványt. Az aláírás után a kész tanúsítvány rendeltetésszerűen használható, például webszerverre telepítve.
SSL/TLS-tanúsítvány telepítése nginx-szel rendelkező kiszolgálón
Az SSL / TLS tanúsítvány telepítéséhez az nginx webszerverre néhány egyszerű lépést kell követnie:
1) Másolja a .key és .pem fájlokat a szerverre. Különböző operációs rendszereken a tanúsítványok és kulcsok különböző könyvtárakban tárolhatók. Debianon például ez az /etc/ssl/certs a tanúsítványokhoz és az /etc/ssl/private a kulcsokhoz. CentOS-en ezek a következők: /etc/pki/tls/certs és /etc/pki/tls/private
2) Előírni szükséges beállításokat ban ben konfigurációs fájl a házigazda számára. Így kell kinéznie (ez csak egy példa):
Szerver ( figyeljen 443; szerver_neve www.mycompany.com; root html; index index.html index.htm; ssl on; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # SSLv3 csak nem ajánlott!!! # Itt van például ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+MAGAS:+KÖZÉP:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on; location / ($uri/files =4uri_próbálkozás $04; )
3) Indítsa újra az nginx-et
4) Lépjen a böngésző 443-as portjára – https://www.mycompany.com, és ellenőrizze annak teljesítményét.
SSL/TLS-tanúsítvány telepítése Apache kiszolgálóra
Az SSL/TLS-tanúsítvány telepítése az Apache-on nagyjából ugyanúgy néz ki.
1) Másolja a kulcs- és tanúsítványfájlokat a kiszolgálóra a megfelelő könyvtárakba
2) Engedélyezze az ssl modult Apache számára az "a2enmod ssl" paranccsal, ha még nincs engedélyezve
3) Hozzon létre egy virtuális gazdagépet, amely a 443-as porton figyel. A konfiguráció valahogy így fog kinézni:
Ugyanakkor még egy dolgot meg kell tenni. A rendszertől függően keresse meg a httpd.conf, apache2.conf vagy ports.conf fájlban a konfiguráció következő részét:
Ha nincs ilyen feltétel, akkor hozzá kell adni a konfigurációhoz. És még valami: hozzá kell adni egy sort
NameVirtualHost *:443
Ez a sor lehet a httpd.conf, az apache2.conf vagy a ports.conf fájlokban
4) Indítsa újra az Apache webszervert
Hozzon létre egy ügyféltanúsítványt
Az ügyféltanúsítvány nagyjából ugyanúgy jön létre, mint a szervertanúsítvány.
$ openssl genrsa -out client.key 2048 RSA privát kulcs generálása, 2048 bit hosszú modulus ........................+++ ..... ..............................................+++ e is 65537 (0x10001) $ openssl req -new -key client.key -out client.csr Amit most beír, az úgynevezett megkülönböztetett név vagy elutasított név. Jó néhány mező van, de néhány mezőt üresen hagyhat Egyes mezőknél alapértelmezett érték lesz. Ha beírja a „.” mezőt, a mező üresen marad. ----- Ország neve (2 betűs kód) :RU állam vagy tartomány neve (teljes név) :Szentpétervár Helység neve (pl. város) :^C [e-mail védett]:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr Arra készül, hogy olyan információkat adjon meg, amelyek beépülnek a tanúsítványkérésébe. Amit most beír, az úgynevezett megkülönböztetett név vagy elutasított név. Jó néhány mező van, de néhány mezőt üresen hagyhat Egyes mezőknél alapértelmezett érték lesz. Ha beírja a „.” mezőt, a mező üresen marad. ----- Ország neve (2 betűs kód) :RU állam vagy tartomány neve (teljes név) :N/A Helység neve (pl. város) :Szentpétervár Szervezet neve (pl. cég) :Vállalatom szervezeti egységének neve (pl. szakasz) :Műszaki általános név (pl. szerver FQDN vagy AZ ÖN neve) :Ivan Ivanov E-mail cím: [e-mail védett] Kérjük, adja meg a következő "extra" attribútumokat, amelyeket el kell küldeni a tanúsítványkérelmével. Kihívás jelszó : Opcionális cégnév : $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out kliens. pem -days 365 Aláírás rendben tárgy=/C=RU/ST=N/A/L=Szentpétervár/O=Cégem/OU=Mérnökség/CN=Ivan Ivanov/ [e-mail védett] CA privát kulcs lekérése $ openssl x509 -noout -kiadó -tárgy -végdátum -in client.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=Cégem/OU=IT szolgáltatás/CN =Cégem gyökértanúsítványa/ [e-mail védett] tárgy= /C=RU/ST=N/A/L=Szentpétervár/O=Cégem/OU=Mérnökség/CN=Ivan Ivanov/ [e-mail védett] notAfter=2016. január 25. 13:17:15 GMT
Ha PKCS12 formátumú ügyféltanúsítványra van szüksége, hozza létre:
$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Exportálási jelszó megadása: Ellenőrzés - Exportálási jelszó megadása:
Most már használhatjuk a kliens tanúsítványt a szerverünkkel való együttműködéshez.
Az nginx beállítása ügyféltanúsítványok használatára
Leggyakrabban, mint mondtam, egyirányú hitelesítést alkalmaznak, általában csak a szervertanúsítványt ellenőrzik. Nézzük meg, hogyan vehetjük rá az nginx webszervert az ügyféltanúsítvány érvényesítésére. Az ügyféltanúsítványokkal való munkavégzéshez lehetőségeket kell hozzáadni a szerver szakaszhoz:
# Az ssl_client_certificate /etc/nginx/certs/clientroot.pem ügyfél által aláírt gyökértanúsítvány(ok); # Lehetséges lehetőségek: be | ki | opcionális | optional_no_ca ssl_verify_client opcionális; # Az ügyfél által aláírt tanúsítványlánc ellenőrzésének mélysége ssl_verify_depth 2;
Ezt követően újra kell indítani a beállításokat vagy a teljes szervert, és ellenőrizheti a munkát.
Az Apache beállítása ügyféltanúsítványok használatára
Az Apache is hozzáadással konfigurálható további beállítások a virtuális gazdagép részhez:
# Az SSLCARevocationPath ügyfelek ellenőrzéséhez szükséges gyökértanúsítványokat tartalmazó könyvtár /etc/apache2/ssl.crl/ # vagy az SSLCARevocationFile tanúsítványokat tartalmazó fájl /etc/apache2/ssl.crl/ca-bundle.crl # Ügyfél-ellenőrzési lehetőség. A lehetőségek a következők: # none, opcionális, követelmény és optional_no_ca SSLVerifyClient request # Az aláírás mélysége lánckeresés. Alapértelmezett 1 SSLVerifyDepth 2
Mint látható, a lehetőségek nagyjából ugyanazok, mint az nginx esetében, mivel az ellenőrzési folyamat egységesen van megszervezve.
Tanúsítványinformációk meghallgatása openssl-lel
Annak ellenőrzésére, hogy a kiszolgáló együttműködik-e az ügyféltanúsítványokkal, ellenőrizze, hogy a kapcsolat létrejött-e TLS/SSL használatával.
A szerver oldalon az openssl használatával kezdjük el hallgatni a portot:
Openssl s_server -accept 443 -cert server.pem -key server.key -state
A kliens oldalon például a culr-rel érjük el a szervert:
Curl -k https://127.0.0.1:443
A konzolban a szerver oldalról megfigyelhető a szerver és a kliens közötti információcsere folyamata.
Használhatja a -verify [ellenőrzési mélység] és a -Verify [ellenőrzési mélység] opciókat is. A kisbetűs opció tanúsítványt kér az ügyféltől, de nem kötelező azt megadnia. Nagybetűvel - Ha a tanúsítvány nincs megadva, hiba történik. Kezdjük a hallgatást a szerver oldaláról így:
Openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3
Szerver oldalról a hiba így néz ki:
140203927217808:error:140890C7:SSL-rutinok:SSL3_GET_CLIENT_CERTIFICATE:a peer nem adott vissza tanúsítványt:s3_srvr.c:3287:
Ügyfél oldalról így:
Curl: (35) hiba:14094410:SSL-rutinok:SSL3_READ_BYTES:sslv3-riasztás kézfogási hiba
Adjon hozzá egy tanúsítványt az ügyféloldalon és Domain név(ellenőrzés céljából megadhatja a 127.0.0.1 címhez tartozó gazdagép nevét az /etc/hosts fájlban):
Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key
Most a kapcsolat sikeres lesz, és telepítheti a szervertanúsítványt a webszerverre, átadhatja az ügyféltanúsítványt az ügyfélnek, és dolgozhat velük.
Biztonság
SSL/TLS használatakor az egyik fő módszer a MITM (Man In The Middle) módszer. Ez a módszer egy kiszolgálótanúsítvány és -kulcs használatán alapul néhány csomóponton, amely figyeli a forgalmat, és visszafejti a kiszolgáló és az ügyfél között kicserélt információkat. A hallgatás megszervezéséhez használhatja például az sslsniff programot. Ezért általában kívánatos a gyökértanúsítványt és a kulcsot egy olyan gépen tárolni, amely nem kapcsolódik a hálózathoz, az aláírási kérelmeket flash meghajtón hozni aláírásra, aláírni és elvinni ugyanúgy. És természetesen készítsen biztonsági másolatot.
Általában így használják a digitális tanúsítványokat, valamint a TLS és SSL protokollokat. Ha bármilyen kérdése / kiegészítése van, írja meg a megjegyzésekben.
Ezt a bejegyzést a szerző címkézve tette közzé.Hozzászólás navigáció
: 29 hozzászólás
cl-service.com
A kliens a tanúsítvány megrendelésekor maga generálja a CSR-t, ahol a kliens a privát kulcs tárolása mellett is dönt, a tanúsítvány kiadásához nincs szükségünk privát kulcsra és az ügyfél semmilyen módon nem adja át nekünk. Természetesen, ha ez egy normál virtuálison történik, akkor a rendszergazdák a root hozzáférés a szerver hozzáfér az ott tárolt kulcsokhoz.
- Jóakaró.
A mellek témája nem kerül nyilvánosságra, mert a leírt PKI technológiának semmi köze a téma címéhez. Ha csak okkal is, adnék linkeket az rfc-hez.
P.S. Volt egy vicc egy kutyáról és egy bolháról. - Jóakaró.
Soha nem akarta megbántani. Információkat kerestem az SSl és a TLS közötti különbségről a gyakorlatban, és az Ön linkje volt a Google-ban az első. A téma címe felkeltette az érdeklődését. Minden szuper, csak így tovább!
- DrAibolit
Köszönöm az értelmes magyarázatokat a digitális tanúsítással kapcsolatban. új vagyok ebben =)
Remélem sikerül tisztázni a következő kérdést.
Mivel a csalás témája nagyon fejlett az internetes iparban, szeretném megtanulni, hogyan lehet önállóan meghatározni az általam látogatott oldalak „tetűit” (főleg ott, ahol van készpénz és fizetés, befektetés, stb.), és meghatározni, ez alapján a bizalmam mértéke (gyakran kell regisztrálnom, személyes adatokat meghagynom, vásárolnom, tranzakciókat, befektetéseket bonyolítok le). Ha jól értem, hogy ennek a tanúsítványnak a megléte lehetővé teszi egy ilyen értékelés elvégzését. Nos, viszont nem probléma és még ingyen is beszerezni.
Hogyan, vagy melyik program segítségével lehet meghatározni egy adott webhely digitális tanúsítványának meglétét? és lehetőleg a kategóriája, amelyet akkor rendelnek hozzá, amikor egy speciális hatóság kiadja az SSL DV-t (a tanúsítvány kiadása csak a domain ellenőrzésével történik), SSL OV-t (a szervezet ellenőrzésével), EV-t (a jogi személy kiterjesztett ellenőrzésével). Valószínűleg csaló webhelyek utolsó lehetőség tanúsítvány nem kerül felhasználásra.
Örülnék, ha további módszereket mondana el a webhelyek megbízhatóságának meghatározására))- mnorin Hozzászólás szerzője
Néhány konkrét program ilyen célokra még nem találkoztam, de tudok pár tippet adni ez ügyben.
Használhatja például a Chromiumot ill Google Chrome. Vegyük például a https://www.thawte.com/ webhelyet – egy olyan céget, amely valójában digitális tanúsítványokkal foglalkozik.
NÁL NÉL címsor rá lesz írva a cég neve és egy zöld lakat. Ez azt jelenti, hogy a szervezet ellenőrizve van, legalább SSL OV.
Ha rákattint a zárra, és a "Részletek" legördülő listában, majd a "Tanúsítvány megtekintése" menüben láthatja a tanúsítványra vonatkozó információkat. A Thawte esetében a tanúsítványt a következő tanúsítvánnyal írják alá: "thawte Extended Validation SHA256 SSL CA", és a click.alfabank.ru tanúsítványát is a Thawte írja alá, de más tanúsítvánnyal. Ezek a "thawte EV SSL CA - G3", vagyis átmentek a kiterjesztett érvényesítésen is.
Valami ilyesmi.
- mnorin Hozzászólás szerzője
- Ruslan
"Az SSL és a TLS működési elve" szakasz, "A kliens véletlenszerű digitális sorozatot generál".
Biztos voltam benne, hogy a kliens létrehoz egy privát munkamenetet, és ennek megfelelően egy nyilvános kulcsot (amit nyilvánvalóan "digitális sorozatnak" nevezett). nyilvános kulcs továbbításra kerül a szerverre, és a szerver titkosítja a csomagokat a kliens felé a kliens munkamenet nyilvános kulcsával.
Kérlek pontosíts.
- Újonc
A cikk nagyon hasznos! Még gyakorlati példák is vannak =) Csak egy dolgot nem értettem - mi a különbség a gyökértanúsítvány és a szervertanúsítvány között? vagy ez ugyanaz?
- Vitalij
Szia.
A tárhely szolgáltatást kínált - SSL for virtuális szerverek. Kihasználták. Kiderült, hogy a harmadik szintre, i.e. A http://www.site.ru tanúsítvány érvénytelen, csak a site.ru számára. Ráadásul a látogatókat makacsul a https protokollra vetik, nem számít, hogy a site.ru vagy a http://www.site.ru oldalra mennek. Természetesen a második esetben a böngésző szívszorítóan káromkodni kezd, és a látogató soha nem jut el az oldalra.
Aki pedig eljutott az oldalra, annak kezdett elgörbülni az oldal, a menü egy része eltűnt, a keresési eredmények között egyes képek már nem jelennek meg egyes komponensek által.
Az E-budget munkaállomás felállítása több lépésben történik, nem bonyolultak, de odafigyelést igényelnek. Mindent az elektronikus költségvetés beállítására vonatkozó utasítások szerint csinálunk. Röviden és lényegre törően...
Elektronikus költségvetési munkahely beállítása
Gyökértanúsítvány e-költségvetés
Hozzon létre egy kulcsmappát a Dokumentumok mappában a letöltött tanúsítványok ebben a mappában való tárolására:
A http://roskazna.ru/gis/udostoveryayushhij-centr/kornevye-sertifikaty/ webhelyen a GIS menüben -> Tanúsító hatóság -> Gyökértanúsítványok, le kell töltenie " Gyökértanúsítvány (minősített)" (lásd az ábrát), vagy ha kapott egy flash meghajtót tanúsítványokkal, másolja ki azokat a Tanúsítványok mappából.
Tanúsítvány kontinens TLS VPN
A második letöltendő tanúsítvány a Continent TLS VPN-tanúsítvány, de nem találtam az új roskazna webhelyen, ezért betettem egy linket az oldalamról. Töltse le a TLS VPN Continent tanúsítványt a kulcs mappába, később szükségünk lesz rá a TLS Continent kliensprogram konfigurálásakor.
Telepítse a letöltött gyökértanúsítványt (minősített), hogy működjön az elektronikus költségvetéssel.
A START menü -> Minden program -> CRYPTO-PRO -> futtassa a Tanúsítványok programot.
Lépjen a Tanúsítványok elemre az alábbi ábra szerint:
Lépjen a Művelet menübe - Minden feladat - Importálás, megjelenik a Tanúsítványimportáló varázsló ablak - Következő - Áttekintés - Keresse meg a letöltött Gyökértanúsítvány (minősített) esetünkben a Saját dokumentumokban található a kulcs mappában
Ha mindent megfelelően csinált, akkor a Szövetségi Pénzügyminisztérium CA gyökértanúsítványa megjelenik a tanúsítványok mappában.
A "Continent TLS Client" telepítése az elektronikus költségvetéssel való munkavégzéshez
A Continent_tls_client_1.0.920.0 megtalálható az interneten.
Csomagolja ki a letöltött archívumot, lépjen a CD mappájába, és futtassa a ContinentTLSSetup.exe fájlt
Az elemben kattintson a Continent TLS Client KC2-re, és indítsa el a telepítést.
Elfogadjuk a feltételeket
A célmappában alapértelmezés szerint hagyja el
Az indító konfiguráló ablakban jelölje be a Konfigurátor futtatása a telepítés befejezése után négyzetet.
A telepítés során megjelenik a Szolgáltatásbeállítások ablak:
Cím - adja meg lk.budget.gov.ru
Tanúsítvány – válassza ki a második korábban letöltött tanúsítványt a kulcsmappában.
Kattintson az OK gombra, és fejezze be a telepítést, majd kész.
Újraindítást kért operációs rendszer nemmel válaszolunk.
A "Jinn-Client" elektronikus aláírási eszköz telepítése
A Jinn-Client programot letöltheti az internetről.
Lépjen a Jinn-client - CD mappába, futtassa a setup.exe fájlt
Kattintson a Jinn-Client listából, és elindul a program telepítése
Hagyja figyelmen kívül a hibát, kattintson a Folytatás, Tovább gombra, fogadja el a megállapodást, és kattintson a Tovább gombra.
Adja meg a kiadott licenckulcsot
Állítsa be az alapértelmezett programot, kattintson a Tovább gombra
Befejezzük a telepítést, válaszolunk az operációs rendszer újraindításával kapcsolatos kérdésre
A modul telepítése a "Cubesign" elektronikus aláírással való munkához
Ha szüksége van archívumra a programmal, írja meg a megjegyzésekben.
Futtassa a cubesign.msi telepítőfájlt
A Mozilla Firefox böngésző beállítása az elektronikus költségvetéssel való együttműködéshez.
1. Nyissa meg az "Eszközök" menüt, és válassza a "Beállítások" lehetőséget.
2. Lépjen a "Hálózat" lap "Speciális" részéhez
3. A „Kapcsolat” beállítások részben kattintson a „Konfigurálás…” gombra.
4. A megnyíló kapcsolati paraméterek ablakban állítsa be az értéket
"A proxyszolgáltatás kézi beállítása."
5. Állítsa be a HTTP-proxy mezők értékeit: 127.0.0.1; Port: 8080.
6. Nyomja meg az OK gombot.
7. A "Beállítások" ablakban kattintson az "OK" gombra.
Jelentkezzen be az Elektronikus költségvetés személyes fiókjába
Megnyílik egy ablak az elektronikus költségvetés személyes számlájára való belépéshez szükséges tanúsítvány kiválasztásával.
Jelöljön ki egy tanúsítványt a bejelentkezéshez Személyes terület E-költségvetés, ha a tanúsítvány privát részére van jelszó, írjon és kattintson az OK gombra, ezután megnyílik az E-költségvetés Személyes fiókja.
