Loš potpis Potpis nije uspio provjera valjanosti Nedostaje identifikator objekta OID. Elektronski potpis (ES) Nepoznata upotreba ključa 1,2 643,3 7,8 1

Hvala puno, Mihaile, sve je urađeno brzo i, što je najvažnije, bilo mi je jasno... Pošto smo našli zajednički jezik. Želio bih da ostanem u kontaktu s vama u budućnosti. Nadam se plodonosnoj saradnji.

Olesya Mikhailovna - CEO DOO "VKS"

U ime Državnog jedinstvenog preduzeća „Sevastopoljsko avijaciono preduzeće“ izražavamo zahvalnost na profesionalizmu i efikasnosti Vaše kompanije! Vašoj kompaniji želimo dalji prosperitet!

Guskova Lilija Ivanovna - menadžer. TUŽBA "SAP"

Hvala Michael na pomoći oko dizajna. Veoma kvalifikovani radnik +5!

Nadiya Shamilyevna - Poduzetnica IP Anoshkina

U ime kompanije "AKB-Avto" iu svoje lično ime, izražavam zahvalnost Vama i svim zaposlenima Vaše kompanije na produktivnom i kvalitetnom radu, senzibilnom odnosu prema zahtevima kupaca i efikasnosti u izvršenju naručenih poslova. .

Nasibullina Alfira - viši menadžer"AKB-Auto"

Želim da se zahvalim konsultantu Mihailu na odličnom radu, pravovremenim i kompletnim konsultacijama. Veoma je pažljiv prema problemima i pitanjima klijenta, ažurno rješava najteže situacije koje mi se čine. Zadovoljstvo je raditi sa Michaelom!!! Sada ću preporučiti Vašu kompaniju svojim klijentima i prijateljima. Da, i konsultanti za tehničku podršku su također vrlo ljubazni, pažljivi, pomogli su da se nose s teškom instalacijom ključa. Hvala ti!!!

Olga Sevostyanova.

Ispostavilo se da je nabavka ključa vrlo laka, pa čak i prijatna. Veliko hvala na pomoći menadžeru Michaelu. Objašnjava stvari koje su složene i masivne za razumijevanje, sažeto, ali vrlo jasno. Pored toga, pozvao sam besplatnu telefonsku liniju i ostavio zahtev na mreži, zajedno sa Mihailom. Dobio sam ključ za 2 radna dana. Općenito, preporučujem ako štedite vrijeme, ali u isto vrijeme želite imati razumijevanje o tome šta kupujete i za šta plaćate. Hvala ti.

Levitski Aleksandar Konstantinovič Samara

Lična zahvalnost konsultantu Mihailu Vladimiroviču za brze konsultacije i rad na ubrzanom prijemu ES sertifikata. Tokom preliminarnih konsultacija bira se optimalan skup pojedinačnih usluga. Krajnji rezultat je trenutan.

Stoyanova N.L. - Glavni računovođa DOO "SITECRIME"

Hvala na brzom radu i stručnoj pomoći! Bio sam veoma zadovoljan savjetom!

Dmitry Fomin

DOO "Expert System" zahvaljuje konsultantu Mihailu na brzom radu! Želimo Vašoj kompaniji rast i prosperitet!

Sukhanova M.S. - ProcjeniteljDOO "Expert System", Volgograd

Hvala konsultantu, koji se predstavio kao Mikhail, na efikasnosti u radu sa klijentima.

Ponomarev Stepan Gennadievich

Veliko hvala konsultantu Mihailu na pomoći u dobijanju EDS-a. Za brz rad i savjete o pitanjima koja se javljaju u procesu registracije.

Leonid Nekrasov

Kompanija, koju zastupa konsultant Mikhail, čini nemoguće! Ubrzajte akreditaciju za manje od 1 sata! Plaćanje po pružanju usluge. Mislio sam da se to nije dogodilo. Sa punom odgovornošću mogu Vam savjetovati da se obratite Centru za izdavanje elektronskih potpisa.

