Dokument sadrži uputstvo za postupak zahtevanja serverskih SSL digitalnih sertifikata u AMRESu, njihovu instalaciju na Linux i Microsoft platformama i korištenje u svrhu zaštite pristupa web, mail i radius servisima.

Dokument promoviše usvajanje digitalnih sertifikata u institucijama članicama Akademske mreže Srbije kao načina za uspostavljanje sigurnih kanala komunikacije.

Da bi korisnici prilikom preuzimanja ili slanja podataka na neki server imali zaštićenu komunikaciju, moraju biti sigurni da su zaista pristupili onom serveru kojem su imali nameru da pristupe i da niko ne može pročitati i/ili promeniti podatke koji se šalju ili primaju. Upotreba digitalnih sertifikata u kombinaciji sa SSL tehnologijom omogućava pomenutu sigurnost.

Opisane su komponente PKI infrastrukture, ali i način realizacije PKI funkcija na primeru uključivanja AMRESa u TCS (TERENA Certificate Service) servis. Navedene su i različite potrebe za korištenjem PKI u NRENu, koje zahtevaju različite tipove digitalnih sertifikata, ali je posebna pažnja posvećena korištenju PKI infrastrukture, odnosno digitalnih sertifikata u kombinaciji sa SSL tehnologijom u svrhu međusobne autentifikacije servisa i njihovih korisnika.

U dokumenta je objašnjen postupak pribavljanja serverskog sertifikata – generisanje ključa, formiranje sertifikata, priprema za/i podnošenje zahteva za potpisivanje serverskog sertifikata. U završnom delu dokumenta nalaze se uputstva za instalaciju digitalnih sertifikata na Linux serverima.

Razvoj elektronskih komunikacija doveo je do toga da se razmena informacija poverljive sadržine odvija svakodnevno. Da bi korisnici prilikom pristupa web, mail ili radius serverima preuzeli ili dali na uvid osetljive podatke (npr. korisnička imena) moraju biti sigurni da su pristupili pravom serveru te da je komunikacija sa serverom sigurna, da niko ne može da presretne/pročita i/ili promeni podatke. Korišćenje SSL tehnologije na serverima (https, pops i sl.) omogućava traženu sigurnost, ali zahteva da serveri imaju odgovarajuće digitalne sertifikate.

AMRES omogućava izdavanje serverskih SSL sertifikata u saradnji sa TERENA-om, a preko servisa TERENA Certificate Service (TCS). Servis je bespatan za sve institucije članice AMRESa.

Svrha dokumenta je da promoviše upotrebu serverskih sertifikata koji omogućavaju uspostavljanje sigurnijih kanala komunikacije. Dokument je namenjen IT administratorima u institucijama članicama AMRESa.

U prvom delu su date definicije termina i pojmova, te kriptografskih sistema, protokola i tehnika vezanih za upotrebu digitalnih sertifikata i infrastrukture javnih ključeva. Opisan je format i tipovi digitalnih sertifikata za različite potrebe u NRENu (Akademskoj mreži).

U drugom delu dokumenta, objašnjen je postupak pribavljanja serverskog sertifikata – generisanje ključa, formiranje sertifikata, priprema za/i podnošenje zahteva za potpisivanje serverskog sertifikata. U završnom delu dokumenta nalaze se uputstva za instalaciju digitalnih sertifikata na Linux serverima.

U ovom dokumentu se koriste tehnički termini iz oblasti sigurnosti, vezani za upotrebu infrastrukture javnih ključeva radi omogućavanja bezbedne komunikacije u računarskim mrežama. Da bi se olakšalo razumevanje dokumenta, definicije najvažnijih pojmova su izdvojene i navedene u nastavku.

Računarska sigurnost (computer security) se bazira na poverljivosti (confidentiality), integritetu (integrity) i dostupnosti (availability) podataka, dok bezbedna komunikacija podrazumeva očuvanje tajnosti (confidentiality), integriteta (integritety) i autentifikaciju sa neporecivošću (authenification with no-repudiation).

Autentifikacija (Authentication) je proces u kome se dokazuju identiteti krajnjih učesnika u komunikaciji (npr. korišćenjem digitalnih potpisa).

Integritet (Integrity) podataka garantuje da nije došlo do izmene podataka ili sadržaja poruke na njenom putu od izvora do odredišta, najčešće tako što se generiše heš poruke (niz bita fiksne dužine) koji se zajedno sa njom šalje. Na prijemu se istim algoritmom korišćenim pri slanju poruke formira heš i poredi sa hešom koji je primljen uz poruku. Ako se te dve vrednosti ne poklapaju znači da je došlo do izmene originalnog sadržaja poruke.

Tajnost ili poverljivost (Confidentality) podataka omogućava da podatak ili sadržaj poruke bude dostupan samo onome kome je poruka i namenjena, što se postiže šifrovanjem.

Neporicanje (Non-repudiation) onemogućava da onaj ko je poslao poruku kasnije tvrdi da je nije poslao. Kada pošiljalac potpiše poruku svojim digitalnim potpisom, zna se da je on koristio svoj privatni ključ kako bi formirao digitalni potpis. Kako samo pošiljalac ima pristup svom privatnom ključu to znači da je samo on mogao da pošalje odgovarajuću digitalno potpisanu poruku.

Kriptografskim ključevima nazivaju se:

Asimetrični par ključeva (Key Pair) – čine privatni i javni ključ, kao matematički par koji se koriste za potrebe rada asimetričnog kriptografskog algoritma, kao što je na primer RSA algoritam. Poruku šifrovanu javnim ključem može da pročita samo vlasnik privatnog ključa, dok poruku šifrovanu privatnim ključem mogu da pročitaju svi kojima je poznat javni ključ.

Privatni ključ (Private Key) – matematički podatak koji može da se koristi za kreiranje elektronskog potpisa ili za dešifrovanje dokumenta koji je šifrovan, primenom asimetričnog kriptografskog algoritma, da bude dostupan samo vlasniku privatnog ključa.

Javni ključ (Public Key) – matematički podatak koji može biti javno objavljen (najčešće se objavljuje u formi X.509v3 elektronskog sertifikata). Koristi se za verifikaciju elektronskog potpisa, kreiranog pomoću odgovarajućeg privatnog ključa koji je matematički par sa datim javnim ključem, kao i za šifrovanje podataka za korisnika koji poseduje odgovarajući privatni ključ.

Deljeni tajni ključ (Shared Secret Key) – matematički podatak koji se koristi za šifrovanje i dešifrovanje dokumenta koji je šifrovan primenom simetričnog kriptografskog algoritma. Takođe se koriste i termini simetrični ključ ili samo privatni ključ.

Infrastrukturu javnih ključeva (PKI - Public Key Infrastructure) čine hardver, softver, polise i procedure koje su neophodne za upravljanje, generisanje, skladištenje i distribuciju kriptografskih ključeva i digitalnih sertifikata. PKI je sigurnosna infrastrukturu čije su usluge implementirane uz pomoć koncepata sistema za enkripciju koji koriste asimetrične algoritme. U vezi sa PKI infrastrukturom koriste se sledeće definicije:

Sertifikaciono telo (CA – Certification Authority) – Pravno lice koje izdaje digitalne sertifikate.

Registraciono telo (RА – Registration Authority) – Entitet koji je odgovoran za inicijalnu identifikaciju i proveru podataka o korisniku/vlasniku sertifikata, kao i kreiranje zahteva za izdavanje sertifikata, ali koje ne izdaje i ne potpisuje sertifikat. RA je delegirano od CA da vrši odgovarajuće poslove (npr. identifikaciju korisnika).

Digitalni sertifikat (PKC - Public Key Cetrificate) – je dokument koji potvrđuje da javni ključ pripada određenom entitetu (RFC 5280). Koristi se i naziv elektronski sertifikat.

CА sertifikat – Sertifikat samog sertifikacionog tela. Potvrđuje da je CA upravo ono CA koje tvrdi da je. Može biti samopotpisan (kada je CA ujedno i koreno sertifikaciono telo - Root CA) ili biti izdat (digitalno potpisan) od strane drugog sertifikacionog tela – izdavaoca sertifikata.

Sertifikaciono telo – izdavalac sertifikata (CA-issuing certificate) – U kontekstu određenog sertifikata, sertifikaciono telo – izdavalac sertifikata je ono CA koje je izdalo (digitalno potpisalo) sertifikat.

Lanac certifikata (Certificate chain) – Uređena sekvenca sertifikata koja se, zajedno sa javnim ključem inicijalnog objektu u lancu, procesira u cilju provere istog u poslednjem objektu u lancu. Formira hijerarhijski lanac poverenja, gde jedan digitalni sertifikat potvrđuje autentičnost prethodnog digitalnog sertifikata.

Politika Sertifikacije (CP – Certificate Policy) – Imenovan skup pravila koji definiše primenljivost sertifikata na određeno okruženje i/ili na klasu aplikacija sa zajedničkim bezbednosnim zahtevima.

Praktična pravila rada Sertifikacionog tela (CPS - Certificate Practice Statement) – Javna praktična pravila i procedure koje sertifikaciono telo primenjuje u proceduri izdavanja sertifikata.

Druga strana – Primalac sertifikata koji proverava dati sertifikat i/ili primenom javnog ključa potpisnika iz sertifikata, proverava digitalni potpis dobijenog elektronskog dokumenta. Druga strana proverava validnost sertifikata u istom procesu. Druga strana može biti i korisnik sertifikata izdatog od strane istog sertifikacionog tela, ali i ne mora.

Potpisnik – entitet koji poseduje sredstvo za elektronsko potpisivanje i vrši elektronsko potpisivanje u svoje ime. To može biti fizičko lice ili entitet u pravnom licu kojem je izdat digitalni sertifikat.

Korisnik (ili krajnji entitet ili vlasnik sertifikata) – fizičko lice ili entite u pravnom licu kojem se izdaje digitalni sertifikat. Fizička lica su krajni korisnici. Pravna lica su institucije, koje digitalne sertifikate potražuju za svoje entitete, najčešće za svoje servere ili servise.

Lični korisnički sertifikat – elektronski sertifikat izdat fizičkom lice, odnosno krajnjem korisniku. Sadrži podatke koje identifikuju to lice, kao sto su # i sl.

Serverski sertifikat – elektronski sertifikat izdat plavnom licu, odnosno instituciji za potvrdu identiteta servera ili servisa u njegovom vlasništvu. Sadrži podatke koje identifikuju servis, npr. jednoznačni DNS naziv servera, # i sl.

