Slovník pojmů, popisy chyb

Symetrická šifra, někdy též nazývaná konvenční, je takový šifrovací algoritmus, který používá k šifrování i dešifrování jediný klíč. Tím se liší od algoritmů s veřejným klíčem, které mají dvojici klíčů – soukromý a veřejný.

Podstatnou výhodou symetrických šifer je jejich nízká výpočetní náročnost. Algoritmy pro šifrování s veřejným klíčem můžou být i stotisíckrát pomalejší. Na druhou stranu velkou nevýhodou je nutnost sdílení soukromého klíče, takže se odesilatel a příjemce tajné zprávy musí předem domluvit na tajném klíči.

Symetrické šifry se často používají společně s asymetrickými. Obvyklé použití je takové, že otevřený text se zašifruje symetrickou šifrou s náhodně vygenerovaným klíčem. Tento symetrický klíč se zašifruje veřejným klíčem asymetrické šifry, takže dešifrovat data může pouze majitel tajného klíče dané asymetrické šifry.

Symetrické šifry se dělí na dva druhy. Proudové šifry zpracovávají otevřený text po jednotlivých bitech. Blokové šifry rozdělí otevřený text na bloky stejné velikosti a doplní vhodným způsobem poslední blok na stejnou velikost. U většiny šifer se používá blok o 64 bitech, AES používá 128 bitů.

Asymetrická kryptografie (kryptografie s veřejným klíčem) je skupina kryptografických metod, ve kterých se pro šifrování a dešifrování používají odlišné klíče. To je základní rozdíl oproti symetrické kryptografii, která používá k šifrování i dešifrování jediný klíč.

Šifrovací klíč pro asymetrickou kryptografii sestává z dvou částí: jedna část se používá pro šifrování zpráv (a příjemce zprávy ani tuto část nemusí znát), druhá pro dešifrování (a odesilatel šifrovaných zpráv ji zpravidla nezná). Je vidět, že ten, kdo šifruje, nemusí s dešifrujícím příjemcem zprávy sdílet žádné tajemství, čímž eliminují potřebu výměny klíčů; tato vlastnost je základní výhodou asymetrické kryptografie.

Nejběžnější verzí asymetrické kryptografie je využívání tzv. veřejného a soukromého klíče: šifrovací klíč je veřejný, majitel klíče ho volně uveřejní, a kdokoli jím může šifrovat jemu určené zprávy; dešifrovací klíč je soukromý, majitel jej drží v tajnosti a pomocí něj může tyto zprávy dešifrovat. (Existují i další metody asymetrické kryptografie, ve kterých je třeba i šifrovací klíč udržovat v tajnosti.)

Je zřejmé, že šifrovací a dešifrovací klíč spolu musí být matematicky svázány, avšak nezbytnou podmínkou pro užitečnost šifry je praktická nemožnost ze znalosti šifrovacího klíče spočítat dešifrovací.

Šifrovací klíč je informace, která určuje průběh kryptografického algoritmu. Při šifrování, klíč specifikuje transformaci zprávy do šifrovaného textu, při dešifrování je tomu naopak. Klíče se používají také v digitálních podpisových schématech a hašovacích funkcích (také MAC - message authentication code), často používaných na autentizaci.

V bezpečných algoritmech, šifrováním zprávy pomocí různých klíčů dostaneme kompletně různé šifry a také dešifrování nesprávným klíčem dá náhodně vypadající text (nicméně existují také kryptosystémy, kde dešifrování různými klíči může dát různé rozumně vypadající zprávy).

V praxi je užitečné předpokládat, že kryptografický algoritmus je útočníkovi znám a spoléhat se jenom na bezpečnost klíče, protože je většinou jednodušší uchovat v tajnosti relativně malý klíč, nežli detaily algoritmu.

Hašovací funkce je matematická funkce (resp. algoritmus) pro převod vstupních dat do (relativně) malého čísla. Výstup hašovací funkce se označuje výtah, miniatura, otisk, fingerprint či hash (česky též někdy jako haš).

Hašovací funkce se většinou používají k rychlejšímu prohledávání tabulky nebo pro porovnávání dat – například pro hledání položek v databázi, odhalování duplicitních nebo podobných záznamů ve velkém souboru, hledání podobných úseků DNA sekvencí apod.

•	malou změnou vstupních dat dosáhneme velkou změnu na výstupu (tj. výsledný otisk se od původního zásadně na první pohled liší),

•	v praxi je vysoce nepravděpodobné, že dvěma různým zprávám odpovídá stejný hash, jinými slovy pomocí hashe lze v praxi identifikovat právě jednu zprávu (ověřit její správnost).

