Promjene u certifikatima i uvođenje nove Fina Demo okoline

Sep 30, 2014 at 10:28 AM
Oct 1, 2014 at 2:33 PM
Na prvi pogled, čini mi se (tj. nadam se) da se u važećoj tehničkoj specifikaciji ne mijenja ništa. Mijenja se nešto vezano uz certifikate, u što se ja ionako kužim koliko i Mare u kriv k...., inače, kao i dosta nas na ovom forumu, ne bih ni bio ovdje. Elementi za kreiranje ZKI ostaju valjda isti, struktura .xml-a se ne spominje, a kreiranje zaštitnog koda i potpisivanje .xml-ova smo prepustili nekoj od verzija Raverusove 'crne kutije', i jedino što smo o certifikatima naučili je kako ga preuzeti sa FINA-inih stranica i poinstalirati kod klijenata.
I sada, i dalje u blaženom neznanju o certifikatima, nadam(o) se da Nino i dalje ima vremena i volje baviti se ovim projektom, pa da će opet to odraditi umjesto nas.
Ne znam hoće li projekt trebati dopunjavati postojeće rješenje (ja konkretno koristim EXE), ili će za te nove certifikate trebati odvojena komponenta, ali makar do toga ostaje prilično vremena (koliko sam skužio, produkcijski certifikati će se početi izdavati 2015.-te, ali će stari certifikati važiti do isteka, prema tome do otprilike 2018.-te, pa ćemo u međurazdoblju u nekoj formi morati u svojim programskim rješenjima osigurati istovremeno funkcioniranje oba sustava).
Po onome što je napisano, novo demo sučelje je valjda već aktivno, a objavljen je i obrazac zahtjeva za izdavanje Fina demo certifikata.
Pa, Nino, kako stojiš s voljom i vremenom?
Coordinator
Oct 1, 2014 at 3:09 PM
Pozdrav,

mi smo, naravno, aktivni na ovom projektu - projekt je ne samo ispuno, nego i premašio sva naša očekivanja :)
Ono što mi je, osobno, posebno drago, a oko čega sam u početku bio skeptičan, je činjenica da se oko svega uspio razviti zdrav "community" sa zaista mnogo prijedloga, ideja, informacija, pomaganja, ...

Iskreno, nismo se u ovom trenutku još previše zamarali s ovim novim najavama iz FINA-e, ne znam niti da li trebamo osim ako oni drastično nešto ne promijene što se tiče certifikata. Naime, certifikati koji se na ovom projektu u ovom obliku koriste nisu, srećom, izmišljotina niti FINA-e, niti APIS-a, niti Porezne - radi se o široko prihvaćenim standardima.

Vezano uz rok trajanja - certifikati imaju svoj rok trajanja i zna se za šta se certifikati koriste. U slučaju fiskalizacije, koriste se za potpisivanje XML poruka te za uspostavljanje SSL veze sa CIS-om. Ako certifikat ističe, na primjer, 01.11.2014. godine, tada nakon tog datuma više neće biti moguće raditi potpisivanje XML poruka. Znači - prije isteka tog roka treba izvaditi novi certifikat, koji će, barem je tako uobičajeno, vrijediti od dana izdavanja, pa će u praksi biti moguće koristiti i stari i novi certifikat paralelno u periodu od dana izdavanja novog certifikata do dana prestanka važenja starog, nakon čega, naravno, vrijedi samo novi certifikat. Osim toga, ništa se drugo ne mijenja. E, sad, da li FINA, APIS, Porezna ili netko sedmi ima namjetu mijenjati nešto po pitanju načina na koji se certifikati koriste - ne znam, no, mislim da za time nema potrebe niti da će se to realno i dogoditi.

Ukratko, jer vidim da ima dosta postova na tu temu ovih dana, ako vam certifikat uskoro ističe, izvadite novi i nastavite dalje po starom. Prema najavama iz FINA-e sa gore navedenog linka, moguće je da će jedino trebati dodati jedan ili više novih certifikata u certificate store ("trusted"), kako bi se osigurala njihova valjanost.

