Kvalifikované elektronické podpisy jsou zpět, chyba v ověřování zůstává

Počátkem července jsem zde na Lupě psal o tom, jak nové verze hojně používaných programů Adobe Acrobat Reader od verze 26.001.21662 z 9. června matou uživatele nesprávným českým překladem anglického Qualified Electronic Signature: z kvalifikovaných elektronických podpisů, jak je zná naše právní úprava, dělají neexistující „prověřené elektronické podpisy“, které naopak nezná ani právní úprava, ani běžná praxe.

Naštěstí to byla jen krátká epizoda, která končila verzí 26.001.21691. Od verze 26.001.21745 z 23. července jsou kvalifikované elektronické podpisy zpět. Jak ukazuje i předchozí obrázek.

Nakonec tak „prověřené elektronické podpisy“ zůstaly jen na české verzi vlastní stránky společnosti Adobe, na které popisuje různé druhy elektronických podpisů.

Chyba v ověřování zůstává

Mohlo by se tedy zdát, že tato trapná letní epizoda je již jen historií. Bohužel tomu tak není, protože druhý problém, který přišel souběžně s „prověřenými“ podpisy, dosud vyřešen nebyl. Jde o problém s ověřováním kvalifikovaných a uznávaných elektronických podpisů, založených na (kvalifikovaných) certifikátech od společnosti I.CA. Ta o problému již také informovala.

Podstatu problému jsem popisoval v předchozím článku, stejně jako způsob její nápravy vlastními silami. Proto jen obrázek ukazující, že ani v aktuální verzi 26.001.21771 nedošlo k nápravě, a kvalifikované certifikáty od I.CA nadále čerpají důvěru jen ze seznamu AATL. Což má ten důsledek, že Reader si pak nedovodí, že jde o kvalifikovaný certifikát (a že samotný podpis může být buď kvalifikovaný, nebo uznávaný, přesněji: zaručený, založený na kvalifikovaném certifikátu).

Jen pro připomenutí z předchozího článku: řešením je vyprázdnit vlastní úložiště důvěryhodných certifikátů v Readeru, a pak certifikáty znovu stáhnout v obráceném pořadí (nejprve EUTL, a teprve pak AATL). Ale jednodušší je udělat z certifikátu vydavatele (zejména: I.CA EU Qualified CA2/RSA 06/2022) kořenový certifikát. Pak už se Reader chová tak, jak by měl, viz následující obrázek.

Jak si zkontrolovat kotvu důvěry?

Jak jsem také popisoval v předchozím článku, verze 26.001.21662 z 9. června přinesla ještě jednu významnou změnu: místo pouhého konstatování o čerpání důvěry ze seznamu EUTL je nově „upovídanější“ a upřesňuje, že důvěra byla čerpána z lokální verze důvěryhodného seznamu EU, který byl naposledy zkontrolován určitého konkrétního dne.

Je to vlastně disclaimer, který přenáší odpovědnost za případné dosud nepromítnuté změny na uživatele – který je nabádán, aby si sám zkontroloval, zda v mezidobí (od „zkontrolovaného dne XY“ do aktuálního času, kdy probíhá ověřování) nedošlo k nějaké změně v obsahu důvěryhodných seznamů. Současně je uživateli nabízen proklik na prohlížeč oněch důvěryhodných seznamů.

Pro toho, kdo se nechce zabývat detaily, existuje poměrně jednoduché řešení: podívat se, v jaké členské zemi EU byl vydán (kvalifikovaný) certifikát, na kterém je podpis založen. Pak kliknout na onen odkaz a podívat se na datum poslední aktualizace národního seznamu příslušné členské země. A srovnat si data.

U příkladu z přechozího obrázku jde o (kvalifikovaný) certifikát vydaný v ČR, a Reader hlásí „poslední zkontrolování“ 3. 7. 2026. Z následujícího obrázku stránky (na kterou se uživatel dostane po kliknutí na nabízený odkaz) je patrné, že národní důvěryhodný seznam ČR byl vydán (resp. naposledy aktualizován, resp. podepsán) 24. 6. 2026. A jelikož datum 24. 6. 2026 předchází poslední kontrole Readeru (3. 7. 2026), lze z toho dovodit, že k žádné relevantní změně nedošlo.

Správně by se totéž mělo udělat i s časovým razítkem či razítky, pokud jimi je podpis opatřen. V případě časových razítek od tuzemských vydavatelů se to ale „sveze“ se samotným podpisem.

Co v ostatních případech?