Zahtev za dobijanje sertifikata (CSR – Certificate Service Request) – Standardni format koji se koristi za slanje zahteva za dobijanje sertifikata (preporuka PKCS #10).

Sertifikacija – process izdavanja digitalnog sertifikata.

Serijski broj sertifikata – Pridruženi broj sertifikatu koji jedinstveno identifikuje sertifikat u domenu datog CA.

Lista opozvanih sertifikata (CRL – Certificate Revocation List) – Lista izdata i elektronski potpisana od strane CA koja uključuje serijske brojeve opozvanih sertifikata i vreme kada je opoziv izvršen. Takva lista se mora uzeti u obzir od strane trećih strana uvek kada treba proveriti validnost sertifikata i/ili verifikaciju elektronskog potpisa.

Opoziv sertifikata – Trajno ukidanje validnosti datog sertifikata i njegovo smeštanje na CRL listu.

Repozitorijum – Baza podataka i/ili direktorijum na kome su objavljeni osnovni dokumenti rada CA, kao i eventualne druge informacije koje se odnose na pružanje sertifikacionih usluga od strane datog CA (kao na primer objavljivanje svih izdatih sertifikata…).

U ovom poglavlju je opisano na koji način se obezbeđuje sigurna komunikacija kroz računarske mreže, odnosno kako se postiže tajnost komunikacije, očuvanje integriteta i autentifikaciji učesnika u komunikaciji.

Samo učesnici u komunikaciji (pošiljalac i primalac) bi trebalo da razumeju komunikaciju u kojoj je očuvana tajnost ili poverljivost. Tajnost komunikacije postiže se šiftovanjem (enkripcijom) poruka.

Na slici 1 je prikazana opšta blok šema sistema za šifrovanje. Sistem za šifrovanje se sastoji od bloka za šifrovanje, bloka za dešifrovanje, generatora ključa i skupa poruka koje oni emituju. U bloku za šifrovanje se primenjuje matematička funkcija koja transformiše skup poruka koje se prenose u neprepoznatljiv oblik. Na ulaznu poruku, se pored same funkcije, primenjuje i ključ, koji predstavlja niz simbola čiji je zadatak da dodatno doprinese promeni izvorne poruke. Ključ je nezavisan od izvorne poruke i od same funkcije i generiše se u generatoru ključa. Ovako izmenjena poruka se potom šalje preko nesigurnog telekomunikacionog kanala ka odredištu. Poruku u kanalu može presresti prisluškivač u cilju dobijanja koristi bilo kroz samu informaciju koju poruka sadrži ili kroz izmenu poslatih podataka.

Slika 1 Opšta blok šema sistema za šifrovanje

Sistemi za šifrovanje sa simetričnim ključevima (algoritmi simetrične kriptografije) predstavljaju sisteme kod kojih se ključ za šifrovanje može lako odrediti iz ključa za dešifrovanje, i obrnuto. Najčešće su ova dva ključa ista pa je neophodno da se pošiljalac i primalac unapred dogovore o vrednosti ključeva koji će se koristiti za enkripciju/dekripciju podataka. Mehanizam za distribuciju deljenih tajnih ključeva (sinonimi su još simetrični ključevi, privatni ključevi) nije trivijalan problem.

Algoritmi simetrične kriptografije obezbeđuju tajnost komunikacije, ali ne omogućavaju ni proveru integriteta poruka ni autentifikaciju.

Rešavanje problema skalabilnosti i distribucije ključeva ) između učesnika u komunikaciji dovelo je do pojave sistema sa asimetričnim ključevima (algoritmi asimetrične kriptografije). U ovim sistemima svaka strana poseduje par ključeva, privatni i javni ključ, od kojih se jedan koristi za šifrovanje a drugi za dešifrovanje podataka. Privatni ključ je tajni i poseduje ga samo njegov vlasnik, dok je javni ključ dostupan svima. Ovi ključevi se generišu tako da iako su matematički povezani, računarski je neisplativo (u razumnom vremenskom periodu) pronalaženje privatnog ključa iz poznatog javnog. Privatni ključ se nikada ne transportuju nesigurnim kanalom.

Korišćenje sistema sa asimetričnim ključevima obezbeđuje ne samo poverljivost podataka i tajnost komunikacije, već i autentifikaciju pošiljaoca.

Poverljivost podataka se obezbeđuje tako što pošiljalac vrši enkripciju koristeći javni ključ primaoca. Na taj način samo onaj kome je poruka namenjena može da je dešifruje jer samo on poseduje odgovarajući privatni ključ.

Kako bi se obezbedila autentifikacija, pošiljalac vrši enkripciju podataka koje šalje svojim privatnim ključem. Kada primalac primi poruku, vrši njenu dekripciju javnim ključem pošiljaoca. Na taj način primalac je siguran da je poruku poslao samo onaj ko ima odgovarajući privatni ključ. Ovaj postupak leži u osnovi digitalnog potpisa.

Kombinovanjem sistema za šifrovanje sa simetričnim i asimetričnim ključevima na odgovarajući način, dobijaju se kombinovani sistemi za šifrovanje koji objedinjuje njihove najbolje osobine. Algoritmi simetrične kriptografije su jednostavniji pa omogućavaju veće brzine rada koristeći ključeve manjih veličina dok se skalabilnost i distribucija ključeva realizuju korišćenjem algoritama asimetrične kriptografije.

Na slici 2 je prikazana blok šema kombinovanog sistema za šifrovanje.

Slika 2 Blok šema kombinovanih sistema za šifrovanje

Napomena: Jedan od prvih sistema koji se bazira na ovoj ideji je sistem Diffie i Hellmana koji omogućava korisnicama (koji nisu imali prethodni kontakt) generisanje simetričnog ključa preko nesigurnog kanala. Na bazi rada Diffie i Helmana pojavili su se i drugi sistemi kao što su RSA, ElGamal, Cramer-Shoup.

Primalac mora biti siguran da je primljena poruka upravno onakva kakva je bila poslata. To utvrđuje proverom integriteta poruke. Jednosmetna heš funkcija je kriptografska tehnika koja se koristi u svrhu provere integiteta poruke i kao gradivna celina čini deo mnogih sigurnosnih protokola. Nije potrebno imati ključ da bi se heš funkcija primenila na neki podatak, te tako bilo ko može da proveri heš funkciju, a samim tim i integritet tog podatka. Kada se heš funkcija primeni na poruku uz upotrebu ključa, nastaje kod za potvrdu poruke - MAC kod.

Primenom kriptografske heš funkcije (one-way hash function) na proizvoljan blok podataka dobija se niz bita fiksne dužine koji se naziva heš vrednost poruke (hash value, message digest, digest). Osnovna karakteristika heš funkcije je da i najmanja promena u originalnoj poruci dovodi do promene njene heš vrednosti.

Idealna kriptografska heš funkcija treba da poseduje sledeće karakteristike: - izračunavanje heš vrednosti neke poruke je jednostavno, - nemoguće je (u konačnom broju koraka) pronaći poruku koja ima datu heš vrednost, - nemoguće je (u konačnom broju koraka) promeniti poruku a da ne dođe do promene i njene heš vrednosti, - nemoguće je (u konačnom broju koraka) pronaći dve različite poruke koje imaju istu heš vrednost.

Kriptografske heš funkcije se koriste kako bi se potvrdio integritet podataka koji se prenose nesigurnim kanalom, kako i za generisanje novih ključeva za enkripciju na osnovu vrednosti početnog ključa.

U tabeli 1 je data lista heš funkcija koje su u upotrebi, i (uz naziv algoritma navedene su dužine njihovih heš vrednosti.

Tabela 1 Heš funkcije

MAC (Message Authentication Code) kod ili kod za potvrdu poruke u osnovi ima sve osobine jednosmerne hash funkcija, uz dodatak tajnog ključa. MAC predstavlja niz bita koji se dobija tako što se na poruku i tajni ključ, koji poseduju obe strane u komunikaciji, primeni MAC algoritam. Upotreba ključa omogućava da samo onaj ko ima identičan ključ može proveriti heš funkciju. Zato se MAC vrednost dodaje na originalnu poruku/datoteku ne samo kako bi se potvrdio integritet poruke u komunikaciji između različitih učesnika, već i za potvrdu autentičnosti datoteke od strane samog vlasnika (ako vlasnik želi da bude siguran da datoteka nije izmenjena usled napada, aktivnosti virusa i sl).

Postoje dve kategorije MAC koda: - HMAC (Hash-based Message Authentication Code) – nastaje kada se primeni neki od poznatih heš algoritama u realizaciji MAC algoritma (HMAC-MD5, HMAC-SHA1), - CMAC (Cipher-based Message Authentication Code) – nastaje kada se primeni algoritam za simetrično šifrovanje (block encription algorithm - a symmetric block cipher in a cipher block chaining mode)).

Jednosmerne heš funkcije i MAC kod obezbeđuju proveru integriteta podatka/poruke, ali ne omogućavaju autentifikaciju pošiljaoca poruke.

Ako primalac želi da bude siguran u to da ne samo da nije došlo do izmene originalnog sadržaja poruke, već i da onaj ko je poslao poruku kasnije ne može da tvrdi da je nije poslao ili da je neko drugi poslao umesto njega, poruka mora biti potpisana digitalnim popisom pošiljaoca.

Autentifikacija (sa neporecivošču) obezbeđuje da su učesnici u komunikaciju upravo oni koji tvrde da su to. Algoritmi za šifrovanje sa asimetričnim ključem mogu obezbediti proveru integriteta i ideniteta (autentifikaciju) upotrebom digitalnih potpisa. Digitalni potpis elektronskih podataka može da se posmatra u analogiji sa potpisom ili pečatom štampanih dokumenta. On omogućava da primalac poruke bude siguran da nije došlo do izmene originalnog sadržaja poruke, kao i da bude siguran u identitet pošiljaoca poruke. Drugim rečima, garantuje integritet poruke i identit/autentifikaciju pošiljaoca iste. Pored toga, digitalni potpis ne može da se porekne, tako da onaj ko je poslao poruku kasnije ne može da tvrdi da je nije poslao ili da je neko drugi poslao umesto njega.

Digitalni potpis poruke se formira korišćenjem tehnike asimetričnih ključeva. Pošiljalac kreira heš (šifrovani sažetak poruke) tako što na originalnu poruku primenjuje heš algoritam. Heš poruke predstavlja „digitalni otisak prsta“ poruke. Ako bi došlo do najmanje promene u originalnoj poruci, promenio bi se i rezultujuću heš poruke. Pošiljalac zatim vrši enkripciju heša svojim privatnim ključem. Ovako enkriptovan heš predstavlja digitalni potpis poruke.

Pošiljalac dodaje na kraj originalne poruke i njen digitalni potpis i tako digitalno potpisanu poruku šalje. Na prijemu, primalac pomoću javnog ključa pošiljaoca vrši dešifrovanje digitalnog potpisa poruke kako bi dobio heš poslate poruke i poredi ga sa vrednošću heša koji on dobija primenjujući isti heš algoritam na samu primljenu poruku. Ako se dobijene heš vrednosti ne razlikuju primalac može da bude siguran da poruka nije izmenjena. Ako se vrednosti razlikuju znači da je došlo do neovlašćenog menjanja sadržaja poruke i/ili da je neko drugi poslao poruku od onog za koga se izdaje.

Na slici 3 je prikazana blok šema sistema sa digitalnim potpisom.

Slika 3 Blok šema sistema sa digitalnim potpisom

Digitalni sertifikati (Public Key Certificate - PKC) omogućavaju potvrdu identiteta učesnika u elektronskoj komunikaciji, slično kao što to čine lične karte u međuljudskim interakcijama. On povezuje podatke o identitetu učesnika u komunikaciji sa parom asimetričnih ključeva koji se koriste za enkripciju i potpisivanje digitalne informacije čime potvrđuje nečije pravo na korišćenje para kriptografskih ključeva. Dakle, potvrđuje da određeni javni ključ pripada određenom krajnjem entitetu (krajnjem korisniku, ali i korisničkom serveru). Na taj način se sprečava zloupotreba ključeva i da se neko neovlašćeno predstavlja tuđim identitetom.

Digitalne sertifikate mogu izdavati i digitalno potpivati samo sertifikaciona tela CA čiji je autoritet nesporan i takav da mu veruju svi učesnici u komunikaciji.

Digitalni sartifikat sadrži podatke o vlasniku/krajnjem entitetu sertifikata, javni ključ vlasnika/krajnjeg entiteta sertifikata, period važenja sertifikta, ime izdavača (sertifikaciono telo koje je izdalo sertifikat), serijski broj sertifikta, digitalni potpis izdavača.