Kada unesete svoj lični nalog da zatražite QEP, prikazuje se poruka « Računar nije konfigurisan . Da nastavite, idite na stranicu postavki računara i slijedite predložene korake » . Nakon što odete na stranicu postavki i instalirate sve potrebne komponente lični račun pojavljuje se poruka da računar nije ponovo konfigurisan.

Da biste ispravili grešku, morate:

1. Dodajte adresu svog ličnog naloga https://i.kontur-ca.ru u pouzdane čvorove. Za ovo:

• Odaberite meni "Start" > "Kontrolna tabla" > "Internet opcije";
• Idite na karticu "Sigurnost", odaberite element "Pouzdane lokacije" (ili "Pouzdane lokacije") i kliknite na dugme "Čvorovi";
• Navedite sljedeću adresu čvora https://i.kontur-ca.ru u polju Dodaj u zonu i kliknite na dugme Dodaj.

Ako se ova adresa već nalazi na listi pouzdanih lokacija, idite na sljedeći korak.

2. Provjerite da li je adresa ličnog računa https://i.kontur-ca.ru definirana kao pouzdana:

• Ako se koristi Internet Explorer verzija 8, onda, kada ste na stranici za autorizaciju, trebate provjeriti da li je potvrdni okvir Pouzdane lokacije na dnu stranice. Ako nema okvira za potvrdu, ali postoji natpis « Internet”, tada adresa https://i.kontur-ca.ru nije dodana na pouzdane stranice.

• Ako se koristi Internet Explorer verzija 9 i novija, tada, kada ste na stranici za autorizaciju, trebate kliknuti desnim gumbom bilo gdje na stranici, odabrati "Svojstva". U prozoru koji se otvori, linija "Zona" treba da sadrži natpis "Pouzdane lokacije". Inače, adresa https://i.kontur-ca.ru nije dodana na pouzdane stranice.

Ako adresa vašeg ličnog računa nije utvrđena kao pouzdana, trebate kontaktirati sistem administrator sa zahtjevom za dodavanje adrese https://i.kontur-ca.ru u pouzdane čvorove.

3. Provjerite možete li se prijaviti na svoj lični račun. Ako se greška ponovi, trebali biste pokrenuti uslužni program RegOids sa veze. Ovaj uslužni program će automatski konfigurisati OID postavke u registru računara. Također možete ručno uvesti jednu od grana registra, ovisno o bitnosti instaliranog operativnog sistema:

4. Provjerite da li računar koristi administratorska prava (da biste provjerili, idite na Start - Kontrolna tabla - Korisnički nalozi i porodična bezbednost - Korisnički nalozi). Ako prava nisu dovoljna, morate korisniku dati puna prava, za to se obratite svom administratoru.

5. Nakon završetka koraka 3, potrebno je ponovo pokrenuti računar i provjeriti ulaz u Lični račun.

Ako nijedna od uputa nije pomogla, obratite se tehnička podrška po adresi [email protected]. U pismu mora biti navedeno:

1. Broj dijagnoze.

Da biste to učinili, morate otići na dijagnostički portal nahttps://help.kontur.ru , pritisnite dugme " Pokreni dijagnostiku » . Kada se proces verifikacije završi, dijagnostički broj će biti prikazan na ekranu. Navedite dodijeljeni referentni broj u pismu.

2. Snimak ekrana prozora sa greškom (kada koristite Internet Explorer verzije 9 i novije, morate priložiti i snimak ekrana prozora "Svojstva" - pogledajte tačku 2).

3. Izvezite i priložite sljedeće grane registra:

32-bit: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo
64-bit: HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo

Vadim Malykh
02.10.2013