HTTPS je v informatice nadstavba síťového protokolu HTTP, která umožňuje zabezpečit spojení mezi webovým prohlížečem a webovým serverem před odposloucháváním, podvržením dat a umožňuje též ověřit identitu protistrany. HTTPS používá protokol HTTP, přičemž přenášená data jsou šifrována pomocí SSL nebo TLS a standardní port na straně serveru je 443.

Protokol HTTPS využívá asymetrické šifrování. Obě strany si před zahájením komunikace vygenerují pár klíčů (privátní a veřejný). Při zahájení komunikace si vymění veřejné klíče, které by obě strany měly ověřit pomocí jiného komunikačního kanálu. Ověření může proběhnout kontrolou výtahu (otisk, miniatura, hash) veřejného klíče u protistrany například pomocí telefonu nebo lze použít princip přenosu důvěry, kdy nám protistrana předá veřejný klíč, který je digitálně podepsaný (nejlépe certifikační autoritou, které důvěřujeme a jejíž veřejný klíč máme v důvěryhodném úložišti, např. THAWTE, VeriSign, RapidSSL, GeoTrust, ...).

Zatímco samotné šifrování ochrání komunikaci před odposloucháváním, bez ověření autenticity veřejných klíčů jsou komunikující strany vystaveny riziku útoku Man in the middle (Osoba uprostřed).

Za certifikáty vydané certifikačními autoritami, které mají svůj veřejný klíč v úložišti, které je dodáváno s webovým prohlížečem, je nutné platit. Existuje však možnost vytvoření certifikátu, který si vydavatel sám sobě podepíše (anglicky self-signed certificate), avšak v takovém případě musí protistrana přidat do úložiště veřejný klíč sama (a ověřit ho jinak).

Digitální certifikát je v asymetrické kryptografii digitálně podepsaný veřejný šifrovací klíč, který vydává certifikační autorita. Uchovává se ve formátu X.509, který (kromě jiného) obsahuje informace o majiteli veřejného klíče a vydavateli certifikátu (tvůrci digitálního podpisu, tj. certifikační autoritě). Certifikáty jsou používány pro identifikaci protistrany při vytváření zabezpečeného spojení (HTTPS, VPN atp.). Na základě principu přenosu důvěry je možné důvěřovat neznámým certifikátům podepsaných důvěryhodnými certifikačními autoritami, přičemž se obvykle používá hierarchický model.

Data v certifikátu jsou popsána jazykem ASN.1. Výhody ASN.1 spočívají v nezávislosti na počítačové platformě a dobré čitelnosti pro člověka. K převodu do binární podoby se používá kódování DER nebo CER a následovně ještě Base64. Soubor s digitálním certifikátem je po otevření zobrazen v čitelné podobě, což umožňuje zkontrolovat údaje o jeho předpokládaném majiteli.

•	Serial Number – (certifikáty mají pro lepší identifikaci vlastní sériové číslo, není to však nutnost)

•	Valid-To – datum konce platnosti certifikátu; nejběžnější doba platnosti je jeden rok

•	Key-Usage – účel veřejného klíče (šifrování, ověřování podpisů nebo obojí)

•	Thumbprint – vlastní otisk certifikátu sloužící k ověření neporušenosti certifikátu

Pro vytvoření digitálního podpisu v digitálním certifikátu jsou používány algoritmy RSA, DSA nebo ElGamal.

Jedná se o digitální certifikát. V České republice je zákonem definován tzv. kvalifikovaný certifikát, který může vydat pouze akreditovaná kvalifikovaná certifikační autorita řídící se Zákonem o elektronickém podpisu (zákon č. 227/2000 Sb.). Jde o standardní digitální certifikát, který je však výše zmíněným zákonem uznáván v rámci komunikace se státními institucemi České republiky. Kvalifikovaný certifikát je ze zákona akceptován stejně jako občanský průkaz, avšak možnost využití kvalifikovaného certifikátu je omezena na vyjmenované případy:

Získání certifikátu: nejlépe prostřednictvím České pošty, cena dříve 190,- Kč (nyní 390,- Kč), jinak též u První certifikační I.CA - cena je vyšší

Je určen pro fyzické osoby, do certifikátu lze naplnit osobní údaje žadatele.

•	vytvořené elektronické žádosti (pokud žadatel nezvolil její uložení na server I.CA)

Je určen pro fyzické osoby zaměstnance nebo OSVČ, do certifikátu lze naplnit k údajům žadatele také identifikaci zaměstnavatele, živnosti.

•	vytvořené elektronické žádosti (pokud žadatel nezvolil její uložení na server I.CA)

•	doložení existence společnosti ne starší 6 měsíců (výpis z obchodního rejstříku, živnostenský list, potvrzení ČSU o registraci a přidělení IČ..)

