Existuje několik možných variant předávání:

• v IS Orsoft vznikne XML, který se předá přes webovou aplikaci JEPO (nutný el. podpis)
• v IS Orsoft vznikne XML, který se předá přes datovou schránku (není nutný el. podpis, ale nedá se sledovat stav předávání)
• v IS Orsoft vznikne XML, který se rovnou přes Orsoft předá na Portál veřejné správy a následně je to doručeno na MF ČR

Dle našeho názoru je nejlepší varianta 3 - Orsoft předává data na MF ČR přes PVS, jedná se o bezpečnou, vyzkoušenou a zaručenou cestu, je možné sledovat stav podání a uživatel má více informací o tom, že tam podání opravdu přišlo.

Napsal jsem takový krátký komix, jak nastavit všechny komunikační vazby v Orsoftu.

http://web.ortex.cz/jklientpvs/pub/komix_mf_ds_edp.pdf

Honza K.

Od 1.1.2010 budou mít i certifikační autority povinnost vydávat pouze 2048 bitů a výše. Také bude končit podpora pro hashovací funkce SHA-1. Za bezpečné v současné době můžeme považovat hashe třídy SHA-2. Je otázka, zda budou i ČSSZ a MF-ČR přijímat podpisy učiněné třídami SHA-2 (správně bych se měl ptát kdy a ne zda).

Honza K.

Tato chyba ukazuje na nesoulad mezi následujícími autentikačními entitami:

• účet na Portál veřejné správy
• heslo PVS
• povolené služby
• variabilní symbol u služby

Tato chyba se netýká ani šifrování, ani podpisových certifikátů, ani dat zasílanými na ČSSZ (či MF,...)

Tato chyba bývá často způsobena těmito situacemi:

1. Špatné heslo při zasílání dat na PVS (tzv. "druhé heslo" ).
2. Uzamčený účet - pokud 3x zadáte špatné dojde k zablokování účtu a tento je třeba odemknout zavoláním na obsluhu PVS - 800 20 21 22.
3. Při změně VS na VS10 - došlo ke změně nastavení VS na straně Orsoftu (JklientaPVS) a nedošlo ke změně VS->VS10 na straně Portálu (a vice versa).
4. Je třeba mít správně nastaven účet PVS v konfiguraci (tzv. SenderID), variabilní symbol v typech transakcí
5. Setkal jsem se několikrát (leden 09) se situací, že uživatel správně změnil VS->VS10 na PVS, u transakcí CSSZ_ONZ a CSSZ_RELDP (u CSSZ_PRIHL to neměnil, anžto fungovala pouze na data roku 2004-08). Následně však omylem poslal CSSZ_PRIHL místo CSSZ_ONZ (v Orsoftu je to volba d-u-g-...)

Honza K.

http://web.ortex.cz/jklientpvs/pub/novyvs10.pdf

Oficiální informace od ČSSZ si přečtěte tady (postupně tam přidávají informace, které by měli uživatelé vědět už před měsícem ):

http://www.cssz.cz/cz/e-podani/

Honza K.

Řešení existuje a jmenuje se PKCS #12 - Standard pro přenos klíčů. Jedná o zašifrovaný soubor, který má většinou přípony .p12 a .pfx. Je to binární soubor, proto pozor na přenos po FTP (musí být binární).

IS Orsoft: Aktualizace klíčů (*-j-j-a-a) - Další operace - Import klíče/Export klíče. Dále bude vyžadováno heslo při exportu (stejným heslem bude zašifrován i vzniknuvší soubor .p12)

MS Windows: Internet Explorer - Nástroje - Možnosti Internetu - Obsah - Certifikáty - Osobní - Import/Export. Dále je třeba zvolit: "Ano - exportovat soukromý klíč", "Vkládat všechny certifikáty na certifikační cestě", zadat heslo pro exportovaný soubor.

Lotus Notes: Soubor - Zabezpečení - Zabezpečení uživatele - Vaše totožnost - Certifikáty - Vaše Certifikáty Internetu - Získat certifikáty - Importovat internetové certifikáty

Mozilla ThunderBird: Nástroje - Nastavení účtu - Zabezpečení - Zobrazit Certifikáty - Osobní - Import/Export

JKlientPVS: Aktualizace - Klíče - Další operace - Import klíče/Export klíče

Pozn.: Pro QCA PostSignum existuje nástroj pro off-line generování žádosti o certifikát - tzv. PostSignum Tool. Tento nástroj také vytváří PKCS#12 soubor s klíčem. Tento nástroj však nevkládá všechny certifikáty do certifikační cesty.

• Změny při komunikaci s ČSSZ přes PVS
• Odesílání e-mailu přímo z Orsoftu

 Ad 1) Změny při komunikaci s ČSSZ

K tomuto bodu se v současné době vyjádřím jen okrajově - totální hrůza - ještě nyní (3.12.2008) nefunguje testovací větev ČSSZ a není pořádně jasné co a jak bude. Více k této oblasti ve speciálním příspěvku, až budu vědět více.

Myslím, že si pro ten příští příspěvek jako administrátor vyjímečně vypnu kontrolu na sprostá slova .

Ad 2) Emaily přímo z Orsoftu

Odesílání e-mailů z Orsoftu probíhá dle standardu SMTP (RFC 821). Samotné odesílání je realizováno z Javy - programy v knihovně o1j.jar. K odesílání je třeba mít ZČ 9.1 (prosinec 2008).

Předpoklady pro odesílání emailů: 

• Funkční připojení k SMTP serveru.
• Vyplněné jméno SMTP serveru v konfiguraci elektronické komunikace (*-j-a)
• Vyplněné číslo portu pro SMTP komunikaci - standardně "25"
• Vyplněné adresy odesílatelů (alespoň "výchozí") - např. orsoft@firma.cz

Pro vyplnění odesílatelů je třeba brát zřetel na politiky SMTP serverů. Některé SMTP servery nepodporují "relaying", tzn. odesílatel musí být ve stejné doméně ("firma.cz") jako sám SMTP server. V praxi se lze setkat i se složitějšími (restriktivnějšími) politikami SMTP serverů. Obecně je třeba počítat s tím, že v praxi mohou některá nastavení antispamových politik ovlivnit odesílání e-mailů z Orsoftu.

Pozor!!!

E-mail je nezaručená služba! To, že se podařilo odeslat e-mail ještě nezaručuje, že e-mail bude úspěšně doručen. Nelze ani zjistit (s jistotou), že byl e-mail přečten.

Použití e-mailů z Orsoftu (k lednu 2009):

• Odesílání PDF výplatek (LZ)
• Workflow (ZČ)
• Distribuce EDI zásilek v PaC (Fakturace)
• Žádost o následný certifikát na PostSignum (ZČ)
• Odeslání debug balíčku do ORTEXu