Prije nekog vremena u grupi Forum Rus na Facebooku bila je rasprava o korištenju autoriteta u informacionim sistemima (diskusija je bila van teme, možete vidjeti u komentarima ispod). Suština spora je zbog OID-a (object identifier - object identifier) ​​informacionih sistema koji moraju biti registrovani u sertifikatima kvalifikovanog elektronskog potpisa (ES) zvaničnici, ovi isti ES moraju se mijenjati čak i češće od jednom godišnje (što je diktirano sigurnosnim zahtjevima), a to, pak, dovodi do dodatnih poteškoća i troškova, jer većina nadležnih radi sa komercijalnim CA-ima bez vlastitih. Problem se pogoršava nedostatkom zajedničkog razumijevanja šta tačno ovi OID-i pružaju i koliko su neophodni i/ili obavezni.

U toku rasprave moj protivnik me je upozorio da bih zbog nepoznavanja nekih osnova predmetne oblasti u budućnosti mogao doći u određene pravne probleme. Nisam mogao zanemariti takvo upozorenje kolege, pa sam odlučio da ponovo pažljivo proučim ovu temu i uvjerim se da sve razumijem i uradim kako treba. Ispod su neki od rezultata ovog izleta u predmetno područje. Možda će neko biti zainteresovan.

Počevši od osnovnih pojmova, elektronski potpis baziran na asimetričnim algoritmima enkripcije. Glavna karakteristika ovih algoritama je da se dva različita ključa koriste za šifriranje i dešifriranje poruke. Simetrični algoritmi su poznatiji široj javnosti, kada šifriramo i dešifrujemo poruku istim ključem (ili lozinkom), na primjer, arhiviramo datoteku lozinkom ili štitimo MS Word dokument.

Mnoge stvari su bazirane na asimetričnim algoritmima šifriranja, iako sama činjenica da se različiti ključevi koriste za enkripciju i dešifriranje ne bi nam omogućila da pronađemo bilo kakvu korisnu primjenu za ove algoritme. Da bi to učinili, moraju imati neka dodatna svojstva. Prvo, ključevi ne smiju biti izračunljivi, odnosno, ako znate jedan ključ, ne možete izračunati drugi. Također je vrlo važno da različiti ključevi za šifriranje odgovaraju različitim ključevima za dešifriranje i obrnuto - samo jedan ključ za šifriranje odgovara jednom ključu za dešifriranje.

Šta je stvarni potpis? Na kraju krajeva, moramo potpisati dokument, a ne šifrirati ga. Prvo morate razumjeti šta je potpis i zašto je potreban. Kada stavite svoj svojeručni potpis papirni dokument, time uvjeravate da ste vi (a ne neko drugi) vidjeli (i pristali na) ovaj dokument (a ne neki drugi). Najvažnija imovina potpisi - neporicanje. To znači da kada jednom potpišete dokument, ne možete se kasnije odreći te činjenice. U slučaju papirnog potpisa, veštačenje rukopisa će vas osuditi, u slučaju elektronskog, matematičkim metodama zasnovanim na asimetričnim algoritmima šifrovanja.

Kako to sve funkcionira, ukratko. Uzimamo asimetrični algoritam šifriranja, generiramo par ključeva (za šifriranje i dešifriranje). Dajemo ključ za šifriranje osobi koja će potpisati dokumente. Mora ga uvijek držati kod sebe i nikome ga ne dati. Stoga se naziva "privatni" ključ. Svima dajemo još jedan ključ (dešifriranje), tako da je „otvoreno“. Prilikom potpisivanja dokumenta, osoba ga mora šifrirati svojim vlastitim privatni ključ. Nije sam dokument taj koji je zapravo šifriran, jer može biti prilično velik, a mi zapravo ne moramo da ga šifriramo. Stoga se, prema dokumentu, dobiva hash - ovo je određeni numerički niz sa veliki udio vjerovatnoće su različite za različite dokumente, kao da je "otisak" dokumenta. Šifriran je privatnim ključem potpisnika. Ovaj šifrirani hash je elektronski potpis dokument. Sada, posjedujući dokument, potpis i javni ključ, svako može lako provjeriti da li je ovaj dokument potpisan ovim posebnim privatnim ključem. Da bismo to učinili, ponovo dobivamo hash dokumenta, dešifrujemo potpis javnim ključem i upoređujemo. Trebalo bi dobiti dvije identične numeričke sekvence.