Komerční certifikáty mají svoji významnou úlohu především tam, kde nelze s ohledem na platnou legislativu využít kvalifikované certifikáty. Je vhodný pro obchodní použití mimo oblast komunikace s orgány veřejné moci, na které se vztahuje povinnost využívat certifikáty kvalifikované. Nejčastěji se používá v komunikaci mezi komerčními subjekty pro šifrování a autentizaci. Jedná se především o neanonymní přístup na webové servery a předávání šifrovaných dat, jak e-mailovou poštou, tak prostřednictvím webových formulářů.

Osobní komerční certifikát - Je určen pro fyzické osoby, do certifikátu lze naplnit osobní údaje žadatele.

•	vytvořené elektronické žádosti (pokud žadatel nezvolil její uložení na server I.CA)

Je určen pro fyzické osoby, do certifikátu lze naplnit k údajům žadatele také identifikaci zaměstnavatele, pozici ve firmě apod.

•	vytvořené elektronické žádosti (pokud žadatel nezvolil její uložení na server I.CA)

•	doložení existence společnosti ne starší 6 měsíců (výpis z obchodního rejstříku, živnostenský list, potvrzení ČSU o registraci a přidělení IČ..)

Certifikační autorita (zkratka CA) je v asymetrické kryptografii subjekt, který vydává digitální certifikáty (elektronicky podepsané veřejné šifrovací klíče), čímž usnadňuje využívání PKI (Public Key Infrastructure) tak, že svojí autoritou potvrzuje pravdivost údajů, které jsou ve volně dostupném veřejném klíči uvedeny. Na základě principu přenosu důvěry (viz níže) tak můžeme důvěřovat údajům uvedeným v digitálním certifikátu za předpokladu, že důvěřujeme samotné certifikační autoritě.

Na Internetu působí mnoho komerčních certifikačních autorit, které obvykle mají své veřejné klíče umístěny přímo ve webových prohlížečích a dalších programech, čímž mohou uživateli zjednodušit rozhodování o míře důvěry webových serverů, ke kterým se připojuje (ale též digitálně podepsaných e-mailů i jiných dat). Existují též bezplatné certifikační autority nebo takové, které se řídí zákony daného státu, vnitřními předpisy organizace a podobně.

Certifikační autorita vydává digitální certifikáty, což jsou elektronicky podepsané veřejné šifrovací klíče, které obsahují identifikační údaje svého majitele, za jejichž správnost se certifikační autorita zaručila. Když certifikační autorita podepíše svůj vlastní klíč, jedná se o certifikát podepsaný sám sebou (anglicky self-signed certificate).

Majitel veřejného klíče musí proto při žádosti o vydání digitálního certifikátu důvěryhodným způsobem certifikační autoritu přesvědčit, že jím poskytnuté údaje odpovídají skutečnosti a tomu, co uvedl ve svém veřejném klíči. Může tak například učinit:

Po ověření a porovnání výše uvedených údajů vydá certifikační autorita digitální certifikát, který ověřené údaje obsahuje. Důležitou součástí digitálního certifikátu je elektronický podpis, kterým lze snadno ověřit jeho autentičnost. Pokud by byly údaje v digitálním certifikátu změněny, kryptografické ověření digitálního podpisu by změnu odhalilo.

Hodnota digitálního certifikátu je úměrná míře důvěry, kterou máme k údajům v něm uvedených. Proto je pro certifikační autoritu nejdůležitější důvěra, kterou vůči svému okolí vzbuzuje (tj. že nevydá digitální certifikát s nepravdivými údaji). Certifikační autorita proto musí adekvátním způsobem pečovat o svoji důvěryhodnost, jinak by nebylo možné využít principu přenosu důvěry (viz níže). Důvěryhodnost certifikační autority můžeme posoudit podle jejích webových stránek, použitého mechanismu ověření údajů, které žadatel o digitální certifikát předkládá a dalších znaků (články v tisku a elektronických médiích, kótované akcie a podobně). Cena vydaného certifikátu (resp. oblíbenosti certifikační autority) pak obvykle odpovídá této těžko exaktně definovatelné míře důvěry.

Placené certifikační autority získávají od svých klientů peníze, které používají jednak na zajištění vlastní činnosti, ale hlavně na platbu za zařazení vlastních kořenových certifikátů do software, který využívá přenosu důvěry (viz níže). Certifikační autority tak platí za distribuci svých kořenových certifikátů v Microsoft Windows, Firefoxu a dalších programech.

Přenos důvěry se běžně využívá v reálném světě. Čteme časopisy, noviny, hovoříme s lidmi, sledujeme televizi. Pokud se dozvíme něco nového, přikládáme informaci váhu podle důvěryhodnosti zdroje informací. Přenášíme tak důvěryhodnost zdroje informací na jím poskytovanou informaci. Věříme více svým blízkým přátelům nebo autoritám (seriózní noviny, učitel ve škole, kvalitní kniha, odborný pořad v televizi). Naopak s rezervou obvykle přistupujeme k informacím „jedna paní povídala“ nebo k reklamě. Nevěříme řádně odsouzenému člověku nebo prokázanému falzifikátu (např. Rukopis zelenohorský).