Sreća je da je sada "sezona" isticanja DEMO certifikata pa je sve puno manjeg opsega - predviđam OGROMNE probleme svima nama kada kroz 2-3 godine krenu isticati korisnički (produkcijski) certifikati; bit će veselo, FINA će prati ruke od svega, tako da će 99% tereta pasti na leđa IT firmi :)
Oct 1, 2014 at 3:20 PM
Nino, hvala na ekspresnom i konciznom odgovoru.
I molim te, javi seizmološkom zavodu tamo gore da ono u Zadru nije bio potres, samo je meni pao kamen sa srca. A vjerojatno je sličnih tektonskih poremećaja bilo diljem fiskalizirane Hrvatske ;-P
Oct 1, 2014 at 3:31 PM
nrasinec wrote:
predviđam OGROMNE probleme svima nama kada kroz 2-3 godine krenu isticati korisnički (produkcijski) certifikati; bit će veselo, FINA će prati ruke od svega, tako da će 99% tereta pasti na leđa IT firmi :)

Ne bi ja to gledao tako negativno nego bas suprotno kao priliku da nesto zaradim s obzirom da ne naplacujem redovno odrzavanje.
Svi obveznici ce morati kupiti novi certifikat pa im onda nece biti cudno da i meni nesto plate za download certifikata, prilagodbu programa itd...
Kad tu pribrojim sve korisnike Fiskal1 tableta koji ce biti prepusteni sami sebi, moci cemo i mi nesto zaraditi, a ne samo FINA.
Oct 1, 2014 at 4:28 PM
@Georgia47 - 8-D
@svi ostali - evo što mi zasad pada napamet što bi u svezi ovoga trebalo poduzeti:
  1. prije nego istekne stari, ishoditi novi FISKAL certifikat za FINA DEMO OKOLINU (za trenutno važeću strukturu certifikata) i instalirati ga da dalje možemo testirati svoja programska rješenja
  2. ishoditi FISKAL certifikat za FINA DEMO 2014 OKOLINU i instalirati ga tek kada u programskom rješenju jasno razgraničimo kad ćemo koristiti njega a kada (još) važeći certifikat za staru okolinu (pretpostavljam da će se nama periodi važenja obaju DEMO certifikata preklapati, ali za produkcijske certifikate kod korisnika to ne bi smio biti slučaj jer će svi vaditi 2014 certifikate pred istek ovih koje sada koriste, i nadam se da će novi certifikati njima važiti dan nakon isteka starih - da ne bude niti preklapanja niti 'rupe' u kojoj ne važi niti jedan certifikat).
  3. Ukoliko smo u programskom rješenju hardkodirali poziv certifikata (kao ja), omogućiti korištenje više certifikata prema periodu njihova važenja (posebno ako smo ugradili 'fičr' provjere ZKI na zahtjev inspektora PU za zadane parametre računa)
  4. Ukoliko smo u programskom rješenju hardkodirali URL do CIS-a (kao ja), a URL DEMO 2014 OKOLINE bude različit od dosadašnjeg (zaključujem da bi trebao biti), omogućiti slanje xml-ova na URL koji odgovara certifikatu koji je korišten za njegovo potpisivanje.
  5. Izmozgati ili tražiti kvalificirano mišljenje kakao rješavati granične situacije tipa da je račun izdan bez JIR-a dan prije isteka starog certifikata (ZKI kreiran starim certifikatom) i ide na naknadno slanje sutra, kada vrijedi samo novi, 2014 certifikat i slično...
    6... <molim ostale da dopune>
Oct 1, 2014 at 8:18 PM
PBDudek wrote:
  1. Izmozgati ili tražiti kvalificirano mišljenje kakao rješavati granične situacije tipa da je račun izdan bez JIR-a dan prije isteka starog certifikata (ZKI kreiran starim certifikatom) i ide na naknadno slanje sutra, kada vrijedi samo novi, 2014 certifikat i slično...