Sve je to odlično, ali do sada smo dobili nepobitnost potpisa za privatni ključ, odnosno dokazali da je dokument potpisan određenim ključem. Moramo dokazati da ga je potpisala određena osoba. Da biste to učinili, postoje certifikacijski centri i digitalni certifikati. Najvažnija stvar koju certifikacijsko tijelo radi je da potvrđuje da privatni ključ pripada određenoj osobi. Da bi se to garantovalo, certifikacijski centar je taj koji generiše parove ključeva i lično ih izdaje vlasnicima (postoje opcije putem proxyja, daljinski, ali ovo su detalji). Zajedno s ključevima generira se digitalni certifikat - to je elektronički dokument (ponekad njegov papirni prikaz), koji sadrži podatke o vlasniku ključa, samom ključu, certifikacijskom tijelu i neke druge informacije. Vlasnik, po pravilu, sve te dobrote prima na sigurnom mediju (smart card, ru-token i tako dalje), koji sadrži privatni ključ i certifikat sa ugrađenim javnim ključem. Sam nosač uvijek morate imati kod sebe, a certifikat javnog ključa koji je kopiran sa njega može se dati svima kako bi mogli provjeriti vaš elektronski potpis.

Dakle, potpisivanje se vrši privatnim ključem, a provjera potpisa javnim ključem. Stoga je izraz "dokument potpisan skupom OID-ova" (zvučan u gornjem sporu) besmislen. Samo dva ključa su uključena u proceduru potpisivanja i verifikacije, u 63-FZ su imenovani u skladu s tim - ključ potpisa i ključ za provjeru potpisa.

A šta su ovi ozloglašeni OID-i? Format digitalni sertifikat X.509 vam omogućava pohranjivanje ekstenzija u njega. Ovo su neki neobavezni atributi koji se mogu koristiti za pohranjivanje dodatnih informacija. Svaki takav atribut je objekt koji je specificiran identifikatorom iz hijerarhijskog direktorija. Stoga OID - identifikator objekta. Nema smisla ulaziti u prirodu samih OID-ova. Zapravo, ovo su neke dodatne informacije koje mogu biti prisutne u certifikatu.

Ovi dodatni atributi se mogu koristiti u različite svrhe. Oni mogu ili pružiti dodatne informacije o vlasniku, ključevima, CA ili nositi neke dodatne informacije za aplikacije i usluge koje koriste ovaj certifikat. Najčešća upotreba je kontrola pristupa zasnovana na ulogama. Na primjer, u certifikatu se može navesti da je vlasnik ključa šef organizacije, a to će mu dati mogućnost da odmah pristupi potrebnim funkcijama i informacijama u svim IS-ovima, bez potrebe da kontaktira administratore svakog od njih. IS i promijenite postavke pristupa. Sve to, naravno, pod uvjetom da svi ovi IS-i koriste certifikat korisnika za autorizaciju i na isti način analiziraju isti atribut (zbog toga se atributi biraju iz direktorija, a ne postavljaju proizvoljno).

Zbog različitih aplikacija dobijamo dva sertifikata koji su potpuno različite prirode. Jedan - potvrđuje da sam ja, i to je uvijek tako. Zauvek, može se izdati jednom ili više puta u životu, kao pasoš. Međutim, zbog nesavršenosti postojećih kriptografskih algoritama, iz sigurnosnih razloga, ovi certifikati sada moraju biti reizdati svake godine. Drugi tip sertifikata se odnosi Dodatne informacije i može se mijenjati mnogo češće nego jednom godišnje. Može se porediti sa posjetnica. Promijenjena je pozicija, e-mail, telefon - potrebno je napraviti nove vizit karte.