Stejným způsobem se uplatňuje přenos důvěry u certifikační autority. Je-li certifikační autorita důvěryhodná, můžeme věřit informacím uvedených v digitálních certifikátech, které vydala (resp. digitálně podepsala). Věříme, že by certifikační autorita nevytvořila digitální certifikát s nepravdivými údaji.

V počítači jsou šifrovací klíče uloženy v úložišti certifikátů nebo v klíčence. Při ověřování autentičnosti veřejného klíče můžeme využít toho, že klíč je digitálně podepsán důvěryhodnou certifikační autoritou (jinou osobou atp.). Pokud je digitální podpis certifikátu platný a důvěřujeme certifikační autoritě, která klíč podepsala, přeneseme důvěru a věříme v důvěryhodnost neznámého veřejného klíče.

Pro usnadnění přenosu důvěry jsou v počítači obvykle předem přítomny kořenové klíče certifikačních autorit, které jsou distribuovány buď přímo s operačním systémem (Microsoft Windows) nebo s příslušnou aplikací (Firefox, Opera, Thunderbird atd.). Do úložiště je možné přidávat další certifikáty a následně důvěřovat certifikátům, které jsou jimi ověřitelné.

Kvalifikovaná certifikační autorita je rámci České republiky definována Zákonem o elektronickém podpisu (zákon č. 227/2000 Sb.). Seznam akreditovaných certifikačních autorit, které mohou vydávat kvalifikované certifikáty zveřejňuje Ministerstvo vnitra České republiky.

Akreditovaná certifikační autorita vydává (zpoplatněné) kvalifikované certifikáty, což jsou standardní digitální certifikáty, které však jsou výše zmíněným zákonem uznávány v rámci komunikace se státními institucemi České republiky. Kvalifikovaný certifikát je ze zákona akceptován stejně jako občanský průkaz, avšak možnost využití kvalifikovaného certifikátu je omezena na vyjmenované případy (státní instituce musí být připraveny a jejich zaměstnanci příslušně proškoleni):

Z hlediska právní platnosti je jedno u které akreditované certifikační autority je certifikát vytvořen. Kvalifikované certifikáty se řídí RFC 3039, přičemž zákon dále nařizuje používání položek Key Usage a nonRepudiation bitu. Problémem kvalifikovaných certifikátů je šifrování, protože elektronický podpis nezahrnuje důvěrnost (realizovanou šifrováním).

Kvalifikované certifikační autority stojí v současné době mimo klasické celosvětově působící certifikační autority a zákon ani jiný stav nepředpokládá. Před ověřením kvalifikovaného certifikátu si proto uživatel musí do příslušného programu (webový prohlížeč, e-mailový klient) sám nainstalovat certifikát příslušné kvalifikované certifikační autority (a sám ověřit jeho důvěryhodnost), což je v současné době pravděpodobně nejslabší místo kvalifikovaného certifikátu, protože důležitost jeho důvěryhodnosti kvalifikované certifikační autority nezdůrazňují a své certifikáty mají jednoduše vystaveny na svých webových stránkách.

Internetová služba na stránkách České správy sociálního zabezpečení. Podrobnější informace o možnostech a fungování zde http://www.cssz.cz/cz/e-podani/. Komunikace technicky probíhá téměř shodně jako s PVS - je k ní třeba soukromý kvalifikovaný certifikát a šifrovací certifikát ČSSZ.

Elektronická hlášení na daňový portál lze posílat přímo jako podepsané XML soubory do rozhraní EPO. Data nejsou šifrována, proto je k činnosti nutný pouze osobní kvalifikovaný certifikát.

Internetová služba na http://www.portalzp.cz/ sdružující následující ZP (Česká průmyslová zdravotní pojišťovna; Oborová zdravotní pojišťovna zaměstnanců bank, pojišťoven a stavebnictví; Revírní bratrská pokladna, zdravotní pojišťovna; Vojenská zdravotní pojišťovna České republiky; Zaměstnanecká pojišťovna Škoda; Zdravotní pojišťovna Metal-Aliance; Zdravotní pojišťovna MÉDIA).

Tajný digitální klíč, pomocí něho je pouze jeho majitel schopen dešifrovat zprávu zakódovanou jeho spřaženým veřejným klíčem.

Veřejný klíč jednotlivých institucí (MFČR, ČSSZ) nebo PZP. Používají se v komunikaci s cílovým úřadem k zašifrování zprávy.