Než se pustíme do podrobností a do toho, co dělat v případě opačné časové souslednosti obou časových okamžiků, řekněme si nejprve něco málo o důvěryhodných seznamech. Ten „unijní“, zkratkou LOTL (od List Of Trusted Lists), je vlastně jen jednoduchým rozcestníkem, který odkazuje na jednotlivé národní důvěryhodné seznamy (o tom českém podrobněji zde).

Národní seznamy jsou místem, kde se zveřejňují ty („národní“) služby, které mají kvalifikovaný status. Ten nezískávají rozhodnutím příslušného orgánu (u nás aktuálně DIA), ale právě až zapsáním na národní důvěryhodný seznam. A stejně tak o něj přichází – tím, že jsou na stejném národním seznamu zveřejněny jako služby s odebraným (anglicky Withdrawn) kvalifikovaným statusem. A právě takovéto odebrání je tím, co by si uživatel měl sám zkontrolovat.

Příklad ukazuje následující obrázek: jsou na němu vedeni všichni tuzemští kvalifikovaní poskytovatelé služeb vytvářejících důvěru, i s výčtem těch jejich služeb, které mají či měly kvalifikovaný status. A pro snadné odlišení jsou služby s kvalifikovaným statusem žluté, zatímco ty s již odebraným statusem jsou černé.

K tomu si dodejme, že četnost odebírání (resp. zveřejnění s odebraným statusem) je minimální. Pokud k nějaké změně národního seznamu dochází, je to typicky „přidání“ (udělení kvalifikovaného statusu nové službě), než „odebrání“.

Důvody pro odebrání kvalifikovaného statusu totiž nastávají poměrně vzácně. Může to být změna právní úpravy (viz dále). Nebo oslabení kryptografických algoritmů, se kterými služba pracuje. Případně nějaký bezpečnostní incident, pokud by k němu došlo. Například u certifikátů koncových držitelů by se to řešilo jejich revokací, u služeb spočívajících ve vydávání certifikátů či časových razítek se to řeší odebráním jejich kvalifikovaného statusu.

Předchozí obrázek ukazuje, že v ČR došlo k odebrání kvalifikovaného statusu jen u služeb vydávání časových razítek, a bylo to jen v souvislosti se změnou právní úpravy. Jsou to takové služby, které byly zřízeny a provozovány před účinností současného nařízení eIDAS – a zde jsou uvedeny s odebraným kvalifikovaným statusem (vesměs k 1. 7. 2016, kdy nařízení nabylo účinnosti) hlavně proto, aby nebyly považovány za kotvy důvěry.

Příklad jedné konkrétní služby časových razítek od I.CA, fungující od roku 2013, ukazuje následující obrázek. Kvalifikovaný status jí byl odebrán 1. 7. 2016.

Jak funguje kotva důvěry?

Ono „nepovažování za kotvu důvěry“ si opět zaslouží malé vysvětlení, stejně jak samotný princip kotev důvěry.

Služby spočívající ve vydávání (kvalifikovaných) certifikátů či (kvalifikovaných elektronických) časových razítek jsou na důvěryhodném seznamu reprezentovány svým certifikátem. V případě podpisů (stejně jako pečetí) jsou to typicky certifikáty té dceřiné autority, která vydává (kvalifikované) certifikáty pro elektronické podpisy či pečeti přímo jejich koncovým držitelům, a svým certifikátem je také pečetí.

Při ověřování podpisu na dokumentu pak příslušný nástroj (např. Adobe Reader) stoupá od podpisového certifikátu po tzv. certifikační cestě, tvořené posloupností certifikátů vydavatelů, resp. certifikačních autorit, a snaží se najít takový certifikát (autority), který je uveden na důvěryhodném seznamu s (uděleným) kvalifikovaným statusem.

Pokud jej najde, takovémuto certifikátu důvěřuje bez dalšího. A neprovádí ani kontrolu stavu jeho revokace, jaká se naopak musí provádět u certifikátů koncových držitelů. Může totiž předpokládat, že pokud by k obdobě revokace byl důvod, bude to řešeno právě odebráním kvalifikovaného statusu, resp. zveřejněním služby s odebraným statusem.

A hlavně: takový certifikát, který nástroj najde na důvěryhodném seznamu (s uděleným kvalifikovaným statusem), může využít k tomu, aby důvěru v něj přenesl na všechny certifikáty, které byly v rámci příslušné služby vydány. Přesněji: které byly podepsány (opečetěny) přímo příslušným certifikátem na důvěryhodném seznamu (zde pro jednoduchost zanedbáváme delší certifikační cesty). Právě proto se takovému certifikátu říká kotva důvěry.