U svijetu se ove dvije vrste certifikata nazivaju, odnosno Certifikat javnog ključa (PKC) i Certifikat atributa (ili Autorizacijski certifikat - AC). Sertifikat druge vrste može se izdavati mnogo češće nego prvi, od strane druge organizacije, i trebao bi biti pristupačniji i lakši za nabavku od ličnog certifikata "javnog ključa". U svakom slučaju, ovo je ono što preporučuje RFC 3281, posvećen ovoj vrsti certifikata. Sertifikat druge vrste treba da sadrži samo vezu do certifikata javnog ključa kako bi sistem koji ga koristi za autorizaciju korisnika mogao prvo identificirati osobu koja koristi PKC.

Hajdemo sada da se približimo našoj stvarnosti. Na zakonodavnom nivou, pitanja vezana za upotrebu elektronskog potpisa u Ruska Federacija, regulisani su dva glavna dokumenta - zakonom Ruske Federacije od 06.04.2011. br. 63-FZ „O elektronskom potpisu“ i naredbom Federalne službe bezbednosti Ruske Federacije od 27.12.2011. 795 „O odobravanju zahtjeva za obrazac kvalifikovani sertifikat ključ za provjeru elektronskog potpisa. Sastav kvalifikovanog sertifikata opisan je u 795. redosledu (II deo "Zahtevi za skup polja kvalifikovanog sertifikata") i ne sadrži zahteve za atribute koji kontrolišu autorizaciju u bilo kom informacionom sistemu. Kao dodatni obavezni atributi navode se samo informacije koje vam omogućavaju da identifikujete fizički ili entiteta u Ruskoj Federaciji (TIN, SNILS, itd.). Iako ni zakon ni naredba FSB-a ne zabranjuju uključivanje drugih informacija u kvalificirani certifikat.

Kao što vidimo, nijedan zakonodavne norme ne diktiraju obavezno prisustvo u kvalifikovanom sertifikatu atributa povezanih sa autorizacijom u bilo kom informacionom sistemu. Odakle dolaze ovi zahtjevi? I dolaze od programera (ili "vlasnika") određenih sistema. Uzmi za primjer" Smjernice o upotrebi elektronskog potpisa u međuresornoj elektronskoj interakciji (verzija 4.3)”, objavljeno na tehnološkom portalu SMEV. Zaista, u stavu 6 ovaj dokumentčitamo: „Prilikom pripreme informacija za formiranje EP-SP sertifikata, potrebno je utvrditi da li je potrebno tražiti informacije od Rosreestra (izvod iz USRR). Ako je takav zahtjev neophodan, OID mora biti naveden u polju „Poboljšani ključ“ (OID=2.5.29.37) u ES-SP certifikatu u skladu sa zahtjevima Rosreestra.“. To jest, informacioni sistem Rosreestr koristi ovaj atribut da odredi informacije koje se mogu izdati vlasniku sertifikata. Međutim, isti dokument sadrži važnu napomenu, naime, ovaj zahtjev važi sve dok se ESIA (jedinstveni servis za autorizaciju u državnim sistemima) u potpunosti ne pokrene i na njega poveže sistem Rosreestr. Ovo je važna napomena, imajte je na umu.

Neću se baviti drugim IP-ovima koji se koriste u državi. organi. Pretpostavljam da je situacija slična. Portal javnih nabavki, elektronski trgovačke platforme, razne računovodstvene i finansijske aplikacije takođe mogu zahtevati prisustvo određenih dodatnih OID-ova u korisničkom sertifikatu. Istovremeno, netačna je tvrdnja da upisivanjem OID-a informacionog sistema u sertifikat na neki način delegiram odgovornost na sertifikacioni centar, blago rečeno. CA unosi ove podatke u certifikat prema mojoj prijavi. Ako se moja pozicija promijenila, a zaboravio sam podnijeti zahtjev za opoziv starog i izdavanje novog certifikata, CA ne može biti odgovoran za moj zaborav. Osim toga, zakon 63-FZ direktno dodjeljuje odgovornost za pogrešnu upotrebu certifikata njegovom vlasniku. U stavu 6 člana 17 čitamo:
Nosilac kvalifikovanog sertifikata mora:
1) ne koristi ključ za elektronski potpis i odmah se obrati akreditovanom sertifikacionom centru koji je izdao kvalifikovani sertifikat radi ukidanja ovog sertifikata ako postoji razlog da se veruje da je povređena poverljivost ključa za elektronski potpis;
2) koristi kvalifikovani elektronski potpis u skladu sa ograničenjima sadržanim u kvalifikovanom sertifikatu (ako su takva ograničenja utvrđena).