Veřejná část dvojice spřažených digitálních klíčů. Pomocí něj může kdokoliv zakódovat libovolný text (dokument, mail, ...) a pouze majitel odpovídajícího soukromého klíče je schopen takovou zprávu dešifrovat a přečíst.

Extensible Markup Language (zkráceně XML, česky rozšiřitelný značkovací jazyk) je obecný značkovací jazyk, který byl vyvinut a standardizován konsorciem W3C. Je zjednodušenou podobou staršího jazyka SGML. Umožňuje snadné vytváření konkrétních značkovacích jazyků (tzv. aplikací) pro různé účely a různé typy dat. Používá se pro serializaci dat, v čemž soupeří např. s JSON či YAML. Zpracování XML je podporováno řadou nástrojů a programovacích jazyků.

Jazyk je určen především pro výměnu dat mezi aplikacemi a pro publikování dokumentů, u kterých popisuje strukturu z hlediska věcného obsahu jednotlivých částí, nezabývá se vzhledem. Prezentace dokumentu (vzhled) může být definována pomocí kaskádových stylů. Další možností zpracování je transformace do jiného typu dokumentu, nebo do jiné aplikace XML.

Jedná se identifikátory subjektu přidělované jednotlivými úřady, jimž se podání posílá (MFČR, ČSSZ, celní správa,...). Je třeba je po získání zapsat na záložce Nastavení parametrů | Portál veřejné správy.

Variabilní symbol ČSSZ - dříve 8-mi místný, nyní 10-ti místný. Subjektu přidělí ČSSZ. Je vyžadován při registraci služeb ČSSZ.

•	Nelze jej editovat, načítá se z parametrů, z Konfigurace / Konfigurace mezd / Plátcova pokladna, z hodnoty „Variabilní symbol starý“.

V případě použití testovací větve portálu je zde umístěn portálem přidělený identifikátor.

•	Nelze editovat, načítá se z parametrů aplikace. Při volbě "testovací podání - vlastní" musíte zadat.

Správce daně je oprávněn poskytovat daňovému subjektu informace shromažďované ve spisu a na osobním daňovém účtu tohoto daňového subjektu prostřednictvím dálkového přístupu v rozsahu a členění, v jakém jsou tyto informace soustředěny v daňové informační schránce daňového subjektu na společném technickém zařízení správců daně, která je zřízena na základě žádosti daňového subjektu.

Žádost o zřízení nebo zrušení schránky lze podat správci daně místně příslušnému podle § 4 odst. 1, 3 a 4 zákona č.337/1992 Sb., o správě daní a poplatků, ve znění pozdějších předpisů, pouze prostřednictvím datové zprávy opatřené zaručeným elektronickým podpisem, jehož součástí je identifikační kód MPSV, ve struktuře a tvaru zveřejněném správcem daně. Správce daně rozhodne o zřízení nebo zrušení schránky do 15 dnů od obdržení žádosti.

Přístup k informacím soustředěným ve schránce je umožněn fyzické osobě, která je daňovým subjektem nebo která je oprávněna jménem daňového subjektu, popřípadě za daňový subjekt, jednat, na základě její Přihlášky k nahlížení do daňové informační schránky. Tuto přihlášku lze podat správci daně, který schránku zřizuje, pouze prostřednictvím datové zprávy opatřené zaručeným elektronickým podpisem ve struktuře a tvaru zveřejněném správcem daně. Správce daně do 15 dnů od obdržení přihlášky umožní této osobě přístup k informacím ve schránce prostřednictvím jejího zaručeného elektronického podpisu, který obsahuje identifikační kód MPSV. O vyřízení přihlášky správce daně učiní úřední záznam do spisu daňového subjektu, jehož schránka byla předmětem přihlášky.

V případě, že doposud neexistuje daňová informační schránka daňového subjektu, do které chce fyzická osoba nahlížet, není možné Přihlášku k nahlížení do daňové informační schránky kladně vyřídit správcem daně.

Do daňové informační schránky může nahlížet zástupce daňového subjektu na základě udělené plné moci nebo pracovník pověřený statutárním orgánem jednat jménem daňového subjektu, který je právnickou osobou, pouze tehdy, jsou-li oprávněni na základě svého zmocnění nebo pověření jednat při správě daní v neomezeném rozsahu se všemi správci daně, jimiž získané informace se shromažďují na společném technickém zařízení správců daně, nebo pokud jejich zmocnění nebo pověření umožňuje výslovně nahlížení do schránky. Toto zmocnění nebo pověření je nutné uplatnit u správce daně, který schránku zřizuje.

O nahlížení do daňové informační schránky požádá fyzická osoba prostřednictvím Přihlášky k nahlížení do daňové informační schránky .

