Nova Java i stari sertifikati MUPCA
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.
Ovaj citat odlično opisuje situaciju:
4 komentara
24 feb 2017 shomi
gorane, jos jednom svaka cast, molim te napravi mailing listu da se prijavim :)
Jedno pitanje, zbog cega je jedino Adobe reader DC jedini eksterni software koji APR prihvata za potpis, uz dodatna podesavanja? U mail prepisci sam sa Foxit-om, kako bi i oni omogucili, da uz dodatna podesavanja, noviji Foxit proizvodi budu OK za APR. Koliko sam ja razumeo i tako im napomenuo, problem je PAdES modul/standard, koji je postavljen kao musthave umesto PKCS#7. Ako gresim, ti ces vrv odmah znati :) Oni su mi u poslednjem mailu, trazili da im izvezem i posaljem neki privatni kljuc radi dodatne analize, sto sam nakon provere sa MUP i POSTOM, potvrdio misljenje da je nemoguce i opasno u svakom slucaju, jer su u pitanju kvalifikovani sertifikati na nekom mediju. Sta jos da im napomenem i naglasim, da bi znali da njihov software urade prihvatljivim za APR? Prosle godine su dokumenta potpisivana sa Foxitom se kacila bez problema na APR.
Hvala,
MIlos
27 feb 2017 Goran
Miloše, tačno ste napisali, sve što je potrebno je da program podrži potpisivanje u odgovarajućem PAdES profilu PAdES-BASELINE-B. U pitanju je format dokumentovan u ETSI standarima i tehničkim dokumentima, na primer ETSI EN 319 142-1. Sa druge strane u pitanju je relativno obiman posao.
Programerima za implementaciju formata svakako ne treba vaš privatni ključ, a sve i da želite da im ga neodgovorno pošaljete, kada je ključ pouzdano smešten u pametnoj kartici ili tokenu, niste ni u mogućnosti da to uradite.
15 mar 2017 Владимир Јанковић
Горане, срдачно се захваљујем на труду да објасните разлоге грешака у приступу online сервисима Централног регистра и Пореске управе путем "старих" сертификата на личним картама. Једина порука коју је сервис Пореске управе дао је да је "картица дисфункционална". Срећом, покушао сам (али после два дана експериментисања) да приступим и Централном регистру и захваљујући јаснијој поруци о грешци дошао до Вашег квалитетног чланка.
Све најлепше Вам желим!
Владимир Јанковић
3 maj 2017 Vladimir Janković
Evo odgovora od CA MUP da se za novi sertifikat mora izvaditi i nova lična karta sa novim čipom da postoji i ta informacija ovde da bi sve bilo kompletno.
CA MUP:
Obnavljanje sertifikata na ličnoj karti je moguće uraditi u bilo kom trenutku, nije neophodno da istekne važnost sertifikata, ali obnavljanjem sertifikata dobićete novi sertifikat, sa novim datumom važnosti i novim serijskim brojem, ali biće izdat iz istog Intermediate CA tela, odnosno potpisnik tog sertifikata će opet biti MUPCAGradjani.
Sertifikat potpisan od strane MUPCaGradjani3 možete dobiti samo na novoj ličnoj karti.