Nova verzija SecurityTray aplikacije je objavljena 9. januara 2017. godine koja više ne koristi opozvani
sertifikat. Tekst ispod se odnosi na pretodnu verziju i više nije primenljiv. Za informacije o pristupu,
pratite nova uputstva na CROSO portalu. Hvala svima koji su se lično javili kako bi zahvalili za dole napisani
savet u vezi pristupa portalu od 23. do 30. decembra. Drago mi je da sam mogao da pomognem. Tekst ostavljam objavljen
na blogu radi potpune arhive.
Sertifikaciono telo Privredne komore Srbije je 23. decembra u 8:53 ujutro opozvalo sertifikat koji prateći
program za pristup CROSO portalu (SecurityTray) koristi za komunikaciju između čitača kartice i portala.
Čim računar „dohvati“ novu listu opozvanih sertifikata sprečava se dalji pristup i korisnicima se prikazuje
poruka „korisnik prekinuo komunikaciju sa uređajem…“.
Istovremeno najavljene su izmene na portalu zbog kojih pristup neće raditi od 30.12. ove godine do 09.01. naredne
godine. Ne bih da zamaram tehničkim pisanjem, ali rešenje koje autori (Saga doo) koriste za vezu browsera i čitača
kartice nije adekvatno, PKS CA je u startu izdalo pogrešan sertifikat koji se ne koristi na odgovarajući način, ali
takođe smatram da je reagovanje PKS CA u ovom trenutku brzopleto. Ovim je ugroženo funkcionisanje važnog servisa za
veliki broj korisnika.
Izvod iz CRL-a (lista opozvanih sertifikata) pokazuje vreme i razlog opoziva:
Serial Number: 1A9C88C71CF9580B
Revocation Date: Dec 23 07:53:51 2016 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Kako da pristupite portalu?
Ukoliko za pristup CROSO portalu koristite Google Chrome ili Internet Explorer i pri pokušaju prijave na portal dobijate poruku
„korisnik prekinuo komunikaciju sa uređajem…“ iako je do 23. decembra sve radilo, potrebno je da ručno u pregledaču otvorite lokalni
sajt https://localhost:9876 SecurityTray aplikacije i dodate bezbednosni izuzetak za pristup
kako bi sve ponovo proradilo.
Mozilla Firefox
Firefox ovim nije pogođen jer ne radi proveru opozvanosti sertifikata putem CRL-a.1)
Možete da koristite Mozilla Firefox za pristup portalu. Ako niste ranije koristili Firefox neophodno je da instalirate sertifikate PKS CA prema
uputstvu sa CROSO sajta.
Internet Explorer
Kada otvorite https://localhost:9876 greška se prikazuje kao na slici ispod gde kao razlog greške vidimo opozvani sertifikat (engl. certificate has been revoked):
U tom slučaju, potrebno je da otvorite Internet Options, a zatim na kartici Advanced u grupi Security isključite opciju „Check for server certificate revocation*“.
Ovo je inače loša ideja (ali trenutno neophodna) pošto Internet Explorer sada za svaki sajt koji posećujete neće proveravati da li je on možda kompromitovan. U RETKOM slučaju ovo bi moglo da ugrozi vašu bezbednost pri korišćenju interneta.
Nakon promene postavki, navedeni sajt će se prikazati kao na slici ispod, što je potvrda da ste uspešno dodali izuzetak.
Možete da zatvorite prozor i nastavite rad. Ne zaboravite da nakon objavljivanja nove verzije programa za pristup portalu ponovo uključite opciju koju ste isključili kako bi vratili bezbednost na odgovarjući nivo.
Da dodate izuzetak kliknite bilo gde na sivi prostor i „na slepo“ ukucajte reč badidea
Pritiskajte slovo po slovo na tastaturi (b, a,…) iako se ništa neće dešavati i zatim pritisnite taster Enter na tastaturi.
Upozorenje će nestati i prikazaće se ekran kao na slici ispod sa crnim tekstom HTTP ERROR 404 što je potvrda da ste uspešno dodali izuzetak. Dok ovo radite ne prozivajte mene, ja samo delim savet i niti sam pravio niti sam savetovao one koji su pravili ovaj program i ovakvo rešenje.
Tehnički komentar
Opoziv kao razlog navodi „kompromitaciju ključa“ što zvuči dosta loše.
U pitanju je međutim sertifikat za lokalni server (CN=localhost) koji „obezbeđuje“ programče SecurityTray. Sertifikat i privatni ključ se nalaze u instalaciji programa koja se preuzima sa sajta portala. Privatni ključ mora da bude dostupan programčetu, što znači i da mora da bude podeljen svim korisnicima. Tu tehnički govorimo o „kompromitaciji“ (ključ je javno dostupan) iako je rešenjem to tako od početka zamišljeno.
PKS CA nikada nije trebalo ni da izdaje (potpisuje) ovakav sertifikat, a SAGA doo nije trebalo da osmisli rešenje koje zahteva da se privatni ključ deli svim korisnicima bez jasnije komunikacije sa PKS CA o uslovima pod kojima će se ključ koristiti. Jer da je bilo potpunog razumevanja između dve strane ne bi sada imali opoziv. Ali kada je sve već tako zamišljeno od početka korišćenja SecurityTray aplikacije, ne vidim čemu brzopletost opoziva bez spremnog alternativnog rešenja i obaveštavanja korisnika portala.
Rešenje je moglo da ima samopotpisani sertifikat koji će tokom instalacije biti dodat kao izuzetak u Mozilla Firefox, odnosno odgovarajući Windows Cerificate Store za Google Chrome i Internet Explorer. Za takav sertifikat nije potrenno da isti izdaje sertifikaciono telo, koje bi time eventualno kršilo sopstvenu politiku izdavanja i došlo u situaciju da isti opoziva.
Ostaje da vidimo kako će problem biti rešen sa najavljenim izmenama portala početkom januara.
1) Firefox kao i sertifikati na većini sajtova koristi drugi moderniji mehanizam za proveru pod nazivom OCSP, što PKS CA ne podržava, pa Firefox neće ni znati da je sertifikat opozvan. ↑
Nakon što je CROSO portal bio nedostupan deset dana radi pripreme nove verzije aplikacije, u ponedeljak 9. januara objavljena
je nova verzija SecurityTray aplikacije koja je u sebi sadržala ozbiljan i nedopustiv bezbednosni propust.
SecurityTray aplikacija služi da uspostavi komunikaciju između sajta portala i čitača pametnih kartica, i na taj način predstavlja
alternativu za ranije korišćene Java aplete ili Native Messaging ekstenzije.
Aplikacija prvo pokreće lokalni veb servis na računaru korisnika (localhost), a zatim koristeći
HTTP CORS mehanizam uspostavlja komunikaciju između
sajta i aplikacije preko HTTP API-ja. Na taj način sajt može da zatraži od lokalne aplikacije da koristeći midlver i karticu u čitaču
izvede operaciju elektronskog potpisivanja.
Kada se veb sajtu pristupa preko HTTPS protokola (zeleni katanac, zaštićena i šifrovana komunikacija), HTTP CORS mehanizam zahteva da
i lokalni veb servis bude obezbeđen na isti način. I tu nastaje problem, koji ne postoji u slučaju kada se koriste druga pomenuta rešenja.
Svaki HTTPS sajt ili servis, pa i ovaj lokalni koji obezbeđuje SecurityTray aplikacija, zahteva dve stvari (1) par ključeva
(tajni i javni), gde se tajni ključ čuva poverljivo i koristi u formiranju zaštićenog kanala i (2) SSL sertifikat u koji se
ugrađuje javni ključ i kojim se dokazuje identitet sajta, odnosno veb servisa.
Oba ova dela moraju da budu dostupni instaliranoj SecurityTray aplikaciji, bilo da se generišu pri prvom pokretanju ili da su pripremljeni
unapred i uključeni u instalaciju aplikacije.
Ukratko o SSL sertifikatima
SSL sertifikat poseduje dva polja kojima se dokazuje identitet sajta. Subjekat sertifikata (Subject, npr. google.com) i izdavalac sertifikata (Issuer).
Izdavalac je najčešće neko telo od poverenja (engl. Certificate Authority) koje nakon što utvrdi da je upravo na primer Google vlasnik određenog para
ključeva izdaje sertifikat. Izdati sertifikatu navodi google.com kao ime subjekta i sadrži javni ključ iz pomenutog para.
Pri povezivanju na google.com, veb pregledač dobija kopiju ovog SSL sertifikata i potom po standardima definisanoj proceduri proverava da li je izdavalac
poznat i pouzdan, da li je subjekat sertifikata upravo google.com i da li izdavalac sertifikata nije u međuvremenu opozvao sertifikat. Ukoliko je provera
uspešna, znamo da je Google vlasnik para ključeva i pregledač može da formira zaštićeni kanal.
Izdavalac može da bude i posrednik, tj. da ima svog izdavaoca, pa pri proveri SSL sertifikata uvek govorimo o proveri lanca sertifikata, gde u vrhu
(engl. root) treba da stoji poznat i pouzdan sertifikat, a svaki sertifikat iz lanca je validan u odnosu na prethodni. Krajnji sertifikati (bez CA oznake)
ne mogu da budu izdavaoci, tj. ne mogu da grade dalji lanac. SSL sertifikati su po pravilu krajnji sertifikati.
Sertifikat se smatra pouzdanim ukoliko se nalazi u tzv. Trusted Root skladištu. Veb pregledači Internet Explorer i Google Chrome na Microsoft Windows
operativnom sistemu koriste Windowsovo Trusted Root skladište, dok pregledač Mozilla Firefox koristi svoje skladište. Drugi sistemi i programi imaju
sopstvena skladišta.
Uloga izdavaoca sertifikata je da postanu deo ovih skladišta, ili da na neki drugi način postanu subjekti od poverenja (npr. postanu ovlašćeni od strane
države), i da zatim utvrđuju identitet subjekata, izdaju im sertifikate i u slučaju incidenata iste opozivaju, najčešće sve uz novčanu nadoknadu.
Pored sertifikata koje ugrađuje proizvođač, korisnik i administrator računara ili mreže mogu da dodaju i dodatne sertifikate u ova skladišta. Na primer
sertifikati domaćih sertifikacionih tela najčešće nisu uključeni u pomenuta skladišta.
Kada su u Trusted Root skladištu samo pouzdani izdavaoci sertifikata korisnik koji poseti google.com, sajt državne uprave ili sajt svoje banke i u uglu
vidi zeleni katanac kao obaveštenje da je konekcija bezbedna, odnosno ne dobije nikakvo sigurnosno upozorenje, može biti siguran da se povezao upravo na
ovaj sajt i da napadači ne mogu da presretnu lozinke, podatke, naprave lažne transakcije i slično.
Ako se u Trusted Root skladištu nalazi i neki nepouzdan izdavalac, gde napadač iako na primer nije Google može da dobije google.com sertifikat, taj napadač
bi mogao da presretne komunikaciju (npr. postavljanjem wi-fi mreže), podmetne ovaj lažni sertifikat i zatim presretne lozinke i podatke, preuzme identitet
korisnika i na razne druge načine ugrozi bezbednost korisnika.
HTTPS je u osnovi bezbednog veba i interneta, aktivno se koristi od 2000-ih godina.
Kako su otkrivani novi napadi i kako je uopšte rasla potreba korisnika da bezbedno koriste sve značajnije servise, u poslednjih 15 godina više puta su
inovirane preporuke, protkoli i standardi, a veb pregledači su postali sve striktniji u proveri validnosti SSL sertifikata.
CROSO pre 30. 12. 2016.
U ranijoj verziji pre 30. decembra 2016. godine SecurityTray aplikacija je koristila SSL sertifikat čiji je izdavalac Sertifikaciono telo Privredne komore
Srbije. Subjekat sertifikata je localhost (lokalni veb servis koji pokreće SecurityTray aplikacija). Privatni ključ koji odgovara ovom sertifikatu, što je
bilo neophodno za ovo tehničko rešenje, je bio uključen u instalaciju aplikacije.
PKS CA je jedno od nekoliko sertifikacionih tela koja su ovlašćena da izdaju kvalifikovane elektronske sertifikate za elektronski potpis.
U pitanju je vrsta elektronskog identiteta. Zakonom o elektronskom potpisu i podzakonskim aktima propisani su posebni uslovi koje ovi izdavaoci moraju
da ispunjavaju, počev od dokumentovanja politike izdavanja i postupaka rada, posebnih kadrovskih resursa, posedovanje opreme, pa do nadzora nadležnog
ministarstva.
Kvalifikovane sertifikate PKS CA izdaje u skladu sa objavljenom politikom kroz lanac izdavaoca:
PKS CA Root
PKS CA Class1 - Kvalifikovani sertifikati
izdati kvalifikovani sertifikati...
Istovremeno PKS CA izdaje SSL sertifikate kroz drugi lanac izdavaoca sa istim korenskim sertifikatom:
PKS CA Root
PKS CA Class2 - IT resursi
izdati drugi sertifikati
PKS CA ne objavljuje politiku izdavanja nekvalifikovanih sertifikata, ali bi po stručnoj praksi trebalo da je ima.
Pravilnik o bližim uslovima za izdavanje sertifikata, Sl. glasnik RS, br. 26/2008
Važeći podzakonski pravilnik nije sasvim jasan u vezi sa tim da li je dozvoljeno iz iste PKI hijerarhije (PKS CA Root) formirati podređena CA koja
izdaju kvalifikovane i nekvalifikovane sertifikate, ali recimo da bi doslovna primena spornog člana bila nemoguća, a da postoji i sertifikaciono telo
koje različite vrste sertifikata izdaje istim sertifikatom.
Uobičajna upotreba SSL sertifikata je da subjekat sertifikata čuva privatni ključ u tajnosti. Politike sertifikacionih tela takođe najčešće
predviđaju da ukoliko dođe do kompromitacije privatnog ključa odgovarajući sertifikat odmah bude opozvan.
Privatni ključ localhost sertifikata koji se koristi u SecurityTray aplikaciji je bio uključen u javno objavljenu instalaciju aplikacije od samog
početka, ali moguće da je PKS CA toga postalo svesno tek 23. decembra ujutro kada je sertifikat opozvan navodeći upravo kompromitaciju ključa.
Slažem se sa komentarima koji su se mogli čuti tada da PKS CA kao jedan od ovlašćenih izdavalaca kvalifikovanih elektronskih sertifikata ima previše
važnu ulogu i da izdavanje ovakvog sertifikata (nepoznati subjekat, javno dostupan privatni ključ) čak i da je u skladu sa politikom PKS CA može da
omogući neočekivane zloupotrebe. Sa te strane reakcija PKS CA je odgovarajuća. Činjenica da je takav sertifikat ipak bio izdat, a onda opozvan,
pokazuje kako je nešto svakako zaškripalo u komunikaciji. Kako bilo, tog petka korisnici koji su koristili Internet Explorer ili Google Chrome su se
suočili sa time da ne mogu više da pristupe CROSO portalu.
Sedam dana kasnije pristup portalu je ograničen radi najavljenih izmena.
CROSO 9. januara 2017.
Nakon deset dana pauze, objavljena je nova verzija SecurityTray aplikacije koja više nije koristila sertifikat PKS CA, već nešto mnogo gore.
Aplikacija je bez znanja korisnika u Trusted Root skladište dodavala svoj CA sertifikat koji može da izdaje druge sertifikate, menjajući ono
što je do tada za njih radilo PKS CA. Privatni ključ ovog CA sertifikata je bez ikakve potrebe bio takođe uključen u instalaciju.
Napadač je mogao da iskoristi javno dostupan privatni ključ i da napravi bilo koji lažni SSL sertifikat.
Primer lažnog google.rs sertifikata koji bi napadač mogao da iskoristi
Na računarima svih korisnika koji bi instalirali SecurityTray aplikaciju bi takav lažni sertifikat bio označen kao pouzdan, što bi napadač mogao
da iskoristi da ukrade lozinke, podatke ili preuzme identitet korisnika pri korišćenju servisa na internetu, e-bankarstvu, e-upravi i slično.
Problem bi postojao i u slučaju da privatni ključ CA sertifikata nije bio uključen u instalaciju, ali je ovim svakako postao očigledniji. Fomiranje
sertifikacionog tela, naročito kada se taj novi sertifikat dodaje u Trusted Root velikog broja korisnika zahteva posebne mere bezbednosti u vezi za
celokupnim životnim ciklusom tajnog ključa i visok stepen profesionalne odgovornosti. Sve i da privatni ključ nije bio očigledno javno objavljen,
korisnici ne mogu da znaju kako je ključ nastao, gde je sve završila njegova kopija i ko bi mogao da ga zloupotrebi. To što je ključ objavljen, na neki
način je ispala srećna okolnost jer je izazvalo brzu i efikasnu reakciju.
Prijavu incidenta poslao sam nešto pre 15 časova na više adresa, uključujući MTT, RATEL,
kao i na kontakt adrese autora softvera do kojih sam uspeo da dođem.
Sutradan 10. januara nešto posle 13 časova isključen je pristup CROSO portalu, a već 11. januara pojavila se nova verzija SecurityTray aplikacije. Želeo
bih da zahvalim Savi Saviću ispred Ministarstva za razumevanje ozbiljnosti situacije i angažovanje da se u saradnji sa zaposlenima u CROSO-u i dobavljačima
aplikacije problem brzo otkloni.
Nova verzija SecurityTray aplikacije koristi samopotpisani krajnji sertifikat, bez dodavanja sertifikata u Trusted Root čime se sprečava mogućnost da ga
napadač iskoristi za izdavanje drugih sertifikata.
Kako sertifikat nema izdavaoca, mora se definisati sigurnosni izuzetak kako bi se ovaj sertifikat bez izdavaoca označio kao pouzdan. Internet Explorer dozvoljava
CORS mehanizam i kada localhost sertifikat nije validan, pa nije potrebna dalja aktivnost korisnika, a uputstvo za korisnike pregledača Google Chrome i Mozilla
Firefox objašnjava kako je moguće ručno dodati izuzetak.
Instalacija nove verzije uklanja CA sertifikat iz Windowsovog Trusted Root skladišta koji je bio dodat prethodnom instalacijom. Za korisnike Mozilla Firefox
pregledača koji su ovaj sertifikat ručno dodali po uputstvu su upućeni kako da sada isti ručno obrišu kako bi povratili bezbednost u korišćenju interneta.
Zaključak o servisima e-uprave
Ne bih dodatno komentarisao kako ovakav propust uopšte može da se dogodi i zašto kritični servisi e-uprave ne prolaze kroz dodatne provere pre nego što se
neadekvatna rešenja objave korisnicima. Činjenica da servis može da bude nedostupan 10 dana radi izmena, ukazuje i na nepostojeći ili loše zamišljeni
plan kontinuiteta.
Na ozbiljan propust sam morao da ukažem i početkom 2014. godine kada je portalu ePorezi Poreske uprave moglo da se pristupi bez ikakve autentikacije, zaobilazeći
očitavanje podataka sa pametne kartice, prostim unošenjem JMBG osobe u čije ime se pristupa. I pored direktnog sastanka u PU za rešavanje tog problema tada bilo
je trebalo znatno duže vremena koje se ne meri danima već, neverovatno, mesecima.
Osim neozbiljnosti u implementaciji važnih servisa i nedovoljne kadrovske posvećenosti, uočljiv je još jedan problem. IT se često menja, objavljuju se nove
verzije softvera, ispravljaju se do tada nepoznati propusti i menja preporučena praksa. Određeno rešenje e-uprave namenjeno opštoj javnosti i korisnicima koji
imaju svoje računare, koje koriste na različite načine ne može da se uvede i zaboravi, već mora da se ažurira, menja i prilagođava novim okolnostima.
Situacije u kojima prolaze godine pre nego što se rešenje prilagodi na novu verziju Jave, pa korisnici moraju da ukidaju bezbednosne zaštite i ugrožavaju
svoj računar i podatke, ili gde neke aplikacije e-uprave ne podržavaju Windows 10 ni dve i po godine nakon njegovog objavljivanja prosto nisu dopustive.
Stoji i opaska kako skoro svi uvedeni servisi zahtevaju računar i Windows operativni sistem. Kao da korisnici drugih platformi nemaju pravo na e-upravu.
Podrška za m-government se najavljuje kao nešto potpuno novo. Nadam se da je to šansa da upravo postojeća veb rešenja budu zamišljena tako da rade na svim
platformama i operativnim sistemima, a ne kao alternativa zasnovana na SMS-u i USSD kodovima.
Ne mogu da se ne setim i situacije sa uslugom zamene saobraćajne dozvole na portalu eUprava, koja mi je posebno bliska jer je dobavljač iskoristio moje
open-source rešenje za čitanje lične karte. Nakon toga u avgustu 2014. godine MUP je počeo da izdaje nove lične karte, a već u septembru sam objavio novu
verziju open-source koda. Rešenje na portalu eUprava nije ažurirano sve do polovine 2015. godine, čime je svima sa novim ličnim kartama onemogućena zamena
saobraćajne preko portala. Čak i tada Java aplet nije ispravno potpisan, pa je za učitavanje i korišćenje usluge potrebno posebno podešavanje računara i
isključivanje bezbednosnih postavki.
Najnoviji CROSO SecurityTray
Poslednje tehničko rešenje SecurityTray aplikacije je primereno svrsi i ne ugrožava bezbednost korisnika, ali je korisnički doživljaj pri korišćenju mogao
da bude bolji.
Najpre, instalaciona procedura je mogla samopotpisani localhost sertifikat da doda u Windowsova skladišta Trusted People i Other People. Trusted People
je dokumentovano skladište za dodavanje izuzetka za samopotpisane sertifikate koji inače ne učestvuju u proveri i formiranju lanca.
Trusted People
Certificates issued to people or end entities that are explicitly trusted. Most often these are self-signed certificates or certificates explicitly
trusted in an application such as Microsoft Outlook
U ovom slučaju korisnici ne bi morali da isključuju postavke u Google Chrome pregledaču, a smanjuje se rizik da neka nadogradnja Windowsa ili Internet Explorera 11
spreči komunikaciju između lokalnog servisa i veb sajta u ovom pregledaču.
Za Mozilla Firefox, preporučeno rešenje za programersko dodavanje izuzetka jeste ubacivanje sertifikata u Servers listu NSS skladišta (kako bi sertifikat bio dostupan)
i upisivanje njegovog otiska u datoteku cert_override.txt
unutar korisničkog profila. Takođe, kada bi instalacija ovo radila automatski, izbegava se potreba za ručnom intervencijom korisnika.
Automatsko dodavanje izuzetka, bez intervencije korisnika
Zadovoljstvo korisnika bi bilo bolje i ako bi programeri u lokalni HTTPS server i njegov HTTP API dodali / rutu sa nekom razumnom porukom, tipa
„Instalacija SecurityTray aplikacije je uspešna“ uz eventualnu mogućnost dijagnostike komunikacije sa čitačem. Korisnici bi tako mogli da provere instalaciju aplikacije,
te da li podešavanja eventualnog lokalnog firewalla ili antivirusa ometaju njen rad. Trenutno rešenje predviđa da se korisnicima ili prikazuje greška HTTP 404 kao
potvrda da aplikacija radi (!) ili pun ekran đubreta koje se ispisuje kada se pristupi /getTicket stranici lokalnog servisa.
Zapakovao sam jednostavno programče koje omogućava uklanjanje (brisanje) e-potpisa iz PDF dokumenta.
Program može biti koristan u situaciji ukoliko je pri potpisivanju dokumenta uključena opcija „Lock Document After Signing“ uz koju Adobe Reader DC
neće dozvoliti dodavanje novog potpisa. Upotrebom programčeta možete da uklonite e-potpise iz PDF dokumenta i da ga zatim ponovo potpišete.
Ukoliko je dokument potpisan vidljivim potpisom, sličica će ostati u vidljiva ali više neće imati pridruženi e-potpis u Signature Panelu.
Program u verziji za Microsoft Windows možete da preuzmete ispod.
A simple tool to easily remove all PDF digital signatures from the Signature Panel
Za GNU/Linux i druge operativne sisteme, dostupan je Java jar paket unsignpdf.jar.
Program se pokreće bez instalacije, ali zahteva da na računaru imate instaliranu Javu. Upotreba je jednostavna. Po pokretanju
odaberite PDF dokument i zatim unesite ime kako želite da sačuvate dokument bez potpisa.
Ovaj program zapravo koristi gotov primer FlattenSignature.java iz dokumentacijeiText
projekta, popularne Java biblioteke za rad sa PDF dokumentima.
Sličan rezultat se može postići i „štampanjem“ PDF dokumenta u novi PDF dokument.
Informacioni sistem APR-a za dostavljanje finansijskih izveštaja ove godine dolazi sa
novom klijentskom aplikacijom NexU-APR koja se koristi za pristup kriptografskom uređaju
za formiranje potpisa (token ili pametna kartica). Kako autori opisuju:
Ovo je aplikacija za formiranje elektronski potpisanih dokumenata iz internet pregledača,
na klijentskoj strani. Rešenje je bazirano na DSS radnom okviru i NexU aplikaciji, čiji je naručilac
Evropska komisija, a implementator kompanija Nowina Solutions.
Evropski Digital Signature Service je projekat slobodnog
softvera koji nudi sveobuhvatno rešenje za izradu, proveru i čuvanje elektronskih potpisa u različitim
formatima. Poseban akcenat projekta je priprema potpisanih dokumenata za dugoročno arhiviranje.
Klijentska aplikacija NexU izvorno podržava Microsoft Windows, GNU/Linux i macOS, ali je u domaćoj
verziji aplikacija zvanično podržana samo na Windowsu, i to verzijama nakon XP-a.
Ipak, programeri su ostavili konfiguraciju za učitavanje midlvera Pošte na GNU/Linuxu. Sertifikaciono
telo Pošte je jedino domaće sertifikaciono telo koje izdaje kvalifikovane sertifikate za elektronski
potpis (KES) sa midlverom koji radi na macOS-u i GNU/Linuxu.
To znači da je informacioni sistem APR-a i potpisivanje dokumenata preko aplikacije moguće koristiti
i na GNU/Linuxu. Bez ikakvih izmena prepakovao sam aplikaciju NexU-APR i priredio instalacioni paket
za Debian/Ubuntu koji sadrži i zgodnu skripticu za pokretanje. Dostupna je i obična .tar.gz arhiva za
ostale distribucije. Moguće bi bilo napraviti i macOS instalaciju, ali nemam hardver na kome bi to učinio.
SafeSign midlver
Za korišćenje aplikacije je neophodno da instalirate AET SafeSign midlver koji tražite od Pošte.
Alternativno instalaciju midlvera možete naći i na internetu, najčešće na brazilskim sajtovima gde
je državno korišćenje GNU/Linuxa daleko veće nego kod nas.
Poslednja verzija midlvera koju ja imam je dosta stara 3.0.97 i na novijim Ubuntu distribucijama
potrebno je instalirati stare libtiff4, libwxbase2.8 i libwxgtk2.8 pakete. Oni se takođe lako
pronalaze na pomenutim sajtovima. Pokrenite tokenadmin da proverite instalaciju čitača i midlvera,
te da li vidite sertifikat u listi.
Za druge distribucije dostupna je obična arhiva NexUApr-1.0.tar.gz
koju preporučujem da raspakujete u /opt kako ne bi morali da menjate putanje u skripti za pokretanje.
Program zahteva java-jre i zenity, a midlver traži još i pcscd.
Nakon instalacije pokrenite NexUApr prečicu. Aplikacija pri prvom pokretanju generiše par ključeva i samopotpisani
localhost sertifikat koji je potrebno da dodate u veb pregledaču. Alternativno možete dodati sigurnosni
izuzetak bez instalacije sertifikata.
Korišćenje samopotpisanog sertifikata i klijentske aplikacije je postalo uobičajno rešenje umesto ranije korišćenih
Java apleta. Sertifikat je neophodan kako bi se ostvarila komunikacija između veb aplikacije na HTTPS protokolu i
lokalnog servera koji time mora takođe da implementira HTTPS protokol. Par ključeva i sertifikat mogu biti generisani
unapred (zajednički za sve korisnike) što olakšava instalaciju (kod nas primer je CROSO) ili kao u slučaju NexU
aplikacije da se generišu pri prvom pokretanju. Aplikacija bi teorijski mogla da sertifikat/izuzetak postavi samostalno,
bez potrebe za intervencijom korisnika, ali u praksi postoji prevelika raznolikost odgovarajućih skladišta, putanja
instalacije, profila i verzija veb pregledača.
Rešenja zasnovana na Native Messaging tehnologiji
ne traže dodavanje izuzetaka, ali umesto jedne komponente (klijentska aplikacija) dolaze u dva dela (aplikacija i
ekstenzija za veb pregledač) pa je potrebno posebno pakovanje za Chrome, Firefox, Edge (ako postane podržan).
Vratimo se APR aplikaciji, pri pokretanju skripta će prikazati sledeće prozorče:
Bezbednosno obe opcije su jednake i u ovom slučaju ne predstavljaju rizik. Ako odaberete opciju da dodate izuzetak
prikazaće se localhost link koji treba da otvorite u veb pregledaču. Mozilla Firefox nudi opciju dodavanja izuzetka
nakon što kliknete na dugme Advanced pa Add Exception, dok Google Chrome traži da „na slepo“ ukucate
badidea.
Nakon što dodate izuzetak umesto upozorenja, prikazaće se ikonica aplikacije. To je potvrda da je komunikacija omogućena.
Ukoliko se opredelite da instalirate sertifikat, sačuvajte datoteku i zatim iz terminala programom
certutil dodajte sertifikat u odgovrajuće skladište za Google Chrome, odnosno Mozilla Firefox.
Skoro sigurno će biti lakše dodati izuzetak, a u Firefoxu između dva i ne postoji razlika pošto dodavanje
izuzetka zapravo upravo dodaje sertifikat aplikacije.
Kada ste završili instalaciju možete da pristupite APR aplikaciji za elektronsko potpisivanje
dokumenata. Otvorite stranicu aplikacije i klikom naPokreni potpisivanje možete da odaberete PDF ili XML datoteku sa računara.
U prozoru za izbor tokena trebalo bi da već bude prepoznato sertifikaciono telo Pošte, zajedno sa parametrima za pristup
midlveru (/usr/lib/libaetpkss.so.3).
Unesite PIN, izaberite sertifikat i sačuvajte potpisani dokument. Detaljnu proveru potpisa možete
da obavite preko demo instalacije aplikacije za validaciju
iz pomenutog evropskog DSS ili na Windowsu u programu Adobe Reader.
Slobodan softver uglavnom podržava proveru i zanavljanje potpisa na strani servera, ili su u pitanju rešenja namenjena drugim
programerima. Gotovi programi namenjeni korisnicima su malobrojni. Za izradu potpisanog PDF-a mogu da se koriste programi LibreOffice i
jSignPdf.
Program pdfsig iz projekta poppler ima osnovnu PAdES implementaciju.
Ukoliko bi se podrška unapredila, potpis bi mogao da bude prikazivan i validiran direktno u popularnim programima za prikaz PDF dokumenata kao što su evince ili kpdf.
Nešto bolja podrška od nedavno postoji u LibreOfficu, ali ni on nije u mogućnosti da validira potpis iz APR-a.
Neobično je što dokument potpisan na ovaj način nema ugrađen vremenski žig što bi APR svakako bio u mogućnosti da obezbedi u okviru
postojeće državne infrastrukture, za razliku od korisnika koji tu uslugu moraju dodatno da plate. Na taj način bi se izbegla
situacija da potpis prestaje da važi istekom ili opozivom sertifikata što se kod nekih drugih e-servisa (Fond PIO) već javljalo kao
problem iz prakse. Potpisani dokument sadrži lanac sertifikata i podatke za proveru, u slučaju Pošte kao OCSP odgovor. Potpis se dodaje
kao „nevidljivi“ potpis i odnosi se na ceo dokument.
Klijentska aplikacija NexU-APR nije ogovarajuće podešena za korisnike 64bitne verzije Windowsa,
kada se koristi PKCS#11 kao metod pristupa tokenu, a posebno problem imaju korisnici sertifikata
sertifikacionog tela Halcom čak i kada instaliraju novu verziju Nexus Personal midlvera.
Kod 32bitnog Windowsa svi programi i komponente su 32bitni pa ne dolazi do zabune. Međutim kod
64bitnog Windowsa moguće je pokretati i 32bitne i 64bitne programe pa je potrebno tačno upariti
Javu, klijentsku aplikaciju i PKCS#11 modul.
NexU-APR aplikacija dolazi sa sopstvenom instalacijom Jave. Zato instalacioni paket ima čak 80
megabajta, ali je zgodno što će makar Java biti ispravno podešena. Ova verzija
Jave je 32bitna, pa bez obzira imate li 64bitni ili 32bitni Windows kada instalirate i pokrenete
NexU-APR aplikaciju koristićete 32bitnu Javu. To će nam kasnije biti značajno.
Instalacija midlvera
Instalacije midlvera uglavnom dolaze u različitoj varijanti za 32bitni i 64bitni Windows (AET SafeSign
za korisnike Pošte, TrustEdgeID za PKS/MUP/Vojsku, te RSIDCardMW za stare lične karte). Ukoliko
koristite 64bitni Windows potrebno je da instalirate 64bitnu verziju instalacije midlvera.
Nexus Personal za Halcom sertifikate u sebi sadrži obe verzije, dok IDPrime za korisnike sertifikacionog
tela E-Smart ima deo koji zavisi od „bitnosti“ sistema, i zajedničku instalaciju za PKCS#11 modul.
TrustEdgeID dolazi u dve verzije, postoji stara verzija koja ima odvojenu instalaciju za PKS i MUP, te
nova verzija (dostupna sa sajtova sertifikacionog tela PKS i Vojske) koja podržava rad sa karticama
i tokenima sva tri tela. Instalacija nove zajedničke verzije uklanja odvojene instalacije.
PKCS#11 moduli
Sve pomenute 64bitne instalacije midlvera kada se instaliraju u sebi sadrže i 32bitnu i 64bitnu verziju
PKCS#11 modula. U pitanju je .dll datoteka koja se nakon instalacije nalazi negde na računaru. Ovaj modul
se najčešće naslanja na Windows i midlver sa kojim korisnik interaguje preko nekog pomoćnog programa
(npr. Token Manager, Token Administrator,…).
Drugi programi (Mozilla Firefox ili u ovom slučaju NexU-APR) mogu da učitaju PKCS#11 modul i tako koriste
pametnu karticu ili token za kriptografske operacije. Na taj način programi mogu da podrže različite uređaje,
pod uslovom da uređaj poseduje ispravan PKCS#11 modul koji korisnik može da učita u program.
Tehnička napomena za programere aplikacija...
Alternativa PKCS#11 modulima je da programi koriste uslugu Windows operativnog sistema (u NexU-APR aplikaciji
ovo je opcija „Microsoft skladište ključeva“) kada se zaobilazi PKCS#11 modul i tokenima pristupa kroz
Microsoft CryptoAPI (skraćeno MS-CAPI).
Sa oba je moguće postići sličan rezultat, a izbor uglavnom zavisi od mogućnosti tehnologije kojom se pravi
aplikacija. Midlveri za tokene i kartice koje koriste domaća sertifikaciona tela podržavaju oba interfejsa,
iako bi teorijski mogao da postoji token koji ima samo PKCS#11 ili samo MS-CAPI podršku. Pristupom kroz PKCS#11
veći akcenat se stavlja na uređaj koji sadrži objekte (ključevi, sertifikati) i nudi operacije. Pristupom kroz
MS-CAPI dobija se lista instaliranih sertifikata u Personal skladištu, bez obzira u kom uređaju se nalaze, a
operacije sprovodi operativni sistem preko registrovanog midlvera.
Programi koji učitavaju PKCS#11 module mogu da rade i na drugim operativnim sistemima (pod uslovom da je i
odgovarajući PKCS#11 modul dostupan za taj sistem), dok je MS-CAPI interfejs dostupan samo na Windowsu.
Midlver može da ima različiti kvalitet implementacije ova dva interfejsa, pa tako neki token može da radi
pouzdano kada mu se pristupa kroz MS-CAPI, a da izaziva rušenje aplikacije kada korisnik pokuša da koristi
PKCS#11 modul. Ili može da ne vidi ili prikazuje ranije uočene sertifikate kroz MS-CAPI, a da sasvim ispravno
radi kroz PKCS#11 interfejs.
Kada se koristi MS-CAPI u kombinaciji sa pametnim karticama i tokenima Windows automatski poziva midlver prema
ATR vrednosti, dok u slučaju PKCS#11 interfejsa taj deo mora da odradi aplikacija ili da prepusti korisniku da
ručno izabere modul.
Izbor PKCS#11 modula u NexU-APR aplikaciji
Kako se NexU-APR pokreće 32bitnom Javom bez obzira da li koristite 32bitni ili 64bitni Windows, potrebno je da se
u aplikaciji odabere 32bitni PKCS#11 modul.
Kada koristite 32bitni Windows situacija je jasna - sve je 32bitno i problema nema. Ali ako imate 64bitni Windows,
potrebno je da prvo instalirate 64bitnu instalaciju midlvera, ali zatim da u NexU-APR aplikaciji odaberete putanju
za 32bitni PKCS#11 modul! Ako bi u tom slučaju pokušali da u NexU-APR aplikaciji odaberete 64bitni modul prikazaće
se greška:
Opis greške nije tačan. Greška se javlja jer biblioteka ne odgovara Javi (koja je 32bitna), a ne zato što
ne odgovara sistemu.
Putanja do 32bitnog PKCS#11 modula može da se razlikuje na 32bitnom i na 64bitnom sistemu. Zato evropski projekat DSS
NexU na kome je zasnovana APR-ova aplikacija omogućava programerima da u konfiguraciji aplikacije navedu jednu
putanju do 32bitnog PKCS#11 modula na 32bitnom i drugu do istog modula na 64bitnom Windowsu. Kada se ispravno podesi,
olakšava se korisnicima jer se automatski bira prava putanja. Međutim programeri koji su priredili
APR-ovu aplikaciju su ovo izgleda pogrešno razumeli i u drugom slučaju naveli putanje do 64bitnih modula što dovodi do gore
prikazane greške.
Igrom slučaja, izuzev kod Halcoma, kod svih su putanje do 32bitnog modula iste i na 32bitnom i na 64bitnom Windowsu.
To znači da ako koristite 64bitni Windows, dok programeri ne isprave konfiguraciju, u NexU-APR aplikaciji obavezno kliknite na
detaljna podešavanja i zatim izaberite 32bitnu varijantu odgovarajućeg modula pre nego što nastavite.
Korisnici Halcom sertifikata moraju da izmene putanju, pošto se tu razlikuju i nije moguće da se na 64bitnom Windowsu samo izabere ponuđena 32bitna putanja.
Tačne putanje do 32bitnog PKCS#11 modula za midlvere tokena sertifikacionih tela u Srbiji su date u tabeli.
Naziv midlvera
32bitni modul na 32bitnom Windowsu
32bitni modul na 64bitnom Windowsu
AET SafeSign (Pošta)
C:\Windows\System32\aetpkss1.dll
(koristi se ista putanja, vidi napomenu)
Nexus Personal (Halcom)
C:\Program Files\Personal\bin\personal.dll
C:\Program Files (x86)\Personal\bin\personal.dll
RSID Card MW (MUP, lične karte pre 18.8.2014)
C:\Program Files\MUP RS\Republic of Serbia ID Card Middleware\rsidp11_x86.dll
Napomena: U slučaju AET SafeSign midlvera na 64bitnoj Windows instalaciji Windows-on-Windows podsistem automatski
vrši prepravku putanje sa C:\Windows\System32\aetpkss1.dll na C:\Windows\SysWOW64\aetpkss1.dll. Zato korisnici Pošte
nemaju posebne 32bitne i 64bitne putanje.
Da izmenite podešavanja, na primer za MUP, izaberite u listi Sertifikaciono telo MUP Republike Srbije pa kliknite na Detaljna podešavanja. Zatim odaberite TrustEdgeID - 64bit kako bi popravili tu putanju, pa kliknite naIzmeni. U prozorčetu koje će se otvoriti kliknite na dugme Odaberi, a potom u polje na dnu kopirajte putanju
iz tabele.
Potvrdite klikom na Open ili Otvori i zatim kliknite na Prihvati.
Postoji i donekle jednostavan način da trajno ispravite sve putanje odjednom.
Preuzmite ovu ZIP arhivu i otvorite je. U njoj se nalazi XML datoteka sa podešavanjima koja ćemo ubaciti u NexU aplikaciju. Ukoliko je aplikacija pokrenuta, najpre zatvorite NexU desnim klikom na ikonicu pored sata, pa iz menija izaberite Izlaz i sačekajte da ikonica nestane.
Sada treba da otvorimo fasciklu (folder) sa podešavanjima NexU aplikacije i to tako što na tastaturi istovremeno pritisnete Win taster i taster R, ili iz Start menija odaberite opciju Run/Pokreni. Kopirajte%userprofile%\.NexUApr u polje za unos i kliknite Ok, odnosno U redu.
Ukoliko uradite tako, otvoriće se fascikla sa NexU podešavanjima.
Prevucite XML datoteku iz ZIP arhive u fasciklu sa podešavanjima NexU aplikacije, menjajući postojeću. Pokrenite ponovo NexU
aplikaciju i sve putanje će biti ispravne, a među putanjama za Sertifikaciono telo MUP-a dobićete i dodatnu opciju sa putanjom
za novi TrustEdgeID midlver.
Novi TrustEdgeID midlver
Novi zajednički TrustEdgeID midlver podržava nove lične karte (od 18.8.2014), kartice i tokene Privredne komore Srbije i
sertifikacionog tela Vojske Srbije. Dostupan je za preuzimanje sa sajtova PKS i Vojske, a njegova instalacija će obrisati
prethodne odvojene instalacije za MUP i PKS, pa postojeće putanje u NexU aplikaciji neće raditi.
Pri pravljenju liste dostupnih sertifikata NexU-APR aplikacija prihvata samo one sertifikate koji odgovaraju izabranom
sertifikacionom telu, dok će ostali sertifikati biti prikazani sa crvenim kružićem kao nevalidni.
To znači da ukoliko koristite zajednički midlver u NexU-APR aplikaciji morate da dodate i opciju sa putanjom do zajedničkog modula prema tabeli iznad, unutar ponuđenih putanja za Sertifikaciono telo MUP Republike Srbije.
Ove putanje već postoje među ponuđenima za PKS pa tu neće biti problema.
Aplikacija NexU-APR nema podršku za sertifikate koje izdaje sertifikaciono telo Vojske Srbije kada se koristi PKCS#11 kao
metod pristupa tokenu. Moguće da podrška postoji kada se koristi Windows skladište sertifikata. Do sada nikada nisam
video dokument potpisan takvim sertifikatom i ne znam kome su sertifikati dodeljeni niti koliko ih je izdato.
Oznaka slota
Kod PKCS#11 modula oznaka slota zavisno od implementacije modula može da označava redni broj čitača kartica ili tokena,
ili redni broj kontejnera unutar jednog tokena ili kartice.
Ukoliko koristite više čitača kartica na računaru, ili ste nekada imali drugi čitač, ili koristite tokene (što je zapravo
čitač kartica i kartica spojeno u jednom uređaju) najverovatnije ćete morati da podešavate i slot. Nažalost, mislim da nema
lakog načina da saznate pravu vrednost već morate da isprobavate.
Isprobajte uvek najpre slot 0.
Ako se prikaže ova greška, a sigurni ste da ste izabrali pravo sertifikaciono telo i vidite sertifikate
u pratećoj aplikaciji (Token Administrator, Token Manager, Nexus Personal...) znači da aplikacija traži
sertifikate na pogrešnom mestu, pa povećajte slot za 1 i pokušajte ponovo.
Ako se prikaže ovakva greška, znači da smo preterali sve slotove (obratite pažnju na deo poruke
„but token only has ... slots“), pa smanjite slot za 1 i pokušajte ponovo.
Zavisno od redosleda korišćenja tokena i kartica oznaka slota može da se promeni. Ne mora da znači da token koji
je ranije radio sa slot 1, sada neće zahtevati slot 0 i obrnuto.
Biću zahvalan ako u komentaru napišite efikasniji način da se odredi prava vrednost slota, posebno ako imate
programersko iskustvo u radu sa PKCS#11 modulima.
Stari sertifikati MUPCA u kojima je kao izdavalac upisan „MUPCA Građani“ ili „MUPCA Građani 2“ imaju poznati
propust gde su serijski brojevi sertifikata neispavno zapisani sa vodećim nulama, suprotno standardu za X.509
sertifikate i pravilima ASN.1 kodiranja. Za problem se zna od 2010. godine. MUP je 2014. godine prešao na nove sertifikate i oni u kojima je kao izdavalac upisan „MUPCA Građani 3“ su
ispravni i nemaju ovaj problem.
Nije mi poznato koliko starih sertifikata je još uvek važeće, niti da li je moguće dobiti novi sertifikat na
ličnoj karti sa starim čipom (kartice izdate pre 18.8.2014).
Problem sa starim sertifikatima u nekim programima sprečava njihovo korišćenje. Za korišćenje u
bilo kom programu zasnovanom na openssl biblioteci (na primer prijava klijentskim sertifikatom na veb serveru)
potrebno je koristiti posebno prepravljenu openssl biblioteku.
Nova verzija Jave 8u121 objavljena 17. januara ove godine kao ispravku nepovezanog sigurnosnog propusta dodaje
i proveru koja ove stare sertifikate čini neupotrebljivim u programima zasnovanim na Javi. Izmena nosi oznaku
JDK-8168714 i uključena je u Java 8 u121, Java 7 u131, Java 6 u141 i sva novija izdanja, uključujući i OpenJDK
distribuciju Jave.
More checks added to DER encoding parsing code
to catch various encoding errors. In addition, signatures which contain constructed indefinite length encoding will now lead to IOException during parsing. Note that signatures generated using JDK default providers are not affected by this change. (JDK-8168714)
Za korisnike ovo znači da kada se izvrši ažuriranje Jave servisi ePorezi ili CROSO više ne rade sa starim sertifikatima MUP-a koji
kao izdavaoca imaju MUPCA Građani ili MUPCA Građani 2. Na servisu ePorezi ne vidi se konkretna greška već uopštena poruka „Na kartici
ne postoji sertifikat sa podacima o JMBG“ koja može da označava i druge probleme. Na CROSO portalu se prikazuje tačna greška
„Invalid encoding: redundant leading 0s“ koja nam ukazuje na problem.
Rešenje je zamena sertifikata novim čiji je izdavalac MUPCA Građani 3, ili privremeno vraćanje Jave na stariju verziju 8u112.
Instalacija starije Java 8u112 za Windows je dostupna ovde
ili prateći Java Archive link na zvaničnom Oracle sajtu.
Java veb aplikacije
Nadogradnja Java okruženja će pogoditi i sve veb aplikacije koje čuvaju, primaju ili validiraju sertifikate i potpise.
Problem možemo da ilustrujemo trivijalnim kodom koji učitava X.509 sertifikat:
import java.io.FileInputStream;
import java.security.cert.Certificate;
import java.security.cert.CertificateFactory;
public class LoadCert {
public static void main(String args[]) throws Exception {
FileInputStream in = new FileInputStream(args[0]);
CertificateFactory cf = CertificateFactory.getInstance("X.509");
Certificate trust = cf.generateCertificate(in);
System.out.println("ok");
}
}
$ java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu1.16.10.2-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)
$ java LoadCert MUPCARoot.crt
Exception in thread "main" java.security.cert.CertificateParsingException: java.io.IOException: Invalid encoding: redundant leading 0s
at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:169)
at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1804)
at sun.security.x509.X509CertImpl.<init>(X509CertImpl.java:195)
at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:102)
at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:339)
at MainClass.main(MainClass.java:27)
Caused by: java.io.IOException: Invalid encoding: redundant leading 0s
at sun.security.util.DerInputBuffer.getBigInteger(DerInputBuffer.java:152)
at sun.security.util.DerValue.getBigInteger(DerValue.java:512)
at sun.security.x509.SerialNumber.construct(SerialNumber.java:44)
at sun.security.x509.SerialNumber.<init>(SerialNumber.java:86)
at sun.security.x509.CertificateSerialNumber.<init>(CertificateSerialNumber.java:102)
at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:643)
at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:167)
... 5 more
$ java LoadCert MUPCARoot3.crt
ok
Na staroj verziji Jave 8u112, oba sertifikata se ispravno učitavaju:
$ $JAVA_HOME/bin/java -version
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
$ java LoadCert MUPCARoot.crt
ok
$ java LoadCert MUPCARoot3.crt
ok
Moguće zaobilazno rešenje je prirediti poseban JRE koji ne sadrži proveru dodatu kroz JDK-8168714, ali sadrži druge bezbednosne ispravke.
Ispravka dolazi u sigurnosnim nadogradnjama za RHEL verzija 5, 6 i 7 kao i za sve druge poznate
distribucije, odnosno drugi softver koji sadrži zakrpu za CVE-2016-5546, pa se može dogoditi da se
verzija Jave nadogradi i ako ne menjate postavke svoje aplikacije.