Daňový subjekt může zmocnit fyzickou osobu k nahlížení do daňové informační schránky udělením Plné moci nebo Plné moci pro nahlížení do daňové informační schránky (viz podmínky) .

Pokud by Váš zájem přesahoval informace zde uvedené, můžete použít informace uvedené na některém ze zde uvedených portálů:

Certifikáty jednotlivých bran pro podpisy jsou vystaveny na adresách dle schématu uveřejněného zde

V této verzi byla výrazně přepracován systém práce s certifikáty a nyní se s nimi pracuje prostřednictvím jejich jednoznačného identifikátoru (hash, miniatura). Při startu modulu se spustí proces, který se snaží v Nastavení parametrů definované certifikáty otevřít, zjistit jejich hash a tento vložit do záznamu o certifikátu v databázi. V případě, že souborový certifikát není na uvedené cestě nebo že se nevyskytuje v systémovém úložišti, není možné proces správně dokončit. Modul EP při startu vypíše hlášení o všech nenalezených certifikátech uživatele.

1.	Pokud chceme používat systémové úložiště, je třeba nejprve certifikáty do tohoto úložiště naimportovat, např. pomocí Nastavení parametrů \| Správce certifikátů

•	pomocí dialogu na záložce Identifikace certifikátu v úložišti nastavit správnou cestu v případě souborového certifikátu

•	pokud je pro přístup k souborovému certifikátu třeba heslo, vložit toto do pole Heslo pro otevření úložiště

•	stisknout tlačítko Vybrat certifikát: objeví se druhá ze záložek (Nastavení certifikátu) a na ní by měly být správné údaje vyčtené z certifikátu

•	pokud je nastaven Typ úložiště jiný než Souborové úložiště, po Vybrat certifikát se toto otevře a můžeme nastavit dříve naimportovaný vhodný certifikát

Parametry modulu EP jsou individuální, proto je třeba aplikovat následující postup u každého uživatele využívajícího modul Elektronické podání

Z důvodů ochrany osobních údajů byla v této verzi doplněna restrikce, která řídí zobrazení dávek uživateli.

Restrikce se jmenuje epViewDavky a má 4 možné parametry, které zpřístupňují 4 základní okruhy dávek EP:

Při upgrade na verzi 161 se provede automatické přednastavení této restrikce následovně:

Z důvodu neohlášených změn na straně dodavatele knihovny pro komunikaci s Portálem zdravotních pojišťoven došlo k tomu, že starší knihovna PVTPZP.dll vykazovala při komunikaci s některými ZP chybu. Bylo nutno přejít na novější knihovnu ASSECOPZP.dll. Z tohoto důvodu je nutná odinstalace knihovny PVTPZP a registrace knihovny ASSECOPZP (upozornění proběhlo 18.9.2014 na webu IS Vision ERP, instalační postup je distribuován v balíčku EP.zip). Pokud se tak nestane, může se při odesílání dávky na ZP objevit chyba 1006.

Chyby, které systém event. vrátí při elektronickém podání, mohou být několika typů (dále uvedený seznam není konečný, bude dále rozšiřován).

Chyba se objeví při akci Testovat podpis v Nastavení parametrů | Správce certifikátů

Pokud je použit o osobní kvalifikovaný certifikát vydaný ČSOB, je problém zde.

Banka vydává na kartě 2 certifikáty: osobní kvalifikovaný a komerční. První jmenovaný pak má ve vlastnostech, záložka Podrobnosti, pole Použití klíče: Digitální podpis, Neodvolatelnost (c0), druhý pak: Digitální podpis,
Zakódování klíče, Zakódování dat, Shoda klíče (b8) Tedy: prvním lze sice podepisovat, nikoliv ale šifrovat nebo dešifrovat. V bance je tato politika ověřena, osobní kvalifikovaný certifikát s možností šifrování nevydávají.

Při testování podpisu se použije osobní kvalifikovaný certifikát zaregistrovaný ve Vision ERP. Je to proto, že v tomto případě má uživatel oba klíče (veřejný i soukromý) a tudíž může provést obě operace: zašifrovat veřejným klíčem, dešifrovat soukromým. V případě použití výše uvedeného osobního kvalifikovaného certifikátu operace selže.

Vzhledem k tomu, že se při komunikaci s VREP šifrování dat osobním certifikátem nepoužívá (šifruje se jednotlivými šifrovacími certifikáty portálů), nemá tato vlastnost na funkčnost Elektronického podání jako takového vliv.

Další možnou variantou výskytu chyby 8194 je, když obsluha místo osobního kvalifikovaného certifikátu zaregistruje do Vision ERP pouze jeho veřejnou část, kterou obdržela od certifikační autority. Při odesílání podání se potom neobjeví dotaz na heslo k privátní části certifikátu (tady žádná není) a objeví se chyba 8194.

