To što želiš zove se "prijava klijentskim sertifikatom".

Grubo prepričano plan je sledeći: klijent, nazovimo ga Petar Perić, poseduje par ključeva (privatni ključ koji ne daje nikom i drugi koji je javni i jednoznačno povezan sa privatnim) i sertifikat. Privatni i javni ključ su posebno odabrani tako da kada se neki podatak šifruje jednim, dešifrovanje se obavlja onim drugim ključem iz para. Sertifikat je potvrda koju izdaje izdavalac i kojom se potvrđuje da dati javni ključ pripada upravo nekom Petru Periću. U datoteci sertifikata se nalazi Petrov javni ključ, informacije o Petrovom indentitetu i podaci o izdavaocu sertifikata, rok važenja, ograničenja za šta Petar sme da koristi ključeve i sertifikat, oznaka politike koliko dobro izdavalac poznaje Petra i drugi podaci na osnovu kojih ti možeš sertifikat da prihvatiš ili odbaciš kao nedovoljno dobar. Sertifikat je elektronski potpisan od strane izdavaoca, i proverom tog elektronskog potpisa možemo da budemo sigurni da sertifikat nije falsifikovan.

Sertifikat možeš Petru izdati ti lično (ako imaš neki drugi način da proveriš da je upravo Petar taj koji zahteva potvrdu i možeš da obezediš pouzdanost i poverljivost procesa izdavanja i potpisivanja sertifikata), ili ga Petru može izdati sertifikaciono telo kome ti dovoljno veruješ. Izdavanje sertifikata je ozbiljan posao jer se time daje digitalni identitet Petru Periću, i neko tu mora da garantuje kako neće doći do greške. Sa tvoje strane ti biraš kojim izdavaocima ćeš verovati. U popularnim programima (nas ovde zanima IIS kao veb server jer tu ćemo proveravati Petrov identitet) podrazumevano su označeni neki izdavaoci kao pouzani, a ovaj spisak možeš da prilagodiš dodavanjem dodatnih tzv. korenskih sertifikata izdavaoca kojima želiš da veruješ.

Kada Petar poželi da se prijavi na sajt klijentskim sertifikatom, u okviru HTTPS pregovaranja, Petar (odnosno njegov veb pregledač) šalje klijentski sertifikat. Na strani servera IIS Petru pošalje kratku nasumičnu poruku koju će Petar šifrovati svojim privatnim ključem. Server dešifruje poruku Petrovim javnim ključem iz njegovog sertifikata i ako se dešifrovana poruka poklapa sa onim što je Petru poslato znamo da onaj sa druge strane ima privatan ključ koji odgovara javnom ključu iz sertifikata. Preostaje da utvrdimo da li je to Petar tako što ćemo proveriti validnost izdatog sertifikata, uvidom u sertifikat (da li ima odgovarajuće karakteristike), i proverom elektronskog potpisa sertifikata i proveru opozvanosti sertifiakta jer izdavalac ima mogućnost da opozove ranije izdati sertifikat (ako na primer Petar prijavi da mu je neko ukrao privatni ključ ili izdavalac primeti neku grešku).

Ovo je skraćeno teorijsko objašnjenje.

Praktično HTTPS pregovaranje, razmenu poruka, dešifrovanje i proveru validnosti sertifikata (karakteristika, potpisa i opozvanosti) srećom obavlja sam veb server prema konfigurisanoj listi izdavaoca od poverenja. U retkim situacijama može ti trebati nešto više od podrazumevanog, i tada nešto od ovoga moraš raditi ručno, ali to brzo postaje veoma komplikovano.

U aplikaciji sertifikatu pristupaš preko Request.ClientCertificate, a podatke o korisniku dobijaš preneseno preko standardnog User.Identity objekta.

Aplikacija mora biti na HTTPS, a za to ti treba da na serveru imaš postavljen serverski sertifikat (i par ključeva). To je isto kao i Petrov klijentski samo sada predstavlja identitet sajta na serveru, a ne identitet korisnika. Ovaj sertifikat možeš da izdaš sama sebi (Petar će onda videti upozorenje kako je to self-signed sertifikat i mora ručno da prihvati da li veruje takvom sertifikatu) ili možeš da zahtevaš sertifikat od sertifikacionog tela. Ponovo, baš kao što Petar treba da pribavi svoj digitalni identitet tako i ti treba da učiniš isto sa identitetom za svoj sajt.

Jedini resurs koji ti je dovoljan da sve ovo obaviš je http://support.microsoft.com/kb/315588 a nadam se da je ova moja poruka od pomoći.

Propustio sam da pomenem kartice.

Pametna kartica je ovde dodatni faktor bezbednosti. Kada bismo privatni ključ držali kao datoteku na računaru virusi/hakeri/komšija bi mogli da to iskopiraju i okolo se potom predstavljaju kao Petar Perić.

Zato koristimo pametnu karticu koja je tako napravljena da privatni ključ ne može da se iskopira sa kartice. Dodatni softver na računaru (midlver za karticu) omogućava veb pregledaču da kada primi onu poruku za šifrovanje istu pošalje kartici. Obično midlver tada zatraži unos PIN koda, aktivira karticu podatak se u kartici šifruje privatnim ključem i vrati nazad veb pregledaču da ga prosledi serveru.

