Bug Online

Prva verzija ove preporuke izdana je 1988. godine, da bi 1993. godine bila prerađena kako bi obuhvatila nove sigurnosne zahtjeve. Ubrzo, 1995. godine, izdana je treća verzija, koja je prerađena 2000. godine. Verzija 3 omogućava fleksibilnost u podržavanju drugih topologija poput mostova (bridge) i mreža (mesh) (RFC 4158).  Preporuka X.509 specificira standardne formate za certifikate javnog ključa, liste opoziva certifikata, svojstva certifikata i algoritam za validaciju putanje certifikata. To je preporuka ITU-T, koja je dio serije preporuka X.500 koja definira direktorijski servis. Direktorij je, zapravo, server ili distribuirani skup servera koji pružaju bazu podataka u kojoj su sadržani podaci o korisnicima. Podaci sadrže mapiranje korisničkog imena u mrežnu adresu, kao i ostale atribute i informacije o korisnicima. Direktorij može služiti kao repozitorij certifikata javnog ključa. Svaki certifikat sadrži javni ključ korisnika te je potpisan privatnim ključem povjerljivog autora certifikata (CA - Certificate Authority). X.509 je važan standard jer se strukture i autentifikacijski protokoli certifikata definirani u njemu koriste u različitim primjenama, kao što su protokoli S/MIME, IP Security i SSL/TLS.

X.509 se zasniva na korištenju kriptografije javnog ključa i digitalnih potpisa. Standard ne zahtijeva korištenje specifičnog algoritma, ali preporučuje RSA. Pretpostavlja se da shema digitalnih potpisa zahtijeva korištenje hash funkcije. Standard, također, ne zahtijeva korištenje specifičnog hash algoritma. Preporuka iz 1988. nalagala je korištenje specifičnog hash algoritma za koji se pokazalo da je nesiguran te je izbačen iz sljedeće preporuke.

Kako su se mijenjale verzije preporuke X.509, tako se mijenjao i format same preporuke. Izlaskom svake nove verzije dodavala su se nova polja unutar preporuke, pa je tako prvotna verzija imala osam polja, a posljednja jedanaest. U drugoj verziji dodana su dva polja: jedinstveni identifikator izdavača i jedinstveni identifikator subjekta. Oba dodana polja bila su opcionalna string-polja koja su se koristila da bi se jedinstveno identificirao CA/subjekt u slučaju ponovnog korištenja X.500 imena za druge entitete. Dolaskom treće verzije uvodi se još jedno dodatno polje nazvano Extensions (ekstenzije). Neke od često korištenih ekstenzija datoteka za X.509 certifikate jesu: .DER, .PEM, .cer, .crt, .P7C, .P7B, .P12, PFX...

CA, jesi to ti?

Kako znati je li dobiveni certifikat generirao povjerljivi CA? U principu vrlo jednostavno, jer je sve propisano protokolom. Sve počiva na dvije važne karakteristike koje definiraju svaki korisnički certifikat koji CA generira, a to su: 1) svaki korisnik koji ima pristup javnom ključu CA-a može verificirati korisnički javni ključ, koji je certificiran, i 2) nitko osim CA-a ne može modificirati certifikat bez kasnije detekcije promijene. Prema tome, certifikati se mogu smjestiti u direktorij bez potrebe za dodatnim načinima zaštite direktorija.

Ako su svi korisnici pretplaćeni na isti CA, tada postoji zajedničko povjerenje prema tom CA-u. Svi se korisnički certifikati smještaju u direktorij kojemu mogu pristupiti svi korisnici. Svaki korisnik može slati svoj certifikat direktno bilo kojem drugom korisniku. U svakom slučaju, jednom kada B posjeduje A-ov certifikat, B pouzdano zna da će poruke kriptirane A-ovim javnim ključem biti sigurne. U slučaju velike zajednice korisnika, nije praktično da svi korisnici budu pretplaćeni na isti CA. Budući da CA potpisuje certifikate, svaki korisnik koji sudjeluje u procesu mora imati kopiju CA-ovog javnog ključa da bi mogao verificirati potpise. Javni ključ se mora dostaviti svakom korisniku na potpuno siguran način, tako da korisnik ima povjerenje u odgovarajuće certifikate. Iz toga slijedi da je praktičnije da postoji više CA-ova, od kojih svaki na siguran način dostavlja svoj javni ključ određenoj grupi korisnika.

Recimo da korisnik A dobiva certifikat od CA-a X1, a B od CA-a X2. Ako A sa sigurnošću ne poznaje ključ od X2, tada je B-ov certifikat, izdan od X2, A-u beskoristan. A može čitati B-ove certifikate, ali ne može verificirati potpis. Međutim, u slučaju da dva CA-a međusobno na siguran način razmijene javne ključeve, sljedeća će procedura omogućavati da A dobije B-ov javni ključ: 1) korisnik A iz direktorija dohvaća certifikat X2 koji je potpisao X1; budući da A sa sigurnošću poznaje javni ključ X1, može dobiti javni ključ od X2 iz njegova certifikata te ga verificirati s pomoću potpisa certifikata (potpis od X1); 2) korisnik A tada ponovno iz direktorija dohvaća certifikat korisnika B koji potpisuje CA X2; budući da A sada posjeduje povjerljivu kopiju javnog ključa X2, može verificirati potpis i sigurno dobiti javni ključ korisnika B. Korisnik A koristi lanac certifikata da bi dobio javni ključ korisnika B. U X.509 notaciji, ovaj se lanac obilježava na sljedeći način: X1<<X2>> X2 <<B>>.

Postoje samopotpisani certifikati: to su CA certifikati jer su izdavač i subjekt isti entitet. Ne postoji način provjere ovakvog certifikata osim provjere njime samim; umjesto tog načina, ovakve vrhovne certifikate ručno spremaju web preglednici. Organizacija Thawte jedan je od izvornih autoriteta certifikata koje priznaju Microsoft i Mozilla. Ovakvi certifikati dolaze kao dio web preglednika te im se podrazumijevano vjeruje. Kao certifikat koji može potpisivati bilo što, dugog vijeka i kojemu se globalno vjeruje, njegov se odgovarajući privatni ključ mora striktno čuvati.