Chyba se objeví při pokusu odeslat podání. Jde v drtivé většině o selhání připojení čtečky karty s certifikátem - nějaký technický problém s USB připojením, kontakt na kartu ve čtečce apod. Řešením je odpojit na několik sekund čtečku od počítače a opět ji připojit, případně vyndat a opět vložit kartu do čtečky. Problém by měl být odstraněn (vhodná je kontrola pomocí manažera karty, např. SecureStore).

•	Chyba 1046 Zdroj: Neurodot.GG.Submission.SubmAuth (kritická chyba) The supplied user credentials failed validation for the requested service. Sender not autheticated: Action not permitted for this userAction not permitted for this user

Komentář: uživatel posílající podání nebyl na portálu ověřen a jeho podání bylo odmítnuto. Důvodem je obvykle žádná nebo nesprávná registrace k požadované službě (podání ELDP, ...) na patřičném portálu případně na příslušném úřadě nebo propadlý případně nezaregistrovaný certifikát uživatele tamtéž.

Dalším zdrojem této chyby (obvykle po změnách v instalaci Vision ERP) je špatný variabilní symbol - VarSymbol, chyba v přihlašovacím identifikátoru nebo heslu pro VREP.

Komentář: Jde o interní chybu VREP. Zahlcený portál se chová nekorektně a došlo k chybě v průběhu komunikace, případně zpracování dávky. Server VREP není schopen díky zatížení včas odpovědět a vznikne time-out. Pokud vznikla chyba na počátku komunikace je třeba odeslání dávky za nějaký krátký čas opakovat (není třeba dávku znovu vytvářet, ale její smazání a znovuvytvoření nezpůsobí problém). Pokud chyba vznikla v průběhu komunikace (až po přidělení Correlation ID dávce a jeho doručení do Vision ERP), pak může dojít k situaci, kdy do programu přijde chyba 1000 a je nastaven stav dávky na Zamítnuto, přitom dávka na serveru je zpracována a může být přijata. Vznikne rozpor a hlavně: do informací o dávce není doručen identifikátor a heslo pro DPH, pod kterým lze zkontrolovat stav zpracování dávky na serveru MFČR. V tomto speciálním případě umožní program změnit tlačítkem na detailu dávky stav na Čeká na vyhodnocení a lze se dotázat přes VREP na stav zpracování dávky (od verze EP 159 2.1.31.405). Výsledkem je např. načtení identifikátoru a hesla podání DPH nebo SHV.

- dočasným nebo trvalým zamezením přístupu k Internetu (např. nastavením proxy serveru v konfiguraci Vision ERP, pokud tento firma používá)

Komentář: tato chyba je způsobena špatně zvoleným šifrovacím certifikátem ČSSZ.

Komentář: nastane obvykle tehdy, když osobní kvalifikovaný certifikát není vnitřně v pořádku. Jako příklad může posloužit spojení nesignované veřejné části certifikátu se soukromou. Certifikát je pak z hlediska funkčnosti v pořádku, nelze jej ale použít pro odesílání. Jako vydavatel je zobrazen autor certifikátu, nikoliv certifikační autorita (PostSignum, I.CA,...). Zpráva odeslaná na VREP a podepsaná takovýmto certifikátem bude vždy odmítnuta z titulu neověřeného subjektu, který zprávu zaslal.