Izdavaoci sertifikata u sertifikatu naglase da li je to sertifikat čiji se privatni ključ čuva u pametnoj kartici. Kod nekih kartica par ključeva se formira u samoj kartici pa apsolutno niko nema kopiju, neki izdavaoci čuvaju kod sebe kopiju kako bi izdavali duplikat ako Petar izgubi karticu. A negde su kartice samo "fasada" i ključ se zapravo može kopirati iz kartice. Sve to uglavnom piše u politici izdavaoca.

U samoj kartici često imamo više od jednog para ključeva+sertifikat, a svaki par može imati različite politike i pravila upotrebe što se navodi u sertifikatu. Sve je stvar politike, željene bezbednosti i očekivane pretnje.

I opet da završim koliko toliko praktično:

Sa strane servera za proces prijave klijentskim sertifikatom nama je sve jedno gde se nalazi ključ, da li je u datoteci na računaru, u pametnoj kartici ili nečem trećem. U svakom slučaju klijentski veb pregledač serveru dostavlja sertifikat i šifrovanu poruku koja se jednako proverava. Jedino o čemu vodimo računa jeste da li je izdavalac sertifikata u listi izdavaoca od poverenja na serveru i da li je sertifikat validan. Ako je zahtev da verujemo samo sertifikatima koji garantuju da je ključ u pametnoj kartici ili imaju neku drugu karakteristiku to možemo proveriti uvidom u primljeni sertifikat.

Gorane, mnogo hvala na trudu i ovako opširnom odgovoru!
Jesam li dobro razumela da bi trebalo sa sajta sertifikacionog tela, koje mi je izdalo kartice, da preuzmem korenski sertifikat i dodam ga u listu izdavalaca kojima se veruje?
Serverski sertifikat mogu sama da kreiram i na IIS-u podesim da aplikacija mora biti na HTTPS, koristeći taj sertifikat?

Tačno tako.

Možda je najbolje prvo omogućiti HTTPS, pa kada to proradi onda se igrati sa prijemom klijentskog sertifikata.

Ako se za HTTPS koristi samopotpisani serverski sertifikat, klijent koji posećuje sajt će morati da prihvati upozorenje koje prikazuje veb pregledač. Ja ne bih voleo da klijentskim sertfikatom pristupam sajtu koji koristi samopotpisani sertfikat, nekako nije fer da se od mene traži visoka garancija identiteta, a da istovremeno to isto ne važi za sajt. Kako je sertifikat samopotpisan niko ne garantuje identitet sajta, svako može da napravi i zloupotrebi svoj "google.com" sertfikat i eventualno presretne podatke između mene i sajta.

Međutim kada se za HTTPS koristi serverski sertfikat koji izdaje sertifikaciono telo čiji je korenski sertifikat u listi na klijentovom računaru, neće biti ovog ružnog upozorenja jer tada sertfikaciono telo garantuje za identitet, a ono je u listi pa mu klijent veruje. Različiti veb pregledači i operativni sistemi imaju nešto drugačije liste tela od poverenja, a ta tela imaju i različite cene i procedure za izdavanje serverskih sertifikata. Ako kupuješ sertifikat, raspitaj se ili proveri sama jesu li podrazumevano u listi i gde. Ovako izgleda upozorenje o nepozdanom sertfikatu:



U ovom slučaju sajt www.euprava.gov.rs ne koristi samopotpisani sertifikat, već sertifikat izdaje Pošta CA preko "Posta CA 1" koji kod mene nije dodat u listu pouzdanih korenskih sertifikata.

Kao i ti na serveru, i klijent uvek može da doda nove korenske sertifikate. Kada koristi karticu, sigurno da će imati korenski tog sertifikacionog tela u listi, pa ako se pod istim korenskim izdaju i serverski sertifikati eto jedne moguće varijante.

Postoji i treća varijanta (pored korišćenje samopotpisanih i korišćenje serverskog sertifikata koje izdaje neko telo), a to je da imaš sopstveno sertfikaciono telo pa da onda svom sajtu sama izdaš sertifikat. Realno ne verujem da to želiš i zašto bi iko takvom sertifikacionom telu verovao. ;) Ali u nekoj organizaciji u varijanti da sama sebi praviš kartice i sertifikate, da postoji neophodna infrastruktura, znanje i kultura bezbednosti, to je takođe validno rešenje.


Zaključak

Za testiranje i razvoj možeš slobodno da koristiš samopotpisani sertifikat na serveru i u bilo kom trenutku kasnije da to promeniš. Promena ni na koji drugi način ne utiče na razvoj i ponašanje veb aplikacije niti na prijavu klijentskim sertifikatom.


_{[Ovu poruku je menjao Goran Rakić dana 07.10.2012. u 18:21 GMT+1]}

Saveti su bili dragoceni!
Za sada koristim samopotpisani sertifikat i kada klijent ručno prihvati da veruje tom sertifikatu pojavljuje se prozor sa listom sertifikata. Korisnik bira koji sertifikat će koristiti, ubacuje pametnu karticu i unosi odgovarajući PIN kod. Tek nakon toga može da pristupi aplikaciji, što je upravo ono što sam i želela.
Veliko HVALA, još jednom!