auuu ovo ce biti pitanje za jocker zovi publiku :D

@nino hvala na info !
nastavite sa odlicnim radom, svi smo vam zahvalni
Coordinator
Oct 2, 2014 at 7:01 AM
Prvo napomena - samo sam jednim okom pogledao ovu najnoviju FINA-inu obavijest, tako da ne kažem da je ovo što ću napisati 100% provjereno.

@PBDudek, komentari na tvoje točke:
  1. da
  2. mislim da neće biti nikakve potrebe za time, uvijek će biti samo jedan važeći certifikat, vidi moji raniji post gore iznad na temu stari/novi certifikat
  3. isto mislim da neće biti potrebe, vidi 2.
  4. ovo bi me zaista iznenadilo - naime - CIS održava APIS, na zahtjev Porezne (MFIN), FINA s time nema nikakve veze, zaista nema smisla da se mijenja CIS URL, bilo za test bilo za produkciju
  5. isto mislim da nema smisla razmišljati o tome
Ako netko zna više ili sam ja nešto krivo shvatio - javite :)
Oct 2, 2014 at 7:34 AM
@nino - iz tvojih usta u Lalovčeve uši!

Znači, sve promjene oko certifikata bi trebale biti 'pod haubom' (i tiče se samo puta certificiranja), a izvana se ne očekuju nikakve promjene?

Dva istovjetna xml zahtjeva potpisana novim i starim certifikatom bi trebala biti također identična?

Isti set ulaznih parametara će primjenom oba certifikata rezultirati istim ZKI, tj. privatni ključ će biti identičan za oba certifikata? (To napominjem zbog one moje 5. točke, jer će ponovljeni zahtjevi na prijelomu važenja certifikata nositi ZKI generiran starim, a bit će potpisani novim certifikatom...)

Samo nagađam gdje bi možda bila ipak nekakva kvaka, jer mi blagu paranoju izaziva sljedeći citat sa FINa-inih stranica:
_...
Sva korisnička informatička rješenja moraju do početka primjene navedenih promjena u produkciji biti prilagođena za rad s novim izmijenjenim profilima certifikata, ali istovremeno moraju i dalje podržavati rad s postojećim certifikatima do isteka perioda njihove valjanosti.
..._

Ovo jest zbilja totalno neodređeno sročeno, ali...
Oct 2, 2014 at 8:07 AM
Hm, meni se čini da će biti promjena jer se po FINA dokumentu mjenja algoritam enkripcije.

Laik sam na tom polju ali ako piše da će umjesto SHA1 enkripcije u novom koristiti SHA256 enkripciju onda bi se to moralo upisati u XML datoteci. Valjda.
Coordinator
Oct 2, 2014 at 8:10 AM
Dva istovjetna xml zahtjeva potpisana sa dva različita certifikata će biti različita, to i je poanta :) ZKI će isto biti različit, tako i treba biti. Bitno je jedino da potpisivanje/izračun ZKI-a bude prema algoritmima iz tehničke specifikacije.
Možda zabunu stvara "stari" i "novi" certifikat - bez obzira što se radi o "FISKAL 1" certifikatu, za isti OIB, radi se o dva različita certifikata, svaki sa svojim thumbprintom.