Konkrétní příklad ukazuje následující obrázek: jde o podpis, založený na (kvalifikovaném) certifikátu (s příznakem umístění soukromého klíče na kvalifikovaném prostředku, alias QSCD), viz horní část obrázku. Tento certifikát vydala dceřiná autorita I.CA, konkrétně I.CA EU Qualified CA2/RSA2022, viz prostřední část obrázku. A certifikát této dceřiné autority je právě tím, kterým je na národním důvěryhodném seznamu reprezentována konkrétní kvalifikovaná služba vydávání kvalifikovaných certifikátů (pro elektronický podpis i elektronické pečeti), viz spodní část obrázku.

Nyní již se můžeme vrátit k otázce v úvodu této kapitoly: co dělat v případě, kdy „naposledy zkontrolováno“ ze strany Readeru předchází datu vydání (resp. aktualizace) příslušného národního důvěryhodného seznamu: je potřeba zkontrolovat, zda náhodou nedošlo k odebrání kvalifikovaného statusu té služby, v rámci které byl podpisový (či pečetící) certifikát vydán. Sice je to velmi málo pravděpodobné, ale stát se to může.

Důvěryhodný ještě nemusí být kvalifikovaný

A ještě jedno upřesnění: pokud se právě popsaným způsobem dá od nějaké kotvy důvěry dovodit důvěra v certifikát, na kterém je založen konkrétní podpis či pečeť, ještě to nutně neznamená, že jde o kvalifikovaný certifikát (a tím pádem alespoň o uznávaný podpis či pečeť, případně kvalifikovaný podpis či pečeť).

Jde skutečně jen o přenos důvěry (od kotvy dále, resp. „níže“), nikoli o vyjádření kvalifikovaného statusu koncového certifikátu. Takové službě vydávání certifikátů, která má kvalifikovaný status a je na důvěryhodném seznamu reprezentována svým certifikátem, nic nebrání v tom, aby kromě kvalifikovaných certifikátů vydávala (a stejným certifikátem pečetila) i takové certifikáty, které nejsou kvalifikované.

To, zda jde či nejde o kvalifikovaný certifikát (a také zda je to certifikát pro podpis či pečeť), se pozná až podle samotného obsahu certifikátu (v rozšíření QCStatements).

Ostatně, současné vydávání kvalifikovaných i ne-kvalifikovaných (komerčních) certifikátů stejnou dceřinou autoritou je právě příklad I.CA a důvod toho, proč se chyba v ověřování v Readeru projevuje právě u ní, a ne u dalších tuzemských autorit: certifikát dceřiné autority (I.CA EU Qualified …) je uveden jak na důvěryhodném seznamu, tak (i se svým kořenem, kvůli komerčním certifikátům) na seznamu AATL. Dříve to programu Adobe Acrobat Reader nečinilo problémy a jednoduše hlásil, že důvěru čerpá z obou seznamů. Jenže od červnové verze 26.001.21662 mu to začalo dělat výše popsaný problém, který dosud nebyl napraven.

Západ slunce u časových razítek

Když už jsem se takto rozepsal o důvěryhodných seznamech a kotvách důvěry, neodpustím si ještě trochu osvěty kolem životnosti časových razítek. Právě zde totiž existuje zajímavý rozdíl mezi tím, jak funguje řada služeb typu elektronických podatelen OVM, CzechPOINT či třeba program Signer, a co říkají technické standardy. A je to důsledek existence kotev důvěry.

Ukažme si to rovnou na příkladu kvalifikovaného elektronického podpisu z 29. února 2020, který je opatřen časovým razítkem od TSA PostSignum ze stejného dne. Toto časové razítko je založeno na certifikátu s řádnou dobou platnosti do 27. 10. 2025, viz následující obrázek.

Platnost certifikátu tohoto časového razítka již vypršela – a tak většina programů dnes již neověří časové razítko jako platné, a nemůže jej proto využít pro důkaz existence podpisu (PoE, Proof of Existence) v čase připojení časového razítka. Proto nedokáží ověřit samotný podpis jako platný (ale musí konstatovat, že stav jeho platnosti je neznámý).

Následující obrázek ukazuje, jak to dopadne na CzechPOINT-u, kdy podmínkou konverze je platný podpis. Mimochodem, CzechPOINT nerozlišuje mezi neznámým stavem platnosti a neplatností, a vše hází „do jednoho pytle“ neplatnosti.

To program Signer od Sofware602 správně rozlišuje všechny tři možnosti (platný, neplatný a neznámý stav platnosti). Zde konkrétně pokrčí rameny a konstatuje, že platnost podpisu je neznámá.