Potreba za pohranjivanjem informacija o ulogama i pristupima korisnika u određenim informacionim sistemima u certifikatu dovodi do problema koji je izazvao spor na Facebooku, naime, certifikat se mora reizdati mnogo češće od sigurnosnih zahtjeva za lični elektronski potpis diktira. Pozicija je promijenjena - ponovo izdajemo certifikat. Pojavio se novi IS - ponovo izdajemo certifikat. Postojala je potreba da se traže informacije od IS-a nova organizacija(Rosreestr) - ponovo izdajemo sertifikat.

Postoji 100% pogodak u konceptu koji se zove svjetski Attribute Certificate (ili Authorization Certificate), koji je gore spomenut i u kojem se preporučuje izdavanje ovih certifikata od strane drugog sertifikacionog tijela (Attribute Autority, za razliku od Certificate Authority - redovni CA koji izdaje kvalifikovane ES sertifikate) i to na pojednostavljen način. Ovaj certifikat sam po sebi ne bi trebao sadržavati ključ elektronskog potpisa i podatke o vlasniku. Umjesto toga, sadrži vezu do certifikata javnog ključa vlasnika, iz koje možete dobiti ostale potrebne informacije o osobi.

Treba napomenuti da ova šema također ima vrlo ograničenu primjenu i ne rješava sve probleme. Šta ako sledeći informacioni sistem odluči da za svoje potrebe koristi isto polje sertifikata „Poboljšani ključ“ (OID=2.5.29.37), koje je već zauzeto Rosreestr vrednošću? Unos dvije različite vrijednosti u jedno polje neće raditi. Stoga ćemo morati izdati još jedan AC! Drugi problem je vezan za kratki vijek trajanja PKC-a (jedna godina). Ako imamo nekoliko AC (koji sadrže link do ličnog sertifikata), svi će morati da budu ponovo izdati nakon što PKC istekne. Za efikasnu upotrebu AC-a, potreban je jedan centar za autorizaciju korisnika u svim informacionim sistemima, a sve aplikacije moraju koristiti atribute certifikata na dosljedan i jedinstven način.

Takav jedinstveni autorizacijski centar za državu. vlasti već postoje - ovo je ESIA. Podsjetimo se napomene u vezi sa Rosreestrovim OID-ovima. U budućnosti će ih zamijeniti informacije iz ESIA. Drugi bi trebali učiniti isto informacioni sistemi u kojoj rade državni službenici. zaposlenima. Umjesto korištenja AC za autorizaciju, potrebno je integrirati se sa ESIA i odatle dobiti potrebne informacije. ESIA bi trebala biti u mogućnosti da veže kvalifikovani ES certifikat za račun Tako će informacioni sistemi moći da autentifikuju korisnika pomoću ličnog ključa, i ovlaste ga (omoguće pristup aplikaciji) putem ESIA. Čini se da je takav sistem univerzalniji i pouzdaniji od upotrebe polja certifikata, a u budućnosti će omogućiti automatizaciju kontrole pristupa. Ako je kreiran jedan sistem kadrovske evidencije stanje zaposlenima, ESIA će moći direktno odatle preuzeti informacije o ovlastima osobe. Osoba je premještena na drugu poziciju - automatski je izgubila pristup nekim sistemima i dobila pristup drugima. Istovremeno, on nastavlja da koristi svoj ES ključ za potpisivanje dokumenata, nema potrebe za ponovnim izdavanjem.