Chyba stejného významu se může vyskytnout i v případě, že v systémovém úložišti počítače se nenachází certifikáty certifikační autority, která certifikát vydala (např.http://www.postsignum.cz/certifikaty_autorit.html). Jako vystavitel je pak zobrazeno jméno majitele certifikátu a podání na straně VREP selže. Může k tomu dojít např. při přenosu certifikátu z počítače na počítač.

•	Chyba PVPOJ12: 003 - Dokument neprošel validací XML schématu. Není-li uvedena jiná příčina chyby, pak může být důvodem nedovolená přítomnost znaku mezera v údajích: PSC, ulice, jmeno, prijmeni, telefon, apod.

•	Při přenosu certifikátu ze systému Windows XP na Windows Vista a vyšší dochází k problému, kdy se při importu objeví následující hlášení:

Chybu vrací VREP, ale jde o přeposlanou chybu některého konkrétního portálu (ČSSZ, ...)

•	Chyba 3001 Zdroj: Department ( kritická chyba ) Datum v položce Důvody pro podání dodatečného daňového přiznání zjištěny dne je v termínu pro podání běžného (opravného) DAP . Je nutné podat běžné (opravné) DAP.

Komentář: obecná číslo chyby pro chybu ve vložené datové větě, zasílá konkrétní adresovaný portál (např. ČSSZ.)

•	Chyba 3001: Při zpracování požadavku byla zaznamenána chyba: chyba při vytváření instance Nastavení (org.apache.tomcat.dbcp.SQLNestedException: Cannot get a connection, pool exhausted)

Komentář: zahlcený portál se chová nekorektně, je třeba odeslání dávky za nějaký krátký čas opakovat (není třeba dávku znovu vytvářet, ale její smazání a znovuvytvoření nezpůsobí problém)

Chyba 3001: (Kritická chyba) Chyba při ověřování podepsaných dat (podpis není platný): [2] Popis: KryptoOperace:: overPodpisZarepJni: Podpis není platný

Komentář: Certifikáty vystavené v roce 2010 používají algoritmus SHA2, pro nějž je podpora v operačním systému až od Windows XP SP3 a výše. V Win XP SP2 a méně cryptoAPI SHA2 nezpracuje.

•	Chyba: Certifikát pro šifrování se nepodařilo najít (0x80092004). Objekt nebo vlastnost nebyly nalezeny

Komentář: chybně nainstalovaný nebo nesprávný osobní kvalifikovaný certifikát (rozdíl v údajích zaregistrovaných ve Vision ERP / EP / Parametry a certifikátem v úložišti zde nastaveném), případně stejný problém u šifrovacích certifikátů pro jednotlivé DIS

•	Chyba: Nepodařilo se otevřít úložiště certifikátů (0 x 15). Zařízení není připraveno

Komentář: šifrovací certifikát pro dotčený DIS (MFČR, ČSSZ,...) je používán ze souborového úložiště a někdo ho poté, co ho zaregistroval do EP Vision ERP odstranil nebo přesunul do jiného adresáře.

•	Chyba: Chyba nastavení. Zkontrolujte prosím nastavení certifikátů a známých údajů pro elektronická podání.

Komentář: nejspíše není do Vision ERP zaveden některý z potřebných certifikátů (osobní nebo některý DIS šifrovací).

Chybové stavy jsou přejaty z dokumentace knihovny ASSECOPZP.dll firmy Asseco Central Europe a jsou rozděleny do dvou skupin. Jednu skupinu chyb vrací knihovna a jsou to chyby, které se staly při kontrole vstupních dat, podepisování či přímo při komunikaci s portálem ZP. Druhá skupina chyb jsou chyby, které vrací portál ZP při zpracování požadavku.

•	Chyba 1001: Neznámá zkratka ZP. ZP může být pouze jedna z hodnot CPZP, OZP, RBP, ZPS, VoZP,PZP, PILOT, PILOT-PZP

•	Chyba 1002: Neznámá služba. Služba může být pouze jedna z hodnot VYU, HOZ, PPPZ, VERPOJ, VERZZ, ORL, PRESMER, SCHRANKA, EXE_PO, EXE_FO, P2_IMPORT

•	Chyba 1003: Nenalezen předaný soubor … Soubor předaný v parametru DataIn nebyl nalezen.

•	Chyba 1006: Obsahem výstupních parametrů DataOut a Debug_XML_odpoved je chybová HTML stránka

•	Chyba 0: Zpracování skončilo v pořádku, výstupní data byla zpracována a uložena do výstupních parametrů. Podání je uloženo na serveru a v parametru ID_Podani je jeho číslo.

•

ostatní Chybové stavy při zpracování podání na portálu ZP: validní odpověď stejně jako při nulové chybě, akorát nedojde ke správnému zpracování podání vlivem nesrovnalostí údajů ve vstupních datech (není oprávnění, chybná struktura dat, nebyly předány všechny informace, chyba kontrol vstupních dat apod.). Chyba není pouze číselného charakteru ale jedná se o jakýkoliv alfanumerický kód jiný než v předchozích případech.

Komentář: v programu Vision ERP je nastaven implicitní čas, po který systém čeká po dotazu na odpověď vzdáleného serveru. Ten je standardně 90 s a někdy tento čas nestačí. Doporučujeme nastavit delší, obvykle stačí 180 s - Menu | Nástroje | Elektronická podání | Nastavení parametrů | záložka Ostatní nastavení. V opačném případě může jít o problém s připojením na web.

V případě používání proxy serveru může být příčinou jeho změna nebo špatné nastavení - chyba se pak objevuje poměrně rychle po spuštění podání. V tomto případě kontaktujte svého správce sítě a sjednejte nápravu stran nastavení proxy serveru.

Komentář: program není schopen navázat HTTPS zabezpečené spojení. To může být způsobeno nepovoleným protokolem TLS 1.2, případně TLS 1.0, TLS 1.1. Je dobré zakázat protokol SSL 3.0. Další možnou příčinou je blokování spojení firemním firewallem.

Komentář: může být způsobeno dočasným výpadkem funkčnosti portálu. Opakujte podání za nějakou dobu. V případě vícenásobně opakované chyby kontaktujte podporu Vision, případně podporu EPO.