Obdobně by to dopadlo u většiny podatelen a spisových služeb.

Nicméně podle technických standardů se na časová razítka dá spoléhat déle, než pouze po dobu platnosti certifikátu jejich vydavatele. A to po dobu, kdy je tento certifikát kotvou důvěry, resp. je uveden na důvěryhodném seznamu (a reprezentuje službu s kvalifikovaným statusem).

Logika je taková, že nastavení řádné doby platnosti certifikátu, na kterém jsou časová razítka založena, je určitým dopředným odborným odhadem toho, jak dlouho bude možné se spoléhat na kryptografické algoritmy, které časové razítko využívá. Tento odhad vzniká v době vydávání certifikátu, a vydavatel jej nastavuje podle toho, jak dlouho si troufne věřit tomu, že použité kryptografické algoritmy „určitě vydrží“.

Je to stejné, jako u certifikátů pro elektronické podpisy a pečeti pro koncové držitele. Jen s tím zásadním rozdílem, že v případě časových razítek jde o jeden certifikát, který má vydavatel (autorita časových razítek) pod svou plnou kontrolou, stejně jako jeho využití, resp. samotné vytváření časových razítek – ke kterému typicky dochází jen po určitou počáteční dobu, a nikoli po celou dobu řádné platnosti certifikátu. A tak může vydavatel časových razítek sám odhadnout, jako dlouho ještě bude možné se spoléhat na již vydaná časová razítka. I poté, co již skončila řádná doba platnosti příslušného certifikátu.

Technické standardy v tomto ohledu pracují s tzv. sunset-em, v doslovném překladu: západem slunce. To je okamžik, ke kterému by možnost spoléhat se na již vytvořená časová razítka měla skončit. Konkrétní implementaci takovéhoto „západu slunce“ nad časovými razítky jsme si vlastně již naznačili – příslušné službě vydávání časových razítek (reprezentované jejím certifikátem) je odebrán kvalifikovaný status (resp. je nově zařazena jako služba s odebraným kvalifikovaným statusem). Což jsme si ukazovali výše.

Praktický důsledek je ten, že podle standardů mohou být ověřena jako platná i taková časová razítka, která jsou založena na již expirovaném certifikátu, nad kterým ale „ještě nezapadlo slunce“ (nenastal u něj sunset).

Ukažme si znovu certifikát časového razítka, kterým je opatřen zde probíraný příklad podpisu z 29. 2. 2020: povšimněte si, že tento certifikát je kotvou důvěry (v Readeru je zobrazován jako jediný na certifikační cestě, viz zelený rámeček).

Takže třeba unijní služba DSS, která je referenční implementací technických standardů, stejně jako na ní postavené validátory, dokáží ověřit časová razítka jako platná až do „západu slunce“ jejich certifikátů.

V konkrétním případě podpisu z 29. 2. 2020 služba DSS ověří časové razítko jako stále platné, použije jej jako rozhodný okamžik pro ověření samotného podpisu (v její terminologii Best Signature Time), a ten jí díky tomu vyjde jako platný.

Problém celého přístupu se „zapadáním slunce“ je v tom, že dopředu nelze úplně odhadnout, kdy k němu dojde. Což je nepříjemné pro udržování digitální kontinuity, cestou přidávání dalších časových razítek. Proto se zde jde „na jistotu“ a nejzazší okamžik pro přidání dalšího časového razítka se řídí řádnou dobou platnosti certifikátu dosud posledního časového razítka, a nikoli „západem slunce“.

Pro úplnost si ještě upřesněme, že program Adobe Reader jde vlastní cestou, pokud jde o časová razítka. Neumí je řetězit, neboli brát později přidané časové razítko jako důkaz existence předchozího časového razítka. Místo toho každé časové razítko ověřuje vždy samostatně, bez ohledu na jiná časová razítka, a to k aktuálnímu času. Přitom mu lze nastavit dvě varianty toho, jak postupuje: buďto důvěřuje certifikátu časového razítka jen po dobu jeho platnosti, nebo neomezeně dlouho. Defaultní je druhá možnost, odpovídající představě, že „slunce nikdy nezapadá“.

• Chcete mít Lupu bez bannerů?
• Chcete dostávat speciální týdenní newsletter o zákulisí českého internetu?
• Chcete mít k dispozici strojové přepisy podcastů?
• Chcete získat slevu 1 000 Kč na jednu z našich konferencí?

Staňte se naším podporovatelem

Chci se stát podporovatelem