U skladu sa Tehničkim uslovima za CJSC AEI PRIME da objavi informacije o hartijama od vrednosti i drugim finansijski instrumenti, odobren od strane Banke Rusije (), elektronski dokumenti koji sadrži informacije javnog značaja mora biti potpisan od strane subjekta objavljivanja informacija poboljšanim kvalifikovanim elektronskim potpisom (videti tačku 1.7. Tehničkih uslova). Ovaj zahtjev stupa na snagu od 1. februara 2017. godine.

Trenutno je počeo probni period za primjenu elektronskog potpisa na PRIME serveru za otkrivanje podataka, koji će trajati do 31. januara 2017. godine.

Za testiranje funkcionalnosti, PRIME korisnici mogu koristiti bilo koji certifikat ES ključa prethodno primljen za ovo pravno lice.

Od 1. februara 2017. godine, na zahtjev Tehničkih uslova (vidjeti stavove 1.7. i 9.6.), kvalifikovani certifikat ključa za verifikaciju elektronskog potpisa korisnika mora biti u skladu sa zahtjevima za oblik kvalifikovanog certifikata utvrđenim Naredbom Federalna služba bezbednosti Rusije od 27. decembra 2011. br. 795 „O zahtevima za odobrenje obrasca kvalifikovanog sertifikata ključa za verifikaciju elektronskog potpisa. Ekstenzija korisničkog certifikata "Poboljšani ključ" (identifikator objekta 2.5.29.37) mora sadržavati identifikator objekta za otkrivanje informacija PRIME - OID 1.2.643.6.42.5.5.5

Prijava na lični račun korisnika otkrivanja informacija "PRIME" izvršit će se korištenjem LOGIN-a i LOZINKE koje je klijent prethodno primio.

Radnje klijenta na objavljivanju poruka u feedu za otkrivanje informacija, postavljanju dokumenata na stranicu na Internetu, izmjenama registracione kartice izdavaoca u sistemu za otkrivanje informacija moraju biti potvrđene elektronskim potpisom.

Da bi koristio ES na PRIME serveru za otkrivanje informacija, klijent prvo mora instalirati dodatak (instalacija je besplatna za korisnike i ne oduzima mnogo vremena). Pogledajte upute za instalaciju dodatka u nastavku.

U ličnom računu korisnika za otkrivanje informacija, nakon što klijent instalira dodatak, prilikom popunjavanja obrazaca za objavljivanje poruke u feedu za otkrivanje informacija ili postavljanja dokumenta na Internet, kao i prilikom promjene podataka registracije kartice, pojavit će se dodatna polja “Elektronski potpis dokumenta” gdje će biti potrebno odabrati ono koje je prikazano u odgovarajućem servisnom polju certifikat ključa za potpisivanje i kliknuti na dugme “Potpiši”. Na ovaj način klijent će potvrditi svoje radnje da otkrije podatke ili izvrši izmjene na svojoj registracijskoj kartici.

• Nakon potpisivanja poruke elektronskim potpisom, klijent mora kliknuti na dugme "Objavi".
• Nakon potpisivanja dokumenta elektronskim potpisom, klijent mora kliknuti na dugme "Dodaj dokument".
• Nakon potpisivanja promjena u registracijskoj kartici elektronskim potpisom, klijent mora kliknuti na dugme "Pošalji identifikacioni obrazac".

Napominjemo da će sve poruke koje klijenti šalju preko svog ličnog naloga putem autorizacije "Test login (rad sa ES)" biti objavljene u Information Disclosure Feedu u radnom režimu. Svi dokumenti koje klijenti postavljaju preko svog ličnog naloga putem autorizacije "Probni unos (rad sa ES)" biće automatski objavljeni na stranicama izdavaoca u radnom režimu.

U suprotnom, procedura izdavaoca u ličnom računu na PRIME serveru za otkrivanje informacija se ne mijenja.