Uglavnom, meni se čini da ništa po tom pitanju za sada ne treba raditi. Mislim da će jedino trebati dodati još jedan certifikat u certificate chain i da bi time sve trebalo biti riješeno, barem što se tiče fiskalizacije.
Coordinator
Oct 2, 2014 at 8:14 AM
@andrejp Opet - brkaju se kruške u jabuke. Fiskalizacija je nešto što je poteklo od Porezne (MFIN-a) ("naručitelj"), APIS je "izvršitelj" (implementator"). FINA je tu samo da kreira certifikate, pored FINA-e to je mogao napraviti i netko treći. Za fiskalizaciju su bitni:
  1. Zakon o fiskalizaciji
  2. Pripadajući Pravilnici
  3. Tehnička specifikacija za fiskalizaciju.
Sa niti jednim od te 3 točke FINA nema ništa. Kada se promjeni Tehnička specifikacija, mijenjat ćemo i mi ovaj projekt :)
Oct 2, 2014 at 8:17 AM
Kamo sreće da tako bude, bio bi to jedan od rijetkih primejra da oni nešto mjenjaju a mi ne moramo :))
Oct 3, 2014 at 2:06 PM
PBDudek reče: Samo nagađam gdje bi možda bila ipak nekakva kvaka, jer mi blagu paranoju izaziva sljedeći citat sa FINa-inih stranica:
_...
Sva korisnička informatička rješenja moraju do početka primjene navedenih promjena u produkciji biti prilagođena za rad s novim izmijenjenim profilima certifikata, ali istovremeno moraju i dalje podržavati rad s postojećim certifikatima do isteka perioda njihove valjanosti.
..._