Najčešće korišćen format digitalnog sertifikata je definisan ITU-T X.509 standardom, verzija 3. Može se čuvati odvojeno od privatnog ključa (PEM format), ili se može čuvati spojen sa privatnim ključem u različitim formatima (npr. PKCS #12, JKS, …).

Pri slanju poruke pošiljalac digitalno potpisuje poruku i uz nju šalje i svoj digitalni sertifikat kako bi primalac mogao da bude siguran u identitet pošiljaoca. Uz poruku može da bude poslato i više digitalnih sertifikata koji formiraju lanac sertifikata, odnosno hijerarhijski lanac poverenja, gde jedan digitalni sertifikat potvrđuje autentičnost prethodnog digitalnog sertifikata. Na samom vrhu u hijerarhiji poverenja nalazi se root (top-level) sertifikaciono telo tzv. koreno sertifikaciono telo, kome veruju sva ostala sertifikaciona tela. Javni ključ root sertifikacionog tela mora da bude javno poznat i dostupan. U Prilogu # je prikazan jedan takav lanac poverenja uspostavljen na realnom primeru lanca CA sertifikata za TCS servis.

Na slici 4 je prikazana blok šema sistema sa digitalnim sertifikatima.

Slika 4 Blok šema sistema sa digitalnim sertifikatima

Infrastruktura javnih ključeva PKI standardizovana je standardom ITU-T X.509. Prati ga IETF dokument RFC 5280, u kome su definisane jasnije preporuke za internet zajednicu.

U ovom poglavlju su opisane komponente PKI infrastrukture, ali i način realizacije PKI funkcija na primeru uključivanja AMRESa u TCS (TERENA Certificate Service) servis. Navedene su i različite potrebe za korištenjem PKI u NRENu, koje zahtevaju različite tipove digitalnih sertifikata, ali je posebna pažnja posvećena je korištenju PKI infrastrukture, odnosno digitalnih sertifikata u kombinaciji sa SSL tehnologijom u svrhu međusobne autentifikacije servisa i njihovih korisnika.

Infrastrukturu javnih ključeva čine hardver, softver, polise i procedure koje su neophodne za upravljanje, generisanje, skladištenje, distribuciju, korištenje i povlačenje kriptografskih ključeva i digitalnih sertifikata.

Na slici # je prikazana međusobna povezanost osnovnih PKI elemenata.

Slika # Međusobne veze PKI elemenata

Upravljanje, generisanje, skladištenje i distribucija kriptografskih ključeva i digitalnih sertifikata se odvija kroz Sertifikaciona (CA) i Registarciona (RA) tela.

Učesnici u komunikaciji, koji međusobno nemaju uspostavljen lanac poverenja, veruju trećoj strani - Sertifikacionom telu CA. CA kao autoritativno telo kome se veruje, ima kapacitet da izdaje i povlači digitalne sertifikate (Public Key Cetrificate - PKC). CA funkcioniše na sledeći način. CA, pre izdavanja sertifikata, vrši potpunu proveru podataka o vlasniku/krajnjem entitetu za koga je podnet zahtev za izdavanje sertifikata. Ove provere CA može da vrši direktno ili posredstvom jednog ili više RA. Posle uspešne provere, CA izdaje digitalni sertifikat njegovom vlasniku/krajnjem entitetu. Izdati sertifikat garantuje da javni ključ pripada tom vlasniku/krajnjem entitetu. Krajnji entite može biti krajnji korisnik (fizičko lice) ili server, a digitalni sertifikat može da veže javni ključ za identitet ili DNS-zapis krajnjeg entiteta. Digitalni sertifikat izdat krajnjem korisniku garantuje njegov identitet, a potpisan je digitalnim sertifikatom samog Sertifikacionog tela. Krajnji korisnici sada koriste svoje digitalne sertifikate, izdate od strane Sertifikacionog tela kome veruju, kako bi dokazali svoj identitet jedan drugom i uspostavili sigurnu komunikaciju.

Digitalni sertifikati se izdaju i fizičkim i pravnim licima. Fizičkim licima (krajnjim korisnicima) se izdaju lični sertifikati (personal PKC). Pravnim licima tj. institucijama se izdaju serifikati za krajnje entitete u njihovom vlasništvu, a to su najčešće (serverski SSL sertifikati) korisnički serveri (web, mail, radius i sl.).

Inicijalna registracija, proces prijavljivanje institucija/korisnika. Da bi koristili usluge infrastrukture javnih ključeva, institucije/krajnji korisnici prvo moraju da prođu proces prijavljivanja koji obuhvata proveru njihovog identiteta i razmenu informacija sa za to zaduženom komponentom infrastrukture javnim Registracionim telom (RA).

Prvi korak u procesu prijavljivanja je registracija, koja podrazumeva proveru identiteta krajnjeg entita koji podnosi zahev za sertifikat. Registracija za krajnjeg korisnika znači proveru identiteta krajnjeg korisnika koji podnosi zahtev za sertifikatom. U slučaju institucija, to nije sama institucija, već najčešće njeni korisnički serveri. Zato za institucije postoji faza predregistracije u kojoj se proveravaju podatci o instituciji i dostavljaju se imena osoba (u proceduri imenovanja predstavnika institucije) koji će dalje vršiti registraciju krajnjih entiteta/servera za potrebe te institucije. Registracija za krajnji entitet u instituciji znači proveru identiteta servera za koji se podnosti zahtev za sertifikatom. Nivo provere identiteta zavisi od tipa sertifikata za koji se podnosi zahtev (sertifikata koji se koriste pri elektronskoj kupovini zahtevaju stroži nivo provere od ostalih tipova serifikata) i za svaki tip sertifikata je definisan odgovarajućim dokumentom koji se naziva politika sertifikacije.

Inicijalizacija je sledeći korak u registraciji u okviru koga predstavnik institucije/krajnji korisnik i sertifikaciono telo razmenjuju neophodne informacije za dalju komunikaciju: kako će se odvijati sama komunikacija, kako će se distribuirati sertifikati, na koji način se uspostavlja sigurna komunikacija između predstavnika institucije/krajnjih korisnika i sertifikacionog tela, kako se generiše i dostavlja par asimetričnih ključeva itd.

Serifikacija. Sertifikacija obuhvata proces izdavanja i dostavljanja sertifikata predstavnicima institucija/krajnjim korisnicima i obavlja je CA.

Opoziv sertifikata. Iako je period važenja digitalnog sertifikata definisan datumima u odgovarajućim polja samog sertifikata dešava se da dođe do kompromitovanja tajnog ključa ili promene nekog od osnovnih ličnih podataka koji se nalaze u sertifikatu što ima za posledicu opozivanje sertifikata, odnosno njegovo povlačenje iz upotrebe. Opozvani sertifikati se objavljuju preko lista opozvanih sertifikata (Certificate Revocation List - CRLItalic Text) koje objavljuje sertifikaciono telo koje je izdalo sertifikat. Koristeći Repozitorijum – bazu podataka i/ili direktorijum sa osnovnim dokumentima rada CA, CA objavljuje i eventualne druge informacije koje se odnose na pružanje sertifikacionih usluga od strane datog CA (kao na primer objavljivanje svih izdatih sertifikata, …).

U nekim slučajevima, umesto lista opozvanih sertifikata, se koriste protokoli za proveru stanja sertifikata u realnom vremenu koji daju pozitivan ili negativan odgovor o statusu sertifikata. Primer takvog protokola je OCSP – Online Certificate Status Protocol.

Primalac sertifikata je svakako dužan da proveri sertifikat, pre nego što ga prihvati. Provere sertifikata nije jednostavan proces, jer potpisnik poruke može umjesto jednog vlastitog sertifikati dati lanac certifikata, u kome je svaki sertifikat potpisan sertifikatom nadređenog CA. To podrazumeva proveru lanca poverenja i validnosti svakog sertifikata u tom lancu.

Provera lanca poverenja. Provera sertifikata za svaki pojedinačni sertifikat mora da odgovori na sledeća pitanja: Da li postoji poverenja u dati sertifikat? Da li je sertifikat doista potpisan od strane određeno CA? Ako primalac sertifikata nema poverenje u prvi sertifikat u lancu, mora preći na proveru sledećeg sertifikata u lancu (odnosno sertifikata CA koji ga je potpisao). Proces se nastavlja sve dok primalac, u lancu sertifikata ne pronađe sertifikat u koji ima poverenja. U Prilogu # je prikazan lanac poverenja uspostavljen na realnom primeru lanca CA sertifikata za TCS servis.

Provera validnosti sertifikata. Provera sertifikata za svaki pojedinačni sertifikat mora da odgovori i na pitanja Da li sertifikat istekao? Da li je sertifikat važeći ili je opozvan? Kao što je već gore pomenuto, nevažeći (opozvani sertifikati) se objavljuju preko lista opozvanih sertifikata ili se koriste protokoli za proveru stanja sertifikata. Svaki sertifikat sadrži polje koje označava period njegovo važenja (Validity) i pokazuje da li je sertifikat istekao. Sertifikati se obično izdaju na 1 do 2 godine.

Standardni formati za digitalne sertifikate (PKC), listu opozvanih sertifikata (CRL) i sadržaj/atribute (attributes) sertifikata su specificirani u ITU-T X.509 strandardu. Danas se najčešće koristiji verzija 3.

Prema preporukama IETF RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) digitalni sertifikat treba da sadrži sledeća polja (vidi sliku #):

• Version - informacija o verziji sertifikata. Trenutna verzija (i ona koja se najčešće koristi) je 3.
  
• Serial number – serijski broj sertifikata predstavlja jedinstveni identifikator sertifikata izdatih od određenog sertifikacionog tela.
  
• Signature - identifikator u OID (identifikator objekta) formatu. Identifikuje algoritam koji je sertifikaciono telo koristilo za potpisivanje sertifikata.
  
• Issuer - jedinstveno ime sertifikacionog tela koje je izdalo sertifikat. Daje se u formatu jedinstvenog imena (Distinguishing name - DN)
  
• Validity - označava period važenja sertifikata i sadrži dva datuma od kojih jedan označava trenutak od kada se sertifikat može smatrati važećim (polje Not Valid Before), a drugi, trenutak do kog se sertifikat može smatrati važećim (polje Not Valid After).
  
• Subject - identifikuje #korisnika/entitet kome je izdat sertifikat. Kao i polje Issuer, daje se u formatu jedinstvenog imena (Distinguishing name - DN) entiteta, npr. #“C=RS,O=AC.BG,OU=RCUB,CN=Ivan Ivanovic”.
  
• Subject public key info - sadrži javni ključ korisnika/entiteta, kao i identifikaciju algoritma koji je korišćen pri kreiranju istog (RSA, DSA, Diffie-Hellman i slično).
  
• Unique identifiers dodatni identifikator sertifikata čija se upotreba ne preporučuje u verzijama 2 i 3.
  
• Extensions - sadrži listu jednog ili više proširenja sertifikata koja se koriste za specificiranje dodatnih informacija o sertifikatu. Svaki član liste sadrži informaciju o tipu proširenja, oznaku kritičnosti proširenja i sadržaj proširenja. Kada korisnički softver, prilikom procesiranja, ne ume da prepozna proširenje, ako je ono označeno kao kritično proširenje, sertifikat će biti označen kao nevažeći. (ako je proširenje označeno kao nekritično, moguće je ignorisati dato proširenje i uvažiti ponuđeni sertifikat). Proširenja koja su u upotrebi pripadaju sledećim kategorijama:
  
  • Standardna proširenja:
    
    • Authority key identifier - AKI - omogućava identifikovanje javnog ključa koji odgovara privatnom ključu sertifikacionog tela kojim je potpisan sertifikat. Obično se koristi ako sertifikaciono telo ima više od jednog ključa za potpisivanje.
      
    • Subject key identifier - SKI - jedinstveni identifikator koji se koristi se za identifikovanje sertifikata koji sadrže odgovarajući javni ključ.
      
    • Key usage - definiše namenu ključa sadržanog u konkretnom sertifikatu, tj. da li on može da se koristi za potpisivanje, za šifrovanje, za verifikaciju lista opozvanih sertifikata i sl.
      
    • Certificate policies - sadrži listu identifikatora politika sertifikacije (datih u OID formi identfikatora objekta) i dodatnih opcionih tekstualnih parametara koji svedoče da je konkretan sertifikat izdat pod odgovarajućim skupom pravila objedinjenih u naznačenim politikama sertifikacije. Opcioni parametri su Certification Practice Statement pointer (definiše lokaciju na kojoj mogu da se pronađu Praktična pravila rada Sertifikacionog tela) i User notice (sadrži tekst poruke za krajnjeg korisnika).
      
    • Policy mappings - koristi se u sertifikatima sertifikacionih tela iz različitih administrativnih domena da označi skup parova politika sertifikacije koje se smatraju ekvivalentnim. Par politika sertifikacije, koji se želi specificirati u ovom proširenju, navodi se u poljima Issuer domain policy i Subject domain policy.
      
    • Subject alternative name - sadrži dodatne podatke o subjektu sertifikacije (npr. njegov email, URL, IP adresu i sl.).
      
    • Issuer alternative name - sadrži dodatne podatke o sertifikacionom telu koje je izdalo sertifikat (npr. email, URI, IP adresu i sl.).
      
    • Subject directory attributes - daje dodatne informacije o predmetu sertifikovanja (npr. nacionalnost) i nije od velikog značaja.
      
    • Basic constraints - govori da li je predmet sertifikacije sertifikaciono telo ili krajnji korisnik/entitet. Za sertifkaciono telo, proširenje može da sadrži i parametar Path length (pokazuje broj sertifikata sertifikacionih tela koje mogu da ga slede).
      
    • Name constraints - koristi se samo u sertifikatima sertifikacionih tela i definiše prostor imena dat u formi stabla dozvoljenih/zabranjenih imena (Permitted subtrees and/or Excluded subtrees), kome moraju/ne smeju da pripadaju tipovi imena u sertifikatima krajnjih korisnika izdatih od strane istih sertifikacionih tela.
      
    • Policy constraints - koristi se u sertifikatima sertifikacionih tela da zabrani preslikavanje politika sertifikacije ili da označi neophodnost pojavljivanja određene politike sertifikacije u svim sertifikatima koji se provaravaju nakon ovog (sartifikata sa ovim proširenjem). Prisustvo polja inhibitPolicyMapping sugeriše da je nakon određenog broja (definisanog vrednošću ovog polja) sertifikata zabranjeno preslikavanje politika sertifikacije, dok prisustvo polja Require explicit policy sugeriše upotrebu određene politike sertifikovanja u određenom broju (definisanom ovom vrednošću) narednih sertifikata.
      
    • Extended key usage - koristi se u sertifikatima krajnjih korisnika/entiteta da označi dodatne mogućnosti upotrebe ključa (pored onih koje su definisane u proširenju Key usage).
      
    • CRL distribution points - ukazuje na lokacije na kojima se nalazi lista opozvanih sertifikata.
      
    • Inhibit anyPolicy - koristi se u sertifikatima sertifikacionih tela da definiše odnos prema specijalnoj vrednosti politike sertifikacije anyPolicy (koja označava mogućnost upotrebe bilo koje politike sertifacije) u narednim sertifikacionim telima. Vrednost označava broj dodatih sertifikata koji se mogu pojaviti u lancu pre nego što anyPolicy više nije dozvoljena, odnosno broj sertifikacionih tela posle ovog, nakon koga se anyPolicy se ne smatra važećom za uparivanje sa nekom drugom konkretnom politikom.
      
    • Freshest CRL pointer - predstavlja pokazivač na „najsvežije“ informacije vezane za opozvane sertifikate. U praksi, ovo je najčešće pokazivač na Delta listu opozvanih sertifikata.
      
  • Privatna proširenja se definišu prilikom korišćenja sertifikata u specifičnim oblastima. Tako, na primer, RFC5280 specificira dva proširenja ove vrste za primenu na Internetu:
    
    • Authority information access - definiše način pristupa uslugama (i informacijama) koje pruža sertifikaciono telo izdavalac sertifikata (npr. o usluzi za online proveru ispravnosti sertifikata, dodatnim informacijama o politici sertifikovanja…).
      
    • Subject information access - definiše način pristupa uslugama (i informacijama) koje pruža predmet sertifikovanja (npr. mesto skladištenja sertifikata kad je reč sertifikacionom telu kao predmetu sertifikovanja).

Primeri formata i realan sadržaj polja digitalnog sertifikata se mogu naći u Prilogu #, u kome je pokazan lanac CA sertifikata za TCS servis.

Digitalni sertifikat se može čuvati u PEM formatu odvojeno od privatnog ključa, ili se može čuvati spojen sa privatnim ključem u različitim formatima (npr. PKCS #12, JKS, …).

Najčešće korišćene fajl ekstenzije za X.509 sertifikate su:

• .CER, .CRT, .DER – DER (Distinguished Encoding Rules) format, najčešće u binarnoj formi, ali može da bude i Base64.
  
• .PEM - Base64 kodirani DER sertifikat, smešten između ”—–BEGIN CERTIFICATE—–” i ”—–END CERTIFICATE—–“
  
• .P7B - videti .P7C
  
• .P7C - PKCS #7 format, sadrži samo sertifikat (jedan ili više), a može da se koristi za CRL
  
• .PFX - videti p12
  
• .P12 - PKCS #12 format, sadrži sertifikat i odgovarajući privatni ključ (zaštićen je šifrom)
  
• .CSR – PKCS #10 format, sadrži zahtev za dobijanje sertifikata (CSR)

Za zaštitu komunikacije između određenog klijenta i servera npr. web klijenta (web pretraživača) i web servera, načešče se koristi SSL (Secure Sockets Layer) protokol, odnosno njegova standardizovana verzija TLS (Transport Layer Security). SSL protokol je smišljen u Netscapu, ali je standardizovan u IETF-u pod nazivom Transport Layer Security (TLS). Naziv SSL se zadržao, pa ćemo ga i mi češće koristiti. SSL može biti ugrađen u softverski paket (npr. Microsoft Explorer pretraživač dolazi sa ugrađenim SSL protokolom i većina web servera ima implementiran protokol). Alternativno SSL/TLS može biti instaliran kao deo TCP/IP protokol steka i tako transparentan za aplikativni nivo.

SSL (Secure Sockets Layer) protokol funkcioniše po klijent-server modelu. Klijent je strana koja inicira sigurnu komunikaciju, dok server odgovara na zahtev klijenta. Najčešći primer korišćenja SSL protokola je https koji predstavlja sigurnu verziju http-a (secure http) i koristi se za uspostavu zaštićene veze sa nekim web serverom, najčešće za potrebe elektronskog plaćanja. U tom slučajum, web pretraživač predstavlja SSL klijenta, a web server, odnosno sajt kome se pristupa, je SSL server.

Sa stanovišta SSL protokola, ono što pravi razliku između klijenta i servera su akcije koje oni preduzimaju prilikom pregovora oko sigurnosnih parametara. Klijent inicira komunikaciju, porukom u kojoj se nalazi i njegov predloži skup SSL opcija koje će se koristiti za uspostavu zaštićenog kanala. Server, na osnovu onoga što je klijent ponudio, bira skup opcija koje će se koristiti. Iako je konačna odluka na serveru, server može da bira samo iz skupa parametara koje je klijent inicijalno predložio.

U sledećoj poruci (ServerKeyExchange) server šalje informaciju o svom javnom ključu, nakon čega zaključuje svoj deo pregovora. Zatim klijent odgovara porukom u kojoj šalje ključ K, koji i klijent i server moraju koristiti za šifrovanje podataka u toku trajanja sesije. Ključ K, koji se šalje u poruci, je šifrovan javnim ključem servera, tako da jedino server može da pročita poruku i dođe do ključa K. Nakon poruke sa ključem, klijent šalje poruku kojom aktivira korišćenje zaštićene komunikacije sa dogovorenim parametrima za sve nadalje poslate poruke i slanjem poruke Finished traži od servera da proveri novoaktivirane sigurnosne opcije. Server odgovara porukom kojom aktivira korišćenje zaštićene komunikacije sa dogovorenim parametrima za sve nadalje poslate poruke i slanjem svoje Finished poruke traži od klijenta da proveri novoaktivirane sigurnosne opcije. Time je obezbeđena poverljivost komunikacije.

Da li je potreban i čemu služi digitalni sertifikat u SSL komunikaciji? Sertifikati se koriste u zaštićenoj komunikaciji kroz mrežu da autentifikuju učesnike u komunikaciji – serversku i kljentsku stranu.

Klijent, tokom iniciranja komunikacije, može zahtevati autentifikaciju servera. Na ovaj način, korisnik može da bude siguran u identitet servera sa kojim komunicira, da nije došlo do krađe identiteta, odnosno, lažnog predstavljanja od strane nekog napadača.

Ako klijent zahteva autentifikaciju servera, server umesto ServerKeyExchange porukom odgovara Certificate porukom. Certificate poruka sadrži lanac sertifikata koji počinje sa sertifikatom samog server, a završava se sertifikatom korenog sertifikacionog tela (root CA). Klijent je dužan da proveri da li može da veruje sertifikatu koji dobije od servera. To uključuje proveru lanca poverenja i provore validnosti sertifikata (vidi poglavlje #).

Nakon utvrđivanja identiteta servera, klijent nastavlja procedure kako je ranije opisano. Naravno ključ K, koji klijent šalje serveru je šifrovan javnim ključem servera koji se nalazi u sertifikatu dobijenim od servera. Ovaj put klijent je siguran da samo server koji poseduje i odgovarajući privatni ključ, može da dešifruje poruku klijenta i uspešno nastavi komunikaciju.

Da bi opisani scenario funkcionisao, server mora da ima svoj digitalni sertifikat (koji nazivamo serverski SSL sertifikat) i on mora biti instaliran na serveru.

Razmena SSL poruka prikazana je na slici #, a u tabeli # su objašnjeni odgovarajući koraci. Inače, lista svih SSL paketa nalazi se u Anex I ovog dokumenta. Razmena poruka specifična za svaki od scenarija opisanih u nastavku poglavlja nalazi se samo na adresi # u wiki verziji ovog dokumenta.

Slika # Razmena SSL poruka - učesnici u komunikaciji se međusobno autentifikuju

Nedostatak postupka autentifikacije, opisanog u predhodnom poglavlju, je u tome što se isti javni ključ servera koristi za potvrdu identiteta servera i za enkripciju ključa K koji će se koristiti za šifrovanje sadržaja komunikacije tokom trajanja sesije. U nekim slučajevima ni ne postoji odgovarajuća podrška za sprovođenje opisanog postupka, budući da se neki sigurnosni algoritmi (npr. DSA – Digital Signature Algorithm) mogu koristiti samo za digitalno potpisivanje poruke, ali ne i za enkripciju. U takvoj situaciji, nije izvodljivo da poruka sa ključem K bude šifrovana javnim ključem server koji se nalazi u sertifikatu kojim je dokazan njegov identitet.

Dakle, potrebno je razdvojiti enkripciju od autentifikacije. Tako da je server dužan da odgovori i Certificate porukom i ServerKeyExchange porukom.

Certificate poruka sadrži sertifikat servera. Javni ključ servera koji se nalazi u njegovom sertifikatu koristi se samo kako bi se potvrdio identitet servera, odnosno, izvršila njegova autentifikacija.

ServerKeyExchange poruku sadrži drugi javni ključ servera, koji klijent treba da koristi za enkripciju informacije o ključevima K koji će se koristiti za sesiju. Razlika je u tome što je informacija o drugom javnom ključu servera sada može biti potpisana privatnim ključem servera, čiji je odgovarajući javni ključ predhodno poslat sa njegovim sertifikatom. Tako klijent može da potvrdi da server zaista poseduje privatni ključ koji odgovara javnom ključu sadržanom u sertifikatu servera.

SSL sadrži mehanizme koji omogućavaju svakoj strani komunikacije da autentifikuje drugu, pa server takođe može da zahteva autentifikaciju klijenta, tokom razmene inicijalnih Hello poruka između klijenta i servera. SSL specificira da server ne može da traži autentifikaciju klijenta ukoliko se on prethodno nije autentifikovao klijentu.

Napomena: SSL koristi javni ključ klijenta samo za digitalno potpisivanje, odnosno autentifikaciju klijenta. Za razliku od slučaja sa serverom, ne postoji potreba za enkripciju korišćenjem javnog ključa klijenta.

Samo slanje Certificate poruke od strane klijenta ne obezbeđuje potpunu autentifikaciju klijenta. Klijent mora da dokaže da poseduje i odgovarajući privatni ključ. Zato, klijent šalje CertificateVerify poruku koja sadrži digitalno potpisan heš dobijen od informacije koja je poznata i klijentu i sreveru. Na taj način server može da proveri potpis i utvrdi da li klijent poseduje odgovarajući privatni ključ.

Podrazumeva se da je server dužan da proveri da li može da veruje sertifikatu koji dobije od klijenta. To uključuje proveru lanca poverenja i provore validnosti sertifikata (vidi poglavlje #).

U navedenom primeru SSL klijent je web pretraživač, a digitalni sertifikat koji mu je potreban da bi opisani scenario funkcionisao je lični korisnički sertifikat.

Prednosti korištenja PKI za autentifikaciju klijenta (krajnjih korisnika) su:

• Osetljive informacije (password ili privatni ključ) ne prenose se kroz mrežu.
• Nije potreban repozitorijum za korisničke akreditiv (credential) – postoji CA kome svi veruju.
• Autentifikacija nije centralizovan servis.

AMRES pruža bespatan PKI servis za svoje institucije članice i krajnje korisnike. Realizacija PKI servisa i procedure u vezi digitalnih sertifikata zavise od namene, odnosno od tipa sertifikata koji je potreban instituciji.

Za realizaciju izdavanja serverskih SSL sertifikata je ključno da oni moraju biti izdati od tela kome krajnji korisnici i/ili proizvođači softvera veruju, to jest tela čiji su sertifikati već ugrađeni u najpopularnije korisničke pretraživače i druge klijente putem kojih se pristupa serverima.

AMRES je u saradnji sa TERENA-om (The Trans-European Research and Education Networking Association) uspostavio servis izdavanja serverskih sertifikata, čiji se lanac certifikata završava potpisom Comodo CA Limited, jednim od trenutno najvećih svetskih CA. Za uspostavljeni servis koristi se naziv TCS servis.

U Prilogu # je prikazan lanac poverenja uspostavljen na realnom primeru lanca CA sertifikata za TCS servis. Sertifikat TERENA SSL CA kojim se potpisuju svi serverski sertifikati za krajnje institucije je potpisan od strane UserTrust, prelaznog sertifikacionog tela koje je potpisano od strane AddTrust External root sertifikacionog tela. Taj root sertifikat je preinstaliran u većini SSL klijenata (na primer, prilikom pristupanja sajtu preko https-a, koji se nalazi na web serveru koji ima TERENA sertifikat, nije potrebna intervencija korisnika kako bi sertifikat bio prihvaćen jer se odgovarajući Root CA sertifikat već nalazi preinstaliran u većini često korišćenih web browser-a: Internet Explorer, Mozilla Firefox, Google Chrome, Opera).

TERENA ima ulogu sertifikacionog tela, a AMRES registracionog tela. Pravo na korišćenje SSL sertifikata za potrebe svojih servera i servisa imaju sve AMRES članice (naučno-istraživačke i obrazovne institucije u Srbiji) koje prethodno prođu kroz proces registracije (poglavlje #5).

U nacionalnim istraživačkim i obrazovnim mrežama identifikovana je potreba istraživačih i akademskih institucijama za različitim vrstama digitalnih sertifikata, a to su:

• Serverski SSL sertifikati (Server Certificate) – za autentifikaciju servera i uspostavljanje sigurne sesije sa krajnjim korisnicima (end clients). Ovi sertifikati mogu da se koriste na svim serverima koji nisu deo GRID infrastukture.
• e-Istraživački serverski sertifikati (e-Science Server Certificate) – za autentifikaciju GRID hostova i servisa. Cilj je da oni budu IGTF akreditovani.
• Lični korisnički sertifikati (Personal Certificate) – za autentifikaciju odnosno identifikaciju krajnjih korisnika i zaštitu e-mail korespondencije.
• e-Istraživački lični sertifikati (e-Science Personal Certificate) – za autentifikaciju odnosno identifikaciju krajnjih korisnika prilikom pristupa Grid servisima. Namera je da budu IGTF akreditovani.
• Sertifikati za potpisivanje koda (Code-signing sertifikati) – za autentifikaciju softvera koji se distribuira preko Interneta.

Severski SSL sertifikati raspoloživi su za institucije članice AMRESa preko TCS servisa, a planirano je da se i lični korisnički sertifikati obezbede uskoro na ovaj način. Politika sertifikacije propisuje da se serverski SSL sertifikati ne mogu se koristiti za zaštitu online finansijskih transakcija. Za pomenuti servis potrebne su EV (Extended Validation) sertifikati za čije izdavanje je temeljitiji proces provere nego za druge sertifikate.

Izdavanje e-Istraživačkih tipovi sertifikata (serverskih i ličnih) za zaštitu GRID instalacija i pristupa njima je uspostavljeno kroz AEGIS CA. AEGIS CA je formiran da bi pružio PKI servis za GRID istraživačku zajednicu u Srbiji. AEGIS politika je objavljena u dokumentu http://aegis-ca.rcub.bg.ac.rs/documents/AEGIS-CP-CPSv1-2.doc, koji sadrži i Praktična pravila rada AEGIS CA.

Sertifikati za autentifikaciju softvera nisu trenutno dostupni.

Preporuka je da se serverskim SSL sertifikatima treba obezbediti pristup svim korisničkim serverima – pre svega mail serverima. Ali tu takođe dolaze u obzir i server kojima korisnici prilikom pristupa primorani da daju na uvid korisnička imena, password i druge ostljive podatke, npr. servisi sa web interfejsom, radius server i sl. Kada je reč o radius server, misli se na autentifikaciju radius server (Identitet Provajdera IDP) za svoje korisničke računare (ovo je ostavljeno na odlučivanje pojedinačnim eduroam institucijama.)

Pribavljanje sertifikata za servere u institucijama se svodi na pripremu zahteva za potpisivanje serverskog sertifikata i njegovo upućivanje na adresu tcs@amres.bg.ac.rs. U pripremi zahteva potrebno je slediti sledeće korake (od kojih su neki proceduralni, a drugi tehnički):

1. Registracija institucije
2. Kreiranje para asimetričnih ključava
3. Kreiranje zahteva za potpisivanje serverskog sertifikata (CSR - Certificate Signing Request)
4. Podnošenje CSR zahteva

Registracija institucije je administrativni korak, kojim institucija stiče pravo na podnošenje CSR zahteva. U procesu registracije, AMRES u svojstvu RA za TCS servis, proverava podatke o instituciji, a institucija imenuje svoje ovlaštene predstavnike za poslove dobijanja serverskih sertifikata. Registracija podrazumeva popunjavanje dokumenta u kome se imenuje ovlašteni predstavnici (administrativni kontakti) koji će zastupati instituciju u postupcima zahtevanja, opozivanja, obnavljanja i dobijanja serverskih sertifikata. Imenuje se najmanje jedan, a najviše tri ovlašćena predstavnika. Takođe je potrebno da se institucija prihvati ugovor (subscriber agreement) o korištenju servisa. Svi detalji se nalaze na AMRES sajtu #.

Ugovor i dokument u kome su navedeni ovlašćeni predstavnici se šalju potpisani od strane ovlašćene osobe institucije i overeni pečatom institucije na adresu AMRES, Kumanovska bb, Beograd.

Posle provere podataka od strane AMRES-a, navedene ovlašćene osobe će mejlom biti obaveštene o rezultatu registracije.

Po uspešnoj registraciji, institucija, kao korisnik servisa, putem ovlašćenih predstavnika ostvaruje pravo na podnošenje zahteva i dobijanje serverskih sertifikata.

U ovom koraku se generišu privatni i javni ključ koji će se koristiti prilikom sigurnih transakcija i za formiranje serverskog sertifikata kao i zahtev za potpisivanje sertifikata.

U nastavku je dato objašnjenje za kreiranje zahteva korišćenjem OpenSSL alata (za upotrebu sa Apache/mod_ssl serverom) na Linux-u, a uputstva za druge serverske platforme možete naći na adresi http://www.instantssl.com/ssl-certificate-support/csr_generation/ssl-certificate-index.html.

Sertifikat može da sadrži jednu ili više FQDN imena (maksimalno 100). Sertifikat sa više FQDN imena se koristi u slučaju da se na jednom serveru (jednoj IP adresi) nalazi više servisa sa različitim simboličkim adresama. Na primer, ako se više različitih web sajtova hostuje na jednom web serveru a različita FQDN imena sajtova se mapiraju u istu IP adresu servera, umesto da se na serveru nalaze posebni serverski sertifikati za svaki web sajt, moguće je da postoji samo jedan sertifikat koji bi važio za više FQDN imena.

U zavisnosti od toga da li sertifikat sadrži jedno ili više FQDN imena, mogu da se koriste dva predefinisana OpenSSL konfiguraciona fajla, SCSreq.cnf i MultiSCSreq.cnf. Samo jedan od njih se navodi u pozivu OpenSSL-a za kreiranje CSR zahteva. Ako se kreira zahtev za sertifikatom koji sadrži jedno FQDN ime servera, onda se poziva SCSreq.cnf, a u slučaju kreiranja zahteva sa više FQDN imena, poziva se MultiSCSreq.cnf.

Odgovarajući konfiguracioni fajl je potrebno prebaciti na server ili kopirati sdržaj konfiguracionog fajla u tekstualni fajl na serveru i sačuvati ga pod odgovarajućim imenom (SCSreq.cnf ili MultiSCSreq.cnf).

SCSreq.cnf – konfiguracioni fajl koji se poziva kada se kreira zahtev za sertifikatom koji sadrži jedno FQDN ime:

[ req ]
default_bits           = 2048
default_keyfile        = keyfile.pem
distinguished_name     = req_distinguished_name
#attributes             = req_attributes
#prompt                 = no
#output_password        = mypass
encrypt_key = no

[ req_distinguished_name ]
countryName                    = Oznaka zemlje (2 znaka)
countryName_default            = RS
countryName_min                = 2
countryName_max                = 2

localityName                   = Naziv lokacije (grad)

organizationName                = Pun naziv institucije
organizationName_default        = University of Belgrade

organizationalUnitName         = Naziv organizacione jedinice
organizationalUnitName_default  = RCUB

commonName                    = FQDN adresa servera
commonName_max                = 64

MultiSCSreq.cnf – konfiguracioni fajl koji se poziva kada se kreira zahtev za sertifikatom koji sadrži više od jednog FQDN imena:

[ req ]
default_bits           = 2048
default_keyfile        = keyfile.pem
distinguished_name     = req_distinguished_name
encrypt_key            = no
req_extensions         = v3_req

[ req_distinguished_name ]
countryName                     = Oznaka zemlje (2 znaka)
countryName_default             = RS
countryName_min                 = 2
countryName_max                 = 2
 
localityName                    = Naziv lokacije (grad)

organizationName                = Pun naziv institucije
organizationName_default        = University of Belgrade

organizationalUnitName          = Naziv organizacione jedinice
organizationalUnitName_default  = RCUB

0.commonName                    = FQDN adresa servera
0.commonName_max                = 64

[ v3_req ]
subjectAltName                  = @alt_names

[ alt_names ]
DNS.1                           = 
DNS.2                	        = 
DNS.3                	        =

U slučaju generisanja zahteva za sertifikatom koji sadrži više od jednog FQDN imena, u konfiguracioni fajl MultiSCSreq.cnf je potrebno dodatna imena upisati u delu [alt_names] kao vrednosti elemenata DNS.x. Dati konfiguracioni fajl predviđa tri dodatna FQDN imena, pri čemu taj broj, u zavisnosti od potrebe, može da bude manji ili veći. Ako je broj dodatnih FQDN imena manji od tri potrebnio je obrisati suvišne DNS.x elemente (obrisati celu liniju koja počinje sa DNS.x). Kada je kreiran konfiguracioni fajl prelazi se na generisanje zahteva za sertifikatom. Da bi ovaj zahtev mogao da bude kreiran, potrebno je da bude instaliran OpenSSL softverski paket. Pre zadavanja openssl komande, unmask komandom se definišu read privilegije za sve što će biti kreirano posle zadate komande. Na ovaj način se štiti privatni ključ servera, koji je tajni i ne sme da bude javno dostupan.
Pri pozivanju openssl-a zadaje se putanja do jednog od gore pomenutih konfiguracionih fajlova (komanda se zadaje u bilo kom direktorijumu). U dole navedenoj komandi myserver.key i server.csr predstavljaju nazive fajlova u koje će biti smešteni privatni ključ servera i zahtev za sertifikatom, redom, pri čemu imena ovih fajlova mogu da se promene i zgodno je da nose ime samog servera.

umask 0377
openssl req -new -config SCSreq.cnf -keyout myserver.key -out server.csr

Pokretanjem navedene openssl naredbe, tražiće se unos dodatnih informacija, pre samog generisanja zahteva (slika 7). Tražene podatke je potrebno tačno popuniti u skladu sa podacima koji su podneti u procesu registracije.

Na ovaj način je generisan par ključeva (privatni ključ se smešta u fajl myserver.key a javni ključ se pakuje u sam zahtev) i zahtev za potpisivanje sertifikata koji u sebi sadrži podatke o instituciji, jedno ili više FQDN imena i javni ključ servera.

Podaci koji treba da se nalaze u sertifikatu se digitalno potpisuju privatnim ključem servera i u obliku zahteva za sertifikatom se automatski smeštaju u fajl server.csr. Privatni ključ, koji se smešta u fajl myserver.key, ostaje na serveru i ne sme da bude javno dostupan. U nastavku teksta su navedeni preporučeni direktorijumi u kojima se čuvaju sertifikati i ključevi.

Kreirani zahtev za sertifikatom može da se proveri sledećom komandom:

openssl req –in myserver.csr –text

Zahtev za sertifikatom podnosi ovlašćena osoba institucije određena u toku registracije institucije. Prilikom podnošenja zahteva potrebno je sadržaj fajla myserver.csr kopirati kao tekst u telo poruke mejla i poslati na adresu tcs@amres.bg.ac.rs. Fajl .csr može da se otvori bilo kojim tekstualnim editorom. Zahtev se nalazi u base-64 kodiranom PEM formatu.

U nastavku je dat primer sadržaja fajla myserver.csr:

-----BEGIN CERTIFICATE REQUEST----- \\ 
MIIDITCCAgkCAQAwdjELMAkGA1UEBhMCUlMxEDAOBgNVBAcTB0Jlb2dyYWQxHzAd \\ 
BgNVBAoTFlVuaXZlcnNpdHkgb2YgQmVsZ3JhZGUxDTALBgNVBAsTBFJDVUIxJTAj \\ 
BgNVBAMTHG9wZW52cG4tc2VydmVyLnJjdWIuYmcuYWMucnMwggEiMA0GCSqGSIb3 \\ 
DQEBAQUAA4IBDwAwggEKAoIBAQDv+mcWyeT8ZS7SCjs8zAbXPsvx8YHjrk48H14M \\ 
+Yf9eXND2Z/FLiVYTax/S59YuFKi1vlmkxEFusspaDCnPs8dQovX2UYHZt9tNGXS \\ 
fzk2x7rviI/mG1y3o15Y0QH96Ov6+R2aGBAPcimjLtWh17KaAE0Xon4V6QWExNU6 \\ 
0TkP73/krflXTehJh2GdT7OvPCbJnwXUTN/RxLqETyL/BlbQr0mmi7Kqdy3xQLJM \\ 
ng5kBQ+fkd9fq4YiQMIIAu0sxpycX6sXIuzWRUuim0oHkCYuIxX8xxVL60oFfAqa \\ 
OiQyonjCG7ZJXngh7OtESeJEEtCniy+fzzweedv62kLTjMx5Osxw6FzUMuXCugzg \\ 
8kDH3DS607iv4Gn3IhYk/aV6H6hJtwUZaA/vssst6MvM6SJOeePZbpvGbYbnUAXU \\ 
FL/LWVThxqWXmz33pPPHzUCIP5HZf4vhGcZHbTmj6nPJ2edFYgtCWLyB0TCa8hi6 \\ 
o2CReo0kuS2oBxEpTx7dsszyPG4lqo0VUHxv5s3IXf4151PQOQ== \\ 
-----END CERTIFICATE REQUEST-----

Takođe, u mejlu je potrebno navesti i sledeće podatke:

• pun naziv institucije, ulica i broj, grad
• jedno ili više FQDN ime servera (ako se navodi više simboličnih imena u jednom sertifikatu, naglasiti koje ime je primarno)
• period važenja sertifikata – 1,2 ili 3 godine
• serverski softver korišćen za generisanje zahteva
• podatke o ovlašćenoj osobi koji su navedeni prilikom registracije
• e-mail adresu na koju će biti poslat sertifikat

Posle uspešne provere zahteva od strane RCUB-a, sertifikat će biti izdat i poslat na mejl koji je naveden prilikom zahtevanja sertifikata.

Sertifikat servera i ca-boundle fajl stižu na mejl poručioca u jednom zip fajlu. Dobijeni fajl ima naziv u obliku sedmocifrenog broja (na primer 9026687.zip) ili ima naziv samog servera (na primer nekiserver_rcub_bg_ac_rs). CA-boundle fajl sadrži prelazni i root CA sertifikat, koji zajdno formiraju CA-chain. Pri instalaciji dobijenog sertifikata potrebno je konfigurisati server da pored svog sertifikata šalje i ca-boundle fajl kojim se uspostavlja lanac poverenja. Prelazni sertifikat predstavlja sertifikat sertifikacionog tela koje je izdalo serverski sertifikat. Prelazno sertifikaciono telo je verifikovano od strane root sertifikacionog tela. Većina ssl klijenata ima preinstaliran root sertifikat, ali da bi sertifikat servera mogao da se proveri, klijentu je potreban i prelazni sertifikat koji je potpisan CA root sertifikatom.

Korišćenjem https protokola omogućava se sigurna razmena podataka između web servera i klijenta. Pomoću sertifikata servera vrši se autentifkacija servera (klijent može da bude siguran da je pristupio traženom serveru), a zatim se sva dalja komunikacija odvija preko zaštićenog kanala korišćenjem enkripcije.

Dobijeni .zip fajl je prvo potrebno raspakovati:

unzip 9026687.zip

Pošto je fajl raspakovan dobijaju se dva fajla sa .crt i .ca-bundle ekstenzijama. Fajl sa crt ekstenzijom predtavlja sertifikat servera, dok se u ca-bundle fajlu nalazi prelazni i root sertifikat. Za Linux distribucije nastale od Redhat-a (CentOS, Fedora, Mandriva) je uobičajeno da se sertifikati i ključevi čuvaju na sledećim lokacijama, redom:

/etc/pki/tls/certs/
/etc/pki/tls/private/

U ssl.conf konfiguracionom falju potrebno je uneti odgovarajuće putanje do sertifikata i ključa servera, kao i ca-bundle fajla.

SSLCertificateFile /etc/pki/tls/certs/9026687.crt
SSLCertificateKeyFile /etc/pki/tls/private/myserver.key
SSLCertificateChainFile /etc/pki/tls/certs/9026687.ca-bundle^***

Na kraju je potrebno restartovati web server:

/etc/init.d/httpd stop
/etc/init.d/httpd start

^*** Za Apache 1.x verziju: koristiti SSLCACertificateFile/etc/pki/tls/certs/9026687.ca-bundle

U slučaju da želite da vidite instaliran sertifikat, to možete da uradite pomoću sledeće komande:

openssl x509 –in 9026687.crt –text

Standard 802.1x omogućava autentifikaciju klijenata pre nego što im se dozvoli pristup mrežnim resursima. Kao framework protokol se koristi EAP (Extensible Authentication Protocol) u kombinaciji sa TLS (Transport Layer Security), TTLS (Tunneled TLS) ili u okviru PEAP (Protected EAP) protokola. Ovo uputstvo razmatra instalaciju i upotrebu serverskih sertifikata na RADIUS serveru (koji je realizovan na FreeRadius platformi) kod EAP-TTLS protokola pri eduroam servisu.

Sertifikat instaliran na RADIUS serveru se u toku procesa autentifikacije šalje klijentu. Sam sertifikat sadrži javni ključ servera i digitalni potpis ovlašćene institucije kojoj se veruje. Klijent verifikuje identitet servera proveravanjem digitalnog sertifikata i tada može da koristi serverov javni ključ za kriptovanje kredencijala koje će mu slati (videti dodatak A za detaljnije objašnjenje EAP-TTLS protokola).

Prvo je potrebno obezbediti serverski sertifikat na način opisan u prethodnom delu ovog uputstva (npr. dobijeni sertifikat se zove 8866644.zip). Taj fajl je potrebno prebaciti na sam server (npr. korišćenjem programa WinnSCP). Nakon toga se fajl prebacuje na lokaciju gde se drže sertifikati vezani za FreeRadius (folder /etc/raddb/certs ). U isti folder je potrebno prebaciti i privatni serverski ključ koji je generisan u procesu dobijanja samog serverskog sertifikata (npr. zove se privatnikljuc.key):

cp 8866644.zip /etc/raddb/certs/8866644.zip #(prebacivanje zip fajla)
cp privatnikljuc.key /etc/raddb/certs/privatnikljuc.key #(prebacivanje privatnog ključa)

zatim se fajl raspakuje:

unzip 8866644.zip

Kada se fajl raspakuje (komanda unzip), dobijaju se dva fajla, jedan sa .crt drugi sa .ca-bundle ekstenzijom. Sertifikat sa .crt ekstenzijom se prebacuje u .pem format preko sledećih komandi:

openssl x509 -in 8866644.crt -out 8866644.der -outform DER
openssl x509 -in 8866644.der -inform DER -out 8866644.pem -outform PEM

Privatni ključ servera mora da ima r——– (read only) dozvolu. U slučaju da nema potrebno je da se dozvola promeni sa:

chmod 400 /etc/raddb/certs/privatnikljuc.key

Sada je ove sertifikate potrebno ubaciti u konfiguraciju vezanu za tls (jer za funkcionisanje ttls autentifikacije je potrebno prvo konfigurisati tls) u okviru eap.conf fajla:

certdir = /etc/raddb/certs
cadir = /etc/raddb/certs
private_key_file = /etc/raddb/certs/privatniključ.key
certificate_file = /etc/raddb/certs/8866644.pem
CA_file = /etc/raddb/certs/8866644.ca-bundle

Sada je potrebno restartovati RADIUS proces da bi promene u konfiguraciji postale aktivne:

killall radiusd
radiusd

Da bi klijent uspešno proverio sertifikat servera, mora da instalira sam sertifikat na svoj računar.

Mail server koristi sertifikat kako bi se autentifikovao klijentima i kako bi ostvario sigurnu vezu sa klijentima korišćenjem enkripcije putem SSL/TLS protokola.

Procedura postavljanja sertifikata je ista kao i kod web servera, samo što se konfiguriše drugi konfiguracioni fajl. U konfiguracionom fajlu je potrebno uneti odgovarajuće putanje do serverskog i prelaznog sertifikata kao i ključa servera:

U slučaju IMAP i POP3 servera, koji se koriste za pristup mejlovima, konfiguracioni fajl je dovecot.conf ( /etc/dovecot.conf):

ssl_cert_file = /etc/pki/tls/certs/8866644.crt                         
ssl_key_file = /etc/pki/tls/private/myserver.key       
ssl_ca_file = /etc/pki/tls/certs/8866644.ca-bundle         

Za SMTP server, koji se koristi za transport, tj. za slanje i prijem mejlova, konfiguracioni fajl je main.cf (/etc/postfix/main.cf).:

smtpd_use_tls = yes 
smtpd_tls_CAfile = /etc/pki/tls/certs/8866644.ca-bundle  #(putanja do prelaznog sertifikata) 
smtpd_tls_CApath = /etc/pki/tls/certs                    #(putanja do direktorijuma u kome su sertifikati) 
smtpd_tls_cert_file = /etc/pki/tls/certs/8866644.crt     #(putanja do sertifikata servera) 
smtpd_tls_key_file = /etc/pki/tls/private/myserver.key   #(putanja do privatnog ključa servera)

Ukoliko je potrebno generisati sertfikat za Java web server kao što je Tomcat, koristi se alat keytool.

Generisanje zahteva za sertifikat je opisano na http://www.instantssl.com/ssl-certificate-support/csr_generation/ssl-certificate-java.html i zamenjuje poglavlje 1.2 ovog dokumenta. Dobijeni CSR fajl se koristi kao što je opisano u poglavlju 1.3, s tim što se za serverski softver navodi “Java web server”.

Za potrebe instalacije sertifikata takođe se koristi keytool kao što je opisano na adresi: https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=275&nav=0,1,88

Obratiti pažnju da se prilikom poslednjeg importa mora koristiti isti alias kao i prilikom generisanja zahteva za sertifikat, nakon čega keytool potvrđuje uparivanje sa informacijom ” Certificate reply was installed in keystore”.

U nastavku je dat lanac CA sertifikata za TCS serverske sertifikate. Prvi u nizu je sertifikat korenog certifikacionog tela (root CA), AddTrunst External CA Root, kojim je potpisan sledeći sertifikat prelaznog sertifikacionog tela (intermediate CA), UTN-USERFirst-Hardware. Na kraju sledi sertifikat TERENA sertifikacionog tela, TERENA SSL CA, koji je potpisan navedenim prelaznim sertifikatom.

Sertifikat korenog sertifikacionog tela je samopotpisan, pa su vrednosti polja Issuer i Subject iste. U polju Issuer, sertifikata prelaznog sertifikacionog tela, nalaze se podaci korenog sertifikacionog tela, kao tela koje je izdalo sertifikat. TERENA CA sertifikat je izdat od strane prelaznog sertifikacionog tela, čiji se podaci nalaze u polju Issuer.

AddTrust External CA Root (koreni sertifikat):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
        Validity
            Not Before: May 30 10:48:38 2000 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:b7:f7:1a:33:e6:f2:00:04:2d:39:e0:4e:5b:ed:
                    1f:bc:6c:0f:cd:b5:fa:23:b6:ce:de:9b:11:33:97:
                    a4:29:4c:7d:93:9f:bd:4a:bc:93:ed:03:1a:e3:8f:
                    cf:e5:6d:50:5a:d6:97:29:94:5a:80:b0:49:7a:db:
                    2e:95:fd:b8:ca:bf:37:38:2d:1e:3e:91:41:ad:70:
                    56:c7:f0:4f:3f:e8:32:9e:74:ca:c8:90:54:e9:c6:
                    5f:0f:78:9d:9a:40:3c:0e:ac:61:aa:5e:14:8f:9e:
                    87:a1:6a:50:dc:d7:9a:4e:af:05:b3:a6:71:94:9c:
                    71:b3:50:60:0a:c7:13:9d:38:07:86:02:a8:e9:a8:
                    69:26:18:90:ab:4c:b0:4f:23:ab:3a:4f:84:d8:df:
                    ce:9f:e1:69:6f:bb:d7:42:d7:6b:44:e4:c7:ad:ee:
                    6d:41:5f:72:5a:71:08:37:b3:79:65:a4:59:a0:94:
                    37:f7:00:2f:0d:c2:92:72:da:d0:38:72:db:14:a8:
                    45:c4:5d:2a:7d:b7:b4:d6:c4:ee:ac:cd:13:44:b7:
                    c9:2b:dd:43:00:25:fa:61:b9:69:6a:58:23:11:b7:
                    a7:33:8f:56:75:59:f5:cd:29:d7:46:b7:0a:2b:65:
                    b6:d3:42:6f:15:b2:b8:7b:fb:ef:e9:5d:53:d5:34:
                    5a:27
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
            X509v3 Key Usage:
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Authority Key Identifier:
                keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
                DirName:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
                serial:01

    Signature Algorithm: sha1WithRSAEncryption
        b0:9b:e0:85:25:c2:d6:23:e2:0f:96:06:92:9d:41:98:9c:d9:
        84:79:81:d9:1e:5b:14:07:23:36:65:8f:b0:d8:77:bb:ac:41:
        6c:47:60:83:51:b0:f9:32:3d:e7:fc:f6:26:13:c7:80:16:a5:
        bf:5a:fc:87:cf:78:79:89:21:9a:e2:4c:07:0a:86:35:bc:f2:
        de:51:c4:d2:96:b7:dc:7e:4e:ee:70:fd:1c:39:eb:0c:02:51:
        14:2d:8e:bd:16:e0:c1:df:46:75:e7:24:ad:ec:f4:42:b4:85:
        93:70:10:67:ba:9d:06:35:4a:18:d3:2b:7a:cc:51:42:a1:7a:
        63:d1:e6:bb:a1:c5:2b:c2:36:be:13:0d:e6:bd:63:7e:79:7b:
        a7:09:0d:40:ab:6a:dd:8f:8a:c3:f6:f6:8c:1a:42:05:51:d4:
        45:f5:9f:a7:62:21:68:15:20:43:3c:99:e7:7c:bd:24:d8:a9:
        91:17:73:88:3f:56:1b:31:38:18:b4:71:0f:9a:cd:c8:0e:9e:
        8e:2e:1b:e1:8c:98:83:cb:1f:31:f1:44:4c:c6:04:73:49:76:
        60:0f:c7:f8:bd:17:80:6b:2e:e9:cc:4c:0e:5a:9a:79:0f:20:
        0a:2e:d5:9e:63:26:1e:55:92:94:d8:82:17:5a:7b:d0:bc:c7:
        8f:4e:86:04

UTN-USERFirst-Hardware (prelazni sertifikat):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            48:4b:ac:f1:aa:c7:d7:13:43:d1:a2:74:35:49:97:25
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
        Validity
            Not Before: Jun  7 08:09:10 2005 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:b1:f7:c3:38:3f:b4:a8:7f:cf:39:82:51:67:d0:
                    6d:9f:d2:ff:58:f3:e7:9f:2b:ec:0d:89:54:99:b9:
                    38:99:16:f7:e0:21:79:48:c2:bb:61:74:12:96:1d:
                    3c:6a:72:d5:3c:10:67:3a:39:ed:2b:13:cd:66:eb:
                    95:09:33:a4:6c:97:b1:e8:c6:ec:c1:75:79:9c:46:
                    5e:8d:ab:d0:6a:fd:b9:2a:55:17:10:54:b3:19:f0:
                    9a:f6:f1:b1:5d:b6:a7:6d:fb:e0:71:17:6b:a2:88:
                    fb:00:df:fe:1a:31:77:0c:9a:01:7a:b1:32:e3:2b:
                    01:07:38:6e:c3:a5:5e:23:bc:45:9b:7b:50:c1:c9:
                    30:8f:db:e5:2b:7a:d3:5b:fb:33:40:1e:a0:d5:98:
                    17:bc:8b:87:c3:89:d3:5d:a0:8e:b2:aa:aa:f6:8e:
                    69:88:06:c5:fa:89:21:f3:08:9d:69:2e:09:33:9b:
                    29:0d:46:0f:8c:cc:49:34:b0:69:51:bd:f9:06:cd:
                    68:ad:66:4c:bc:3e:ac:61:bd:0a:88:0e:c8:df:3d:
                    ee:7c:04:4c:9d:0a:5e:6b:91:d6:ee:c7:ed:28:8d:
                    ab:4d:87:89:73:d0:6e:a4:d0:1e:16:8b:14:e1:76:
                    44:03:7f:63:ac:e4:cd:49:9c:c5:92:f4:ab:32:a1:
                    48:5b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A

            X509v3 Subject Key Identifier:
                A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 CRL Distribution Points:
                URI:http://crl.usertrust.com/AddTrustExternalCARoot.crl

    Signature Algorithm: sha1WithRSAEncryption
        3c:ec:7b:e0:ae:a3:0e:96:6d:30:d7:85:c6:d2:68:5b:45:5a:
        82:a6:34:0f:b0:c9:92:23:5e:11:6d:08:11:b2:74:09:23:3a:
        35:25:73:58:5e:ca:b9:7c:28:fa:47:ec:f9:a0:03:58:50:b6:
        53:ef:8c:db:39:e4:67:e9:d8:ca:28:46:d4:a7:e0:f5:38:75:
        f8:e7:cb:5c:bf:1d:11:3c:6a:40:9b:2d:44:56:d3:f7:ff:05:
        28:32:0c:15:c8:64:45:93:e8:21:24:8f:2d:da:7a:84:7b:4f:
        cf:cd:b2:25:7c:77:10:d3:94:d1:04:91:a8:25:1c:09:22:0f:
        7d:44:35:11:14:ef:af:00:fe:5e:ea:5f:8e:b0:d9:92:59:ba:
        fc:13:96:a0:18:01:56:ce:da:f6:28:0b:b1:af:dd:5c:4f:5c:
        b2:f3:8f:5a:71:cf:ed:18:ad:63:88:1d:8e:95:f7:ea:95:e7:
        1f:ad:90:b8:84:08:47:85:7f:22:2f:1a:1d:48:30:d6:4c:08:
        d8:37:19:67:32:2b:eb:5c:d0:b2:fc:6e:57:9f:04:35:5e:90:
        00:7e:11:c7:de:13:2a:cd:a4:6d:45:26:c7:88:56:a0:f0:6a:
        f7:d8:e7:fc:27:7e:67:08:d0:bd:fa:b6:c3:61:02:01:65:b9:
        b8:2f:cf:5a

TERENA SSL CA (TERENA CA sertifikat):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            4b:c8:14:03:2f:07:fa:6a:a4:f0:da:29:df:61:79:ba
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware
        Validity
            Not Before: May 18 00:00:00 2009 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C=NL, O=TERENA, CN=TERENA SSL CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:c3:e3:48:c4:2f:5c:c1:cb:a9:99:fd:1b:a2:83:
                    5d:8a:3d:ad:3a:d0:e2:a4:43:1f:4d:0e:fe:35:25:
                    30:a5:69:1b:c4:e8:e5:c1:8f:54:7e:e1:6a:a2:9a:
                    5c:5c:de:3d:fc:02:ce:96:b8:5f:8f:83:5b:cc:60:
                    40:90:f8:e4:b6:3a:25:9c:5f:14:51:ec:b1:e7:af:
                    9e:50:a1:31:55:c7:02:bd:ac:52:8a:7f:35:8e:82:
                    fa:84:ad:15:fe:a2:7f:83:10:3a:55:53:94:2c:01:
                    16:74:94:54:63:28:a3:f2:5b:29:3d:94:88:80:20:
                    e2:14:59:21:19:b4:a4:98:e1:60:e6:f2:eb:a2:80:
                    83:43:e0:ad:68:f3:79:19:8b:68:43:51:3f:8a:9b:
                    41:85:0c:35:8c:5d:b5:f1:b6:e5:a7:c3:83:b5:6b:
                    23:6f:d4:a5:eb:50:e5:94:f1:4a:5f:ee:27:4b:14:
                    12:15:24:4c:0d:cf:62:8d:b7:00:21:ad:3a:32:0f:
                    58:0b:5f:1e:9b:d1:df:9d:8e:a9:19:35:50:2f:41:
                    a9:ad:3b:c6:e0:45:b2:53:39:7f:21:bf:22:1a:87:
                    5c:34:ae:52:6f:07:7d:a2:0b:4e:9f:2b:79:a6:7d:
                    13:dd:f5:7f:83:7c:2f:5a:5d:77:78:78:91:a0:14:
                    bf:7d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45

            X509v3 Subject Key Identifier:
                0C:BD:93:68:0C:F3:DE:AB:A3:49:6B:2B:37:57:47:EA:90:E3:B9:ED
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.6449.1.2.2.29

            X509v3 CRL Distribution Points:
                URI:http://crl.usertrust.com/UTN-USERFirst-Hardware.crl

            Authority Information Access:
                CA Issuers - URI:http://crt.usertrust.com/UTNAddTrustServer_CA.crt
                OCSP - URI:http://ocsp.usertrust.com

    Signature Algorithm: sha1WithRSAEncryption
        4e:23:ee:48:9c:f6:85:8b:71:c4:0a:6e:73:93:72:c0:3a:8e:
        80:8a:d9:b3:ca:b2:d4:01:9c:28:cf:f2:5c:0e:21:44:93:0b:
        b6:1a:21:e3:98:01:94:0e:67:49:81:1e:be:3d:0d:4e:60:da:
        ef:a0:31:4e:95:ef:f3:dd:7a:5a:82:20:43:b6:a1:63:43:b3:
        50:69:43:62:4b:56:62:b0:34:8a:b9:13:43:59:93:ec:14:79:
        88:f3:48:93:e8:9d:c9:fa:87:72:0c:6b:56:a0:c3:15:8d:68:
        a5:87:1f:71:2d:e6:5a:6d:3c:69:71:40:04:55:dc:a0:43:94:
        20:45:38:78:d7:bd:8a:d8:39:c6:df:09:b7:5a:9a:a9:03:b8:
        28:10:78:cd:bf:01:1b:5a:11:3e:38:f4:d8:1b:34:79:cf:33:
        d2:01:fd:ac:98:cd:6d:47:11:90:4c:bb:b9:5b:d8:70:e7:d5:
        af:b6:cc:c4:86:e6:75:c0:9e:29:b6:2b:0f:2a:a5:69:02:0d:
        e3:e9:a2:b4:5d:c0:f3:ce:2c:6a:85:38:76:61:c6:49:82:ab:
        51:b3:82:a6:b9:41:98:28:98:fb:6b:fe:8a:16:ff:31:7e:54:
        47:a8:3c:dc:43:26:a9:9b:05:b7:9e:c0:34:43:91:30:d4:32:
        c3:11:5a:e1

SSL (Secure Sockets Layer) protocol se koristi za uspostavljanje sigurnog kanala komunikacije. SSL koristi klijent-server model. Klijent je strana koja inicira sigurnu komunikaciju, dok server odgovara na zahtev klijenta. Najčešći primer korišćenja SSL protokola je https koji predstavlja sigurnu verziju http-a (secure http) i koristi se za uspostavu zaštićene veze sa nekim web serverom, najčešće za potrebe elektronskog plaćanja. U tom slučajum, web pretraživač predstavlja SSL klijenta, a web server, odnosno sajt kome se pristupa, je SSL server.

Sa stanovišta SSL protokola, ono što pravi razliku između klijenta i servera su akcije koje oni preduzimaju prilikom pregovora oko sigurnosnih parametara. Kako klijent inicira komunikaciju, njegov zadatak je da predloži skup SSL opcija koje će se koristiti za uspostavu zaštićenog kanala. Server, na osnovu onoga što je klijent ponudio, bira skup opcija koje će se koristiti. Iako je konačna odluka na serveru, server može da bira samo iz skupa parametara koje je klijent inicijalno predložio.

Alert – Obaveštava drugu stranu o mogućoj sigurnosnoj pretnji ili o prekidu kounikacije.

ApplicationData – Sami korisni podaci koje dve strane razmenjuju, enkriptovani, autentifikovani i/ili verifikovani od strane SSL-a.

Certificate – Poruka koja nosi digitalni sertifikat pošiljaoca (koji sadrži njegov javni ključ).

CertificateRequest – Zahtev za sertifikatom klijenta koji šalje server.

CertificateVerify – Poruka koju šalje klijent kako bi dokazao da poseduje odgovarajući privatni ključ koji odgovara javnom ključu koji se nalazi u njegovom sertifikatu.

ChangeCipherSpec – Poruka kojom se označava početak korišćenja sigurne komunikacije sa prethodno dogovorenim parametrima.

ClientHello – Poruka koju šalje klijent u kojoj navodi listu sigurnosnih parametra koje podržava I želi da koristi za uspostavu sigurne komunikacije.

ClientKeyExchange – Poruka od klijenta koja sadrži kriptografske ključeve za uspostavu sigurne komunikacije.

Finished – Potvrda da je inicijalno pregovaranje završeno i da je uspostavljena sigurna komunikacija.

HelloRequest – Zahtev od servera da klijent počne (ili restartuje) SSL process za dogovor oko parametara koji će se koristiti.

ServerHello – Poruka od servera koja specificira sigurnosne servise koji će se koristiti u komunikaciji.

ServerHelloDone – Potvrda koju šalje server kako bi potvrdio klijentu da je završio sa slanjem svih zahteva klijentu za uspostavu sigurne komunikacije.

ServerKeyExchange - Poruka od servera koja sadrži kriptografske ključeve za uspostavu sigurne komunikacije.

Najosnovnija funkcija koju SSL klijent i server mogu da urade je uspostava kanala za enkriptovanu komunikaciju.

Na slici 7 je prikazana razmena pruka između SSL klijenta i servera koja prethodi uspostavi enkriptovane komunikacije, a u tabeli x je dato objašnjenje odgovarajućih koraka u razmeni.

SSL sadrži mehanuzme koji omogućavaju svakoj straini komunikacije da autentifikuje drugu. Na ovaj način svaki korisnik može da bude siguran u identitet korisnika sa kojim komunicira i da nije došlo do krađe identiteta, odnosno, lažnog predstavljhanja od strane nekog napdača.

Na slici 8 su prikazane poruke koje se razmenjuju kako bi klijent izvršio autentifikaciju s slici x su prikazane poruke koje se razmenjuju kako bi klijent izvršio autentifikaciju servera.

Pri utvrđivanja identiteta servera, server šalje Certificate poruku umesto ServerKeyExchange poruke. Certificate poruka sadrži lanac sertifikata koji počinje sa sertifikatom samog servera a yavršava se sertifikatom korenog sertifikacionog tela (root CA). Klijent je dužan da proveri da li može da veruje sertifikatu koji dobije od servera. To uključuje proveru digitalnog potpisa, period važenja i status revokacije sertifikata.

Kao i ranije opisano, klijent šalje ClientKeyExchange poruku ali sada enkriptovanu javnim ključem servera koji se nalazi u sertifikatu dobijenom od servera. Ovaj korak je važan zato što omogućava klijentu da bude siguran da strana sa kojom komunicira poseduje i odgovarajući privatni ključ. Samo onaj ko poseduje odgovarajući privatni ključ će moći da dešifruje poruku od klijenta i uspešno nastavi komunikaciju.

U tabeli 3 je dato objašnjenje odgovarajućih koraka u razmeni.

Gore je objašnjeno da pri autentifikaciji servera, server šalje Certificate poruku umesto ServerKeyExchange poruke. Jedna od posledica ovakvog pristupa je da se isti javni ključ koristi za potvrdu identiteta servera i enkripciju ključa koji će se koristiti za enkripciju sesije a koji šalje klijent. Pored toga što nije poželjno, u nekim slučajevima ni ne postoji odgovarajuća podrška. Naime, neki sigurnosni algorimi (kao što je DSA – Digital Signature Algorithm) mogu da se koriste samo za digitalno potpisivanje poruke, ali ne i za enkripciju. U takvoj situaciji, nije izvodljivo da kliljent enkrptuje ClientKeyExchange poruku koristeći javni ključ servera. U takvom slučaju potrebno je razdvojiti enkripciju od autentifikacije.

Na slici 9 je prikazana razmena poruka koja odgovara objašnjenoj situaciji.

Certificate poruka u ovom slučaju je ista kao i u gore objašnjenim situacijama, osim što se javni ključ servera koji se nalazi u njegovom sertifikatu koristi samo kako bi se potvrdio identitet servera, odnosno, izvršila njegova autentifikacija.

Po slanju Certificate poruke, server šalje ServerKeyExchange poruku koja sadrži javni ključ koji klijent treba da koristi za enkripciju informacije o ključevima koji će se koristiti za sesiju. ServerKeyExchange poruka je ista poruka koja je opisana u prvom primeru kada se ne vrši autentifikacija servera. Razlika je u tome što je informacija o ključevima sad potpisana privatnim ključem servera koji se nalazi u njegovom sertifikatu. Ovaj korak je bitan kako bi klijent mogao da potvrdi da server zaista poseduje privatni ključ koji odgovara javnom ključu sadržanom u sertifikatu servera.

U tabeli 4 su objašnjeni svi koraci prilikom razmene.

Pored autentifikacije servera SSL omogućava i autentifikaciju klijenta koja je realizovana na sličan način. Na slici 10 je prikazana odgovarajuca razmena poruka, a u tabeli 5 su objašnjeni odgovarajući koraci.

Ako server zahteva autentifikaciju klijenta, šalje Certificate Request poruku u sklopu hello razmene. SSL specificira da server ne može da traži autentifikaciju klijent ukoliko se on prethodno nije autentifikovao klijentu.

Napomena: SSL koristi javni ključ klijenta samo za digitalno potpisivanje, odnosno autentifikaciju. Za razliku od slučaja sa serverom, ne postoji potreba za enkripciju korišćenjem javnog ključa klijenta. Iz tog razloga, nema potrebe da se u slucaju autentifikacije klijenta posebno odvaja enkripcija.

Samo slanje Certificate poruke od strane klijenta ne obezbeđuje potpunu autentifikaciju klijenta. Klijent mora da dokaže da poseduje i odgovarajući privatni ključ. Zato, klijent šalje CertificateVerify poruku koja sadrži digitalno potpisan heš dobijen od informacije koja je poznata i klijentu i sreveru. Na taj način server može da proveri potpis i utvrdi da li klijent poseduje odgovarajući privatni ključ.

SSL protokol je organizovan iz više delova kao što je prikazano na slici 11. Četiri različita izvora kreiraju SSL poruke: ChangeCipherSpec protokol, Alert protokol, Handshake protokol i aplikativni protokoli kao što je http. Record Layer protokol prihvate poruke navedenih protokola, formatira ih, vrši odgovarajuću enkapsulaciju i prosleđuje ih transportnom sloju.

SSL protokol zahteva puzdan prenos i bez grešaka, tako da koristi tcp kao protokol transportnog sloja. SSL omogućava kombinovanje više SSL poruka u okviru jednog TCP segmenta.

SSL koristi Record Layer protokol za enkapsulaciju koji definiše zajednički format za sve SSL poruke (Alert, ChangeCipherSpec, Handshake i poruke same aplikacije). Na slici 13 je prikazan format poruke koji specificira Record Layer, a u tabeli 6 su data objašnjenja odgovarajućih polja.

ChangeCipherSpec protokol

Ovo je jednostavan protokol koji ima samo jednu pruku, ChangeCipherSpec, koja je već pomenuta i objašnjena.

Alert protokol

Koriste ga sistemi kako bi signalizirali grešku ili upozorenje drugoj strani komunikacije.

Handshake protokol

Zadužen je razmenu poruka za dogovor parametra SSL sesije:

• HelloRequest
• ClientHello
• ServerHello
• Certificate
• ServerKeyExchange
• CertificateRequest
• ServerHelloDone
• CertificateVerify
• ClientKeyExchange
• Finished

EAP (Extensible Authentication Protocol) predstavlja framework protokol za proces autentifikacije u okviru 802.1x standarda. EAP poruke se prenose iznad MAC sloja PPP, Ethernet, Token Ring ili 802.11 Wireless protokola. One nose pakete protokola za autentifikaciju: TLS, TTLS ili PEAP. Tok poruka između klijenta i servera prilikom autentifikacije korišćenjem EAP-TTLS protokola preko Wireless mreže je prikazan na slici 1.

Slika 1. EAP-TTLS

• Klijent access point-u šalje zahtev za asocijacijom, čime želi da alocira resurse i da se sinhroniše sa AP-om, u toj poruci se prenose informacije o NIC kartici klijenta (koje protoke podržava) i SSID-u mreže na koju želi da se poveže.
• AP šalje Association Response poruku u kojoj se nalazi prihvatanje ili odbijanje zahteva za asocijacijom. Ako odluči da prihvati zahtev, AP alocira memorijski prostor i generiše Association ID koji se prosleđuje u poruci.
• Klijent šalje prvu EAP poruku kao zahtev za početkom EAP-TTLS autentifikacije.
• AP šalje zahev za identitetom klijenta.
• Klijent šalje svoje kredencijale kao odgovor na prethodu poruku, ali ne šalje svoj pravi identitet jer konekcija nije joše zaštićena, tj ne koristi se nikakva enkripcija. Klijent šalje svoj tzv. spoljni (outer) identitet koji je obično u formi autonomous@ream, dakle ne šalje svoje pravo korisničko ime.
• AP preuzima klijentovu EAP poruku, enkapsulira je u RADIUS protokol i prosleđuje serveru za autentifikaciju.
• Server šalje klijentu zahtev za identitetom i lozinkom, i uz to svoj sertifikat koji sadrži javni ključ servera i hash samog sertifikata kriptovan javnim ključem CA-a.
• AP dekapsulira EAP poruku iz RADIUS-a i enkapsulira je u 802.11 protokol i posleđuje ka klijentu.
• Klijent proverava identitet servera na sledeći način:
  1. klijent prvobitno sadrži javni ključ CA-a (koji je predefinisan u okviru softvera Supplicant na klijentu);
  2. klijent dekriptuje digitalni potpis sertifikata javnim ključem CA-a i dobija hash sertifikata;
  3. serverov sertifikat se zatim ubacuje u hash funkciju koja je navedena u sertifikatu i izlaz iz funkcije se upoređuje sa hash-om dobijenim dekriptovanjem digitalnog potpisa u okviru serverskog sertifikata;
  4. ako su ta dva hash-a jednaka, klijent može da veruje serveru i da koristi njegov javni kluč da kriptuje svoje kredencijale;
     
     ako je ishod prethodnog postupka pozitivan, klijent kriptuje svoje kredencijale (identitet i lozinku) koristeći javni kluč servera, na taj način praveći tunel između njega i servera.

• Server dekriptuje poruku svojim privatnim ključem i proverava kredencijale korisnika u bazi podataka.
• Ako je autentifikacija uspešna, server šalje Access accept poruku ka klijentu.
• AP prosleđuje poruku o uspešnoj autentifikaciji ka klijentu i proces je završen.