Neznam zasto ali i meni prolaze crnci ups trnci kroz kicmu. Koliko sam ja shvatio dosta posla glede certifikata ce se prevalit na nasa ledja. Kao prvo certifikati nece biti isti jer ce biti drugi ključ (2048 bita) i druga enkripcija. Druga razlika je u encription chain i koliko sam ja shvatio (kratko sam preletio text jer se ionako odnosi na 4 kvartal 2015 godina ) biti ce 3 certifikata u igri. Root kao i do sada (naravno samopotpisani) i pod certifikat s oznakom 2014 i na kraju korisnički koji će ciniti certificate chain. Ono što mene ježi jest cinjenica da ce postojat prijelazni period kada ce vaziti oba certifikata. To znaci da ce nasa aplikacija morati provjeravati da li je postojeci certifikat izasao (expiration date) i jos gore od toga da li je vazeći (jer postoji mogucnost da imam vazeći certifikat, ali je kod institucije npr. fine poništen pa se ne mogu spajati s njim jer je not expired ali je nevažeći. Ja sam za to da se svima izda novi certifikat i oni koji imaju vazeci dobiju ga besplatno (novi), ali sumnjam da ce fina to htjeti jer to stavlja vise posla pred njih. Oni ce samo nastaviti izdavati nove certifikate, a stari ce ostati vaziti do trenutka zastare(expire) ili dok ih se ne proglasi nevažećim. Dakle kako rekoh MI cemo biti ti koji cemo morati prilagoditi programe za oba režima. Dakle pod hitno rijesiti da ucitavate certifikate sa diska i izbjegavati formu "FISKAL 1" iz certificate storea da nebi bilo nestasluka. Ja u cert storeu drzim samo root certifikat a ove nove cu ucitavati sa diska kao i sada sto cinim.

Isto tako ocekujem i neke izmjene do konacnog rijesenja kako to uvijek i biva. Savjetujem svima da se sto prije ukljucimo u novu testnu okolinu i testiramo riješenja daleko prije, a ne kao zadnji puta 15 dana prije pustanja u produkciju. Jer kako PBDudek rece bit ce prelomnih situacija, koje cemo mi developeri najbolje uociti.
Oct 3, 2014 at 2:21 PM
Ma daj, Željko, taman me je Nino uglavnom smirio, a ti me opet ubijaš u pojam! ÷€

Za ozbiljno, mislim da smo dovoljno nagađali. Ja sam šefa poslao da pokrene ishođenje novog certa (stari mi je jučer istekao), pa ćemo konkretno vidjeti što će se događati.

Prvi od nas zainteresiranih tko ishodi novi certifikat, neka se javi jel radi, kako radi i ako ne radi što misli zašto.

Dotle, želim više vjerovati Ninu nego tebi. Tako mi je lakše...
Oct 3, 2014 at 2:29 PM
Mene zanima situacija kad dobivas novog klijenta sa novim certifikatom ili par starih kojima je istekao certifikat pa moraju na novi, a imas barem jednog sa vazecim starim certifikatom. To je situacija koja neminovno mora bit rijesena u programskoj logici i nacinu ucitavanja certifikata. Dakle bit ce izmjena samo je pitanje koliko. Najlakse bi developerima bilo neki datum pocetka i svi imaju isti novi certifikat i to je to. Samo to nema sanse. Uvijek jaci prebacuje posao slabijemu. Tak je bilo tak ce i biti .
Oct 3, 2014 at 2:31 PM
A nigdar ni bilo da nekak ni bilo, pa nigdar ni ne bu da nekak ne bu!!!
Oct 3, 2014 at 2:44 PM
I ako korisnicima prepustite rjesavanje certifikata bit ce svega. U storeu ce biti stari i novi certifikati i moze se desit da se pomijesaju tvrtke i svasta pa ce vas zvat potrebno i bespotrebno. Zato savjetujem certifikat u poddirektorij programa i programski sam odradjivati registraciju u cert store i ucitavat certifikate sa diska. Ja cu ubaciti opciju da korisniku pokaze poruku upozorenja 15 dana prije isteka certifikata tako da kad bude zvao nakon sto mu certifikat istekne ili zadnji sat samo pritisnem veliki taster IGNORE ili do it slowly no sikiriki pa dok ne izvadi cert nema izdavanja računa. Sad mi je palo na pamet : Nakon provjere da je certifikat izasao zabranicu rad sa programom jer ce ispast banana. Klijent ce izdat racun bez jira (nece se naravno spojiti na PU) a nece se moci svi naknadno spojiti unutar 48 sati sa novim certifikatom jer ce morat proci proceduru izdavanja i past ce pod kaznu koja ce se prebacivati na programerska ledja po sistemu sto si mi dozvolio da radim tvoj je program. Dakle razmislite o tome sto sam rekao. Nije plasenje samo jedan od mogucih scenarija koji mi je pao napamet ad hoc. Zato smo tu vise glava pametnije misli ! Ljep pozdrav svima!
Oct 3, 2014 at 3:48 PM
Edited Oct 3, 2014 at 4:01 PM
Kako sam već napomenuo, u certifikate se ne razumijem.

Nastavno na Željkove postove, upozoravam sve koji su otprilike mog ranga znanja na sljedeće:

Demo certifikat mi je istekao danas, i nekako sam računao da će istek važenja certifikata spriječiti njegovo korištenje, ali - i danas mi se računima koje izdajem uredno formira ZKI i uredno se potpisuje .xml zahtjeva za fiskalizaciju (dakle s certifikatom kome je istekao rok važenja). Da nešto nije u redu, doznajem tek tako da od CIS-a ne dobivam jir već poruku o greški:
Status greške: ProtocolError
Greška: Nepoznata greška

U FiskalizacijaDEV.log stoji na kraju:
Greška kod obrade i slanja dokumenta: The remote server returned an error: (500) Internal Server Error.

Prema tome, sam istek valjanosti certifikata me neće spriječiti u izdavanju računa ukoliko nisam (a nisam) ugradio provjeru je li certifikat u trenutku izdavanja važeći ili nije.

Uz ono što reče Željko, tu dolazimo do situacije da je moguće uvaliti klijenta u situaciju da nevažećim certifikatom izda gomilu računa prije negoli se sam sjeti ili mu mi kažemo da mora zatražiti novi, pa još dok mu novi stigne, dok mu ga netko preuzme i instalira... a ne znam kako će se CIS postaviti na zahtjeve potpisane važećim (novim) certifikatom koji sadrže ZKI kreiran privatnim ključem nevažećeg (ili čak i važećeg u trenutnku izdavanja, nije bitno) (starim) certifikatom.

Možda sam ja previdio, ali u ovom trenutku nisam siguran da Raverus ima ugrađenu i funkciju provjere valjanosti certifikata (idem sad gledati Ninove upute), ali ako nema - bilo bi zgodno da ima, pa bi to bio pozdan ključ za sprečavanje izdavanja računa bez posjedovanja valjanog certifikata.

I još samo nešto @zeljkoNG - ja nemam niti jednog korisnika koji je u stanju sam se brinuti o certifikatima, a ne vjerujem ni da ima itko tko se bavi ovim poslom. Otkad su nam uvalili ovu fiskalizaciju, taj smo posao svi mehanički preuzeli na sebe kao da je to elementarna nepogoda, a ne prisilno nabačen teret na naša pleća koji nam nikad nitko nije niti će platiti ukoliko ne zauzmemo stav kao Georgia47 (vidi njegov post gore u diskusiji).

Edit: evo ja provjerio - Raverus EXE nema način za provjeru trenutne valjanosti certifikata. Nino, jel bi to moglo ući u razmatranje?
Oct 6, 2014 at 10:17 AM
Kad smo vec kod promjene certifikata, sto ce se dogoditi s koristenjem "obavezno" ugradjene funkcije za testiranje ZKI-a nakon promjene certifikata?

Npr, jucer ste izdali racun sa starim certifikatom, danas ste upravo instalirali novi (ne mora biti ovaj najnoviji, nego stari ali sa novim vazenjem) i dodje vam inspekcija sa jucerasnjim racunom da provjere kako vam radi TEST ZKI funkcija u programu (niti kod jednog mog nisu to jos trazili, ali evoluirat ce mozda i inspekcija).

Nema sanse da dobijete isti ZKI, sto onda ukazuje na besmislenost "obaveznog" ugradjivanja navedene funkcije, a da ne spominjem to da certifikat vrijedi 5 godina, tako da vam 5 godina racuna unatrag, nakon instalacije novog certifikata, vise nece davati isti ZKI kao sto su bili zapisani na racunima.
Oct 6, 2014 at 10:26 AM
Prethodno sam napisao da moj demo certifikat koji je istekao još uvijek radi (kreiranje ZKI i potpisivanje zahtjeva), samo mi CIS odbija poslati JIR. Pretpostavljam da će biti isto sa produkcijskim certifikatima. Prema tome, za provjeru ZKI za stare račune samo treba natjerati program da koristi odgovarajući (makar i nevažeći certifikat) i u tu svrhu ne bi trebalo stare certifikate uklanjati sa računala.
Pravi problem je, po meni, kako opomenuti (ili još bolje spriječiti) korisnika da ne nastavi izdavati račune (sa ZKI, bez JIR jer im ga CIS neće poslati) od dana isteka certifikata.
Oct 6, 2014 at 11:50 AM
Edited Oct 6, 2014 at 11:51 AM
viggor po meni je to sa provjerom zki ionako bez veze jer ako vam aplikacija ne izdaje pravilno zki onda necete sa sigurnoscu dobiti JIR jer budite bez brige da se vas ZKI uz zadane parametre provjerava prilikom izdavanja JIR. Uvodjenjem novog certifikata i kada budete radili sa novima a npr provjera vas trazi da npr. provjerite ZKI sa racuna iz godine kada ste radili sa oba certifikata morat ce vam dati podatak ili parametar sa kojim certifikatom ste izdali pa ga ucitati s diska. (Zato sam vam spomenuo da si prepravite programe da ucitavaju cert sa diska umjesto cert storea). Bilo bi jako zgodno da onaj tko kaze da se nesto mora imati i da kaze koliko to kosta pa da oni koji osiguravaju to sto je potrebno ne razbijaju glavu jer to je dodatna opcija koja nije potrebna nama ni korisnicima (koji placaju) nego nesto extra.

Dakle moje pitanje je: čemu provjeravati nešto što je već provjereno. Samo se odstampa kopija racuna iz arhive i to je to !
Oct 6, 2014 at 11:55 AM
Edited Oct 6, 2014 at 12:10 PM
zeljkoNG wrote:
Dakle moje pitanje je: čemu provjeravati nešto što je već provjereno. Samo se odstampa kopija racuna iz arhive i to je to !
Možda zato što tako izričito piše u Zakonu o fiskalizaciji?

Edit: Pardon, ne u Zakonu već u pravilniku:

Članak 16.
Zaštitni kod obveznika fiskalizacije koristi se kao obvezni element računa:
  1. kojim obveznik fiskalizacije po potrebi, u postupku provjere računa u tijeku poreznog nadzora na temelju ostalih elemenata računa dokazuje da je on izdavatelj računa te
  2. u postupcima provjere računa od strane građana na temelju članka 27. Zakona i u svim slučajevima kada je račun izdan bez JIR-a.
Oct 6, 2014 at 12:18 PM
zeljkoNG wrote:
...jer budite bez brige da se vas ZKI uz zadane parametre provjerava prilikom izdavanja JIR...
A ni to ti ne stoji:
Tehnička specifikacija, poglavlje 12, citat:
Porezna uprava ne provjerava zaštitni kod ali na njezin zahtjev obveznik fiskalizacije, temeljem istih ulaznih parametara, mora kreirati zaštitni kod jednak onome s računa.
Oct 6, 2014 at 6:03 PM
zeljkoNG wrote:
...budite bez brige da se vas ZKI uz zadane parametre provjerava prilikom izdavanja JIR...
Sorry, ali ovo je 100% netocno - ZKI se kreira pomocu privatnog kljuca kojeg NE ZNA NITKO U SVEMIRU (barem ne bi trebao), osim onoga tko ima certifikat! Niti FINA, koja izdaje certifikate ne zna taj privatni kljuc. Zato i ne moze ponovo izdati isti certifikat, ako ga nekom greskom izgubite, nego vam generira potpuno novi - koji nema veze sa starim. I kako onda generirati ZKI-eve od racuna sa izgubljenim/zapaljenim/pojedenim/ugradenim certifikatom??? Jednostavno, NIKAKO.

Pitam se samo, da li su toga svjesni kreatori sustava i da li su o tome izvijestili nadobudne kontrolore?
Oct 7, 2014 at 2:43 AM
Edited Oct 7, 2014 at 2:45 AM
Decki hvala za info. Neznam kako mi je to promaklo. Vjerojatno zato sto se nisam dosad baktao sa certifikatima i xml pa nemam iskustva s time.

Viggor hvala tebi posebno jer ne vidim balvan u vlastitom oku. Salje se potpisani xml u PU (a ne certifikat) tako da ZKI jednoznacno odredjuje izdavatelja.
Viggore ovaj ti zadnji post zlata vrijedi. Dakle certifikat se nikada ne smije izgubiti niti uništiti jer se ne moze IZVADITI / REIZDATI duplikat i ne moze se generirati
istovjetan zki sa izdanih racuna. Mislim da nije dovoljno naglasena vaznost cuvanja i arhiviranja certifikata jer ako se ostane bez certifikata steta ce biti nepopravljiva.
Dakle obavezno arhivirati certifikate na externe medije i to vise njih zlu ne trebalo.
Jos jednom hvala svima!
Oct 8, 2014 at 11:54 AM
Može se reizdati isti certifikat, logiraš ne tamo gdje si ga prvi puta skinuo i možeš ga opet skinuti.
Oct 9, 2014 at 11:57 AM
Edited Oct 9, 2014 at 12:03 PM
moremore wrote:
Može se reizdati isti certifikat, logiraš ne tamo gdje si ga prvi puta skinuo i možeš ga opet skinuti.
Ovo je tocno! Naravno moras znati lozinku koju si koristio prilikom prvog skidanja certifikata. Ja sam se referirao na slucaj kad to ne znas - onda nema reizdavanja, nego se mora napraviti novi certifikat iako je subjekt (OIB) ostao isti.

@zeljkoNG, mislim da to cuvanje certifikata, iako je pametno cuvati ih najvise zbog zlouporabe, ne vidim da je toliko kriticno. Ako se izgubi, napravi se novi - sama funkcija testiranja ZKI-a je jednako besmislena u slucaju gubitka certifikata ili njegove promjene zbog isteklog roka ili neke promjene u sustavu (kao sto je ova koja slijedi krajem 2015-te).

BTW, glede ovoga sto sam spomenuo, zlouporabu certifikata, jedan moj klijent me pitao sto mislim o sljedecem: njegovog poznanika, ugostitelja, zvala PU da im objasni otkud preko 2.000.000 (2 miliona) nakucanih racuna od pocetka godine na njegov OIB!!! Ovaj navodno ne pravi godisnje 100-200 tisuca prometa. Meni jedino sto pada na pamet (osim da se "nisu igrala deca", a navodno nisu), je da mu je neko klepio certifikat i izdavao racune pod njegovim OIB-om.

EDIT: mislim ne na 2 miliona racuna, nego na 2 miliona kuna.
Oct 9, 2014 at 12:59 PM
viggor wrote:
sama funkcija testiranja ZKI-a je jednako besmislena u slucaju gubitka certifikata ili njegove promjene zbog isteklog roka ili neke promjene u sustavu (kao sto je ova koja slijedi krajem 2015-te).
Nije. Meni je (demo) certifikat istekao 3. 10. i još uvijek radi (kreira ZKI i potpisuje zahtjev, samo mi CIS odbija poslati JIR). Pretpostavljam da će tako biti i sa isteklim produkcijskim certifikatima, prema tome, ukoliko se čuvaju stari certifikati, samo je potrebno uz parametre računa kojem se provjerava ZKI odabrati i certifikat kojim mu je ZKI izvorno kreiran.
Oct 9, 2014 at 3:23 PM
Odlicno! Onda cuvajmo certifikate radi "test ZKI" funkcije - koja je opet, besmislena, ali o tome smo davno vodili diskusiju, jos dok smo sve pripremali za rad, tako da necu vise o tome, jer tema posta je nesto sasvim drugo - vaznije. Ja sam malo zamutio stvari dodatnim podpitanjima pa se ispricavam svima koje zivciram.
Oct 26, 2014 at 12:06 AM
Edited Oct 26, 2014 at 12:08 AM
Ne vidjeh upita li se itko da li ce(mo) obveznici fiskalizacije ponovo morati placati nove certifikate, obzirom na novonastale promjene, iako stari certifikati vrijede barem do kraja 2017. Siguran sam da u ovoj Lopovskoj Nasoj, hoce. Bas me zanimalo koliko bi to moglo biti para. Evo sta kaze Lider: do kraja 2013. je bilo 70.000 obveznika.

Dakle, 70.000 x 300 = 21.000.000 kn !!! Ej, 21 MILION KUNA je Fina drpila samo za kreiranje visecifrenih (100-200 cifara, ne znam tocno) prostih brojeva, koji sluze za kreiranje privatnih i javnih kljuceva (uprosten opis RSA algoritma). Plus 5.250.000 drzavi, tj. svega 5 MILIONA KUNA za PDV!

I to sad, gotovo sam siguran, misle ponovit, bez pardona. Slicno kao sto je od juce poskupio tehnicki pregled vozila za 10% - bez ikakvog objasnjenja, jednostavno, sad je tako i gotovo - ko vas jebe, dragi nasi gradjani, treba nam para, ajmo, daj 'vamo, nemoj da vam prevcemo dzepove.
Oct 27, 2014 at 6:39 AM
viggor wrote:
Ne vidjeh upita li se itko da li ce(mo) obveznici fiskalizacije ponovo morati placati nove certifikate, obzirom na novonastale promjene, iako stari certifikati vrijede barem do kraja 2017.
Po onome što je objavljeno, stari certifikati vrijede do isteka, zato su i napisali da moramo osigurati u programima mogućnost rada sa oba tipa u prijelaznom razdoblju (svi koji podnesu zahtjev za certifikatom od kraja 2015. izdat će im se 'novi' i naplatiti, a stari će vrijediti, nadam se bez ikakve promjene i nadoplate, kako si napisao, do kraja 2017.).
Oct 27, 2014 at 12:48 PM
Nadobudno sam dao zahtjev za novi demo certifikat (postoji obrazac) no rečeno mi je da njihova demo okolina za novi certifikat još ne radi. :)