Řízení životního cyklu certifikátu ISO 15118 v roce 2026: Od naléhavosti TLS k souladu s CRA

TL;DR (Shrnutí výkonných opatření)

• TLS cutover je pevná hranice (nejedná se o návrh): Z 24. února 2026, DigiCert bude přestat přijímat Žádosti o veřejné certifikáty TLS s platností více než 199 dnía certifikáty vydané od tohoto data mají Maximální platnost 199 dníPro mnoho operátorů je to praktický přechod – rychlost obnovy se okamžitě zvýší.
• Plán 200→100→47 dní je již definován: Základní požadavky CA/Browser Forum stanovují postupné snižování: 200 dní od 15. března 2026, 100 dní od 15. března 2027a 47 dní od 15. března 2029.
• CRA přidává časový limit pro sledování souladu: Pravidla pro podávání zpráv ratingových agentur vyžadují včasné varování do 24 hodin, úplné oznámení do 72 hodina definovala konečná okna pro podávání zpráv o aktivně zneužitých zranitelnostech a závažných incidentech.
• Největším skrytým rizikem není vypršení platnosti: Systémový režim selhání je posun kotvy důvěry—změny kořenových/meziprovozních/křížového podepisování nejsou synchronizované napříč EVSE, lokálními řadiči a ověřovacími cestami backendu.
• První investice pro zajištění provozuschopnosti: Systémově řízená automatizace (ACME + inventarizace + postupné zavádění) plus kontinuita hran (lokální validace/ukládání do mezipaměti, protokoly důkazů a správa synchronizace času).

Úvod: Rok 2026 promění systém Plug & Charge v operační systém

V roce 2026 přestane být funkce Plug & Charge (P&C) funkcí typu „nastav a zapomeň“ a stane se nepřetržitý operační systém.
Rovina důvěryhodnosti ISO 15118 (PKI + TLS + zrušení + aktualizace) se nyní řídí časovými harmonogramy, které netolerují manuální pracovní postupy.

Abychom pochopili hranice systému – za co je zodpovědná norma ISO 15118 vs. za co je zodpovědný OCPP – začněme s naším doprovodným textem:
Realita nasazení ISO 15118 vs. OCPP v roce 2026.

Bezprostřední tlak je Komprese životního cyklu TLSZ provozního hlediska nemůžete „čekat do března“.
DigiCert bude přestat přijímat veřejné požadavky TLS překračující 199 dní začíná 24. února 2026,
a certifikáty vydané od tohoto dne budou mít Maximální platnost 199 dní.
DigiCert také zdůrazňuje kritický provozní detail: maximální povolená platnost se řídí datum vydání, nikoli při zadání objednávky.

Zároveň zákon EU o kybernetické odolnosti (CRA) zavádí druhé časové omezení: pravidla pro hlášení vyžadují
24hodinové včasné varování a 72hodinové oznámení pro aktivně zneužívané zranitelnosti a závažné incidenty s dopadem na produkty s digitálními prvky.

Tato příručka se zaměřuje na architekturu a kontroly rizik pro provozování certifikátů ISO 15118 za těchto omezení.

Milníky a požadovaná opatření pro období 2024–2026 (textový Ganttův diagram)

Provozní poznámka: 24. února 2026 je často skutečným bodem přelomu, protože se tehdy mění chování hlavních certifikačních autorit při emisích.

Poznámka k zásadám: Postupné zkracování životnosti je definováno v základních požadavcích (200/100/47 dní).

Životní cyklus: Zajišťování → Provoz → Obnovení → Zrušení

Mapa životního cyklu (co musíte být schopni ovládat)

1. Zajišťování OEM: Vygenerované/vložené klíče; navázán kořen důvěryhodnosti (HSM/zabezpečený prvek).
2. Registrace ke smlouvě: Smluvní certifikáty vázané na uživatelské smlouvy (závislé na ekosystému).
3. Uvedení do provozu EVSE: Stanovení základních linií úložiště důvěryhodných dat, zásad a základních linií synchronizace času.
4. Provozní validace: TLS handshakes, budování řetězce, kontrola odvolání, vynucování zásad.
5. Obnovení / opětovné vydání: Automatizace + postupné zavádění + vrácení zpět.
6. Reakce na zrušení / incident: Kompromitace/nesprávné vydání/zneužití → zrušit/střídat/získat zpět.
7. Zotavení a usmíření: Obnovte službu při zachování auditovatelnosti a integrity fakturace.

Podceňovaný bod selhání: Posun kotvy důvěry

Většina „záhadných selhání P&C“ v prostředích s více OEM nespočívá v jediném prošlém certifikátu – jsou…
selhání ověření cesty způsobené posunem kotvy důvěry:

• Objevují se nové kořeny/meziprodukty (mnohokořenová realita).
• Křížové podepisování změny mění proveditelné řetězce.
• Úložiště důvěryhodných dat backendu se aktualizují rychleji než EVSE/lokální řadiče.
• Artefakty zrušení na okraji zastarají.

Aktualizace důvěryhodných kotev považujte za proces změn kritický z hlediska bezpečnosti:

• Úložiště důvěryhodných informací s verzí
• Zavádění na Kanárských ostrovech
• Plány pro vrácení zpět
• Telemetrie selhání ověření podle vydavatele/sériového čísla/cesty
• Explicitní vlastník pro „kdo, co a kdy aktualizuje“

Selhání při křížovém podepisování a budování vlastních cest (realita roku 2026): V ekosystémech s více kořeny dle ISO 15118,
Funkce Plug & Charge často selhává ne proto, že by certifikát byl neplatný, ale proto, že EVSE nedokáže vytvořit platný certifikát.
cesta k certifikátu po změnách křížového podepisování (nové meziprodukty, přemosťující certifikační autority, znovu vydané řetězce).
S připojováním dalších výrobců OEM a domén PKI se zvyšuje složitost cesty. Pokud se úložiště důvěryhodných dat na okraji sítě (EVSE/lokální řadiče)
zpožďují se za aktualizacemi backendu, handshakey TLS mohou selhat, i když se backendové certifikáty samy o sobě jeví jako „platné“.

Obrázek 1 (Doporučený vizuál): Ověření cesty v systému Multi-Root ISO 15118

(Zobrazit kořenový server V2G / kořenový server OEM / kořenový server smlouvy, mezilehlé produkty a mosty křížového podepsání.)
Zvýrazněte místo, kde nově podepsaný mezilehlý prvek přeruší budování cesty na EVSE, pokud úložiště důvěryhodných dat nejsou aktualizována synchronizovaně.

Hlavní sdělení: Většina výpadků P&C, za které se připisuje „PKI“, je ve skutečnosti selhání ověření cesty poháněno posunem křížového podepisování a nesynchronizovanými úložišti důvěryhodnosti.

ACME a automatizace: Řízení člověkem vs. řízení systémem při životnosti 199/200 dní

Proč se manuální obnova stává deterministickým generátorem výpadků

Krátké životnosti vyžadují neustálé obnovování. Přechod DigiCertu na 199 dní od 24. února 2026
Díky tomu je toto okamžitě funkční pro mnoho vozových parků. A širší časový harmonogram pro dané odvětví je již definován:
200 dní (od 15. března 2026), poté 100 dní, pak 47 dní.

Pro jakoukoli flotilu se události obnovy škálují takto:

Počet obnov za rok ≈ N × (365 / L)

Kde N je počet koncových bodů TLS a L je doba životnosti certifikátu (dny).
Jako L snižuje se, obnova řízená člověkem se stává matematicky neslučitelnou s cíli provozuschopnosti.

Scénář (velikost na úrovni představenstva)

Pro provozování CPO 5 000 koncových bodů, 199denní životnost znamená:

Počet obnov/rok ≈ 5000 × (365 / 199) ≈ 9 171

V tomto měřítku, dokonce i Míra lidských chyb 1% v překladu zhruba
92 výpadků způsobených certifikáty ročně—před započítáním dopadu dopravní špičky,
Penalizace SLA nebo kaskádování selhání napříč uzlem.

ACME v nabíjecích sítích: co by mělo automatizovat

ACME (Automated Certificate Management Environment) proměňuje obnovování v operace řízené zásadami pro:

• EVSE ↔ backendový TLS
• Lokální řadič / Edge Proxy TLS
• Brány lokality a řídicí jednotky uzlů

Systémem řízený pracovní postup (architektonický vzor)

1. Inventář každý koncový bod (vydavatel, sériové číslo, řetězec, expirace, poslední rotace).
2. Zásady pro obnovení předem (obnovit při stanoveném limitu, nikoli „téměř vyprší platnost“).
3. Hardwarově zálohované klíče pokud je to proveditelné, vyhněte se exportu soukromých klíčů.
4. Postupné zavádění s kontrolami stavu (handshake + autorizace + zahájení relace).
5. Automatické vrácení zpět na zvýšené míře selhání.
6. Záznamy důkazů pro každé vydání/nasazení (sledovatelnost na úrovni shody).

Řízeno člověkem vs. řízeno systémem

• Vedené člověkem: Tikety, tabulky, pozdní obnovení, nejednoznačné vlastnictví, riskantní nouzové změny.
• Systémově řízené: Deterministické zásady, automatizované vydávání, řízené zavádění, průběžná telemetrie, auditovatelné důkazy.

Kontroly zrušení: „zabiják P&C“ (CRL vs. OCSP, slabé sítě a obhajitelné zásady)

Proč OCSP/CRL selhávají v garážích a depech

• Slabé/přerušované LTE/5G
• Omezený odchod (firewally/captive portály)
• Kroky validace citlivé na latenci
• Externí závislosti (odpovídače OCSP, distribuční body CRL)

Výsledek: EVSE může zahájit relaci, ale nepodaří se ji dokončit. ověření zrušení spolehlivě.

CRL vs. OCSP: praktické kompromisy

• CRL: větší stahování, ale uložitelné do mezipaměti a obnovovatelné podle plánu (dobré pro kontinuitu na okraji serveru).
• OCSP: lehké na požadavek, ale často vyžaduje živou dosažitelnost na nejslabší straně.

V roce 2026 je správné držení těla vrstvené:

• Plánované ukládání do mezipaměti CRL pro zajištění odolnosti
• OCSP, kde je připojení spolehlivé
• Explicitní zásady pro zhoršené podmínky

Proč je „měkké selhání“ stále těžší obhájit

Historicky, „soft-fail“ (povolení relace, pokud vypršel časový limit kontroly odvolání) zachoval dostupnost.
V roce 2026 se stává soft-fail obtížnějším ospravedlnit, protože:

• Životnost je kratší (menší tolerance k zastaralým předpokladům)
• Hlášení incidentů ze strany CRA vyžaduje přísnější disciplínu a důkazní systém

Obhajitelný design vyžaduje explicitní a zdokumentovanou politiku:

• Těžké selhání pro veřejné/vysoce rizikové prostředí
• Milost s důkazy pro uzavřené vozové parky (omezené okno + kompenzační kontroly)
• Protokolování důkazů za každé špatné rozhodnutí

Architektonická zmírnění (vzory, nikoli produktové sliby)

Vzor 1: Předběžné ověření okraje + ukládání do mezipaměti

• Seznamy CRL v mezipaměti s definovanými časovými intervaly aktuálnosti
• Meziprodukty mezipaměti a validované řetězce
• Předběžné načítání během období „dobré konektivity“

Vzor 2: Sešívání OCSP (kde je to proveditelné)

Sešívání OCSP přesouvá doručování důkazů o odvolání od nejslabšího okraje, čímž se snižuje závislost na infrastruktuře CA během navazování relace.

Poznámka k implementaci (embedded reality): V prostředích EVSE ověřte podporu rozšíření souvisejících se sešíváním
ve vašem integrovaném TLS stacku a konfiguraci sestavení (např. mbedTLS, wolfSSL) a ověřovat chování napříč starším hardwarem,
protože se liší úplnost funkcí a omezení paměti/RTOS.

Vzor 3: Správa důvěryhodnosti s více kořeny

• Kanál aktualizací jednotného úložiště důvěryhodných certifikátů pro více kotev OEM
• Aktualizace Canary + vrácení zpět při prudkém nárůstu chyb při budování cesty

Vzor 4: Řízení synchronizace času (nevyjednávatelné)

• Zásady NTP (nebo PTP, kde je to vhodné)
• Monitorování driftu a prahové hodnoty výstrah
• Definované chování, když hodiny nejsou důvěryhodné

Kontinuita offline: zachování použitelnosti funkce Plug & Charge i během odpojení od edge-to-cloud sítě

Co je (a co není) offline kontinuita

Offline kontinuita není „obejití PKI“. Je to řízená degradace, která zachovává:

• Integrita klíčů a úložišť důvěryhodných informací
• Auditabilita pro fakturaci a reakci na incidenty
• Explicitní omezení toho, co lze lokálně validovat (a jak dlouho)

Lokální řadiče / Edge proxy jako primitiva dostupnosti

• Udržujte lokální mezipaměti důvěryhodnosti (kotvy/mezilehlé položky/seznamy CRL)
• Vynucení omezených lokálních autorizačních zásad
• Měření/protokoly vyrovnávací paměti pro pozdější odsouhlasení
• Snižte poloměr šíření sítě WAN tím, že budete fungovat jako lokální koncový bod pro EVSE

Obrázek 2 (doporučený vizuál): Edge Proxy jako mezipaměť důvěryhodnosti v lokalitách se slabou sítí

(Zobrazit EVSE připojující se k místnímu Edge Proxy/lokálnímu řadiči. Proxy udržuje uložené v mezipaměti důvěryhodné kotvy/zprostředkovatele,)
plánovaná aktualizace CRL, monitorování synchronizace času a protokoly důkazů; ukládá události do vyrovnávací paměti cloudového CSMS/PKI, když je uplink nestabilní.)

Hlavní sdělení: Proxy servery Edge snižují závislost na externích koncových bodech OCSP/CRL a umožňují řízenou offline kontinuitu bez obcházení PKI.

CRA a VMP: od termínů pro podávání zpráv v září 2026 k auditovatelnému provoznímu modelu

Pravidla pro podávání zpráv ratingových agentur: návrh na 24hodinový/72hodinový formát

Pravidla pro podávání zpráv ratingových agentur vyžadují, aby výrobci oznamovali aktivně zneužívané zranitelnosti a závažné incidenty, které mají dopad
o bezpečnosti produktů s digitálními prvky:

• Včasné varování do 24 hodin uvědomění si
• Úplné oznámení do 72 hodin
• Závěrečná zpráva v rámci definovaných oken (v závislosti na třídě incidentu)

Rozsáhlé narušení služby Plug & Charge způsobené hromadným zrušením nebo narušením důvěryhodnosti může se kvalifikovat
jako závažný incident v závislosti na dopadu a důkazech o zneužití.

Proces řízení zranitelností (VMP): minimální životaschopné schopnosti

1. Pravda o flotile: inventář aktiv + verzí (firmware EVSE, obrazy řadičů, verze úložiště důvěryhodných dat).
2. Integrace SBOM (dynamická): SBOM mapovaný na nasaditelné artefakty; průběžná korelace s informacemi o zranitelnostech.
3. Řízení expozice řízené VEX: Udržujte příkazy VEX pro rozlišení „přítomné, ale ne zneužitelné“ od „zneužitelné v našem nasazení“, což umožňuje důvěryhodné stanovení rozsahu v rámci časového okna T+24h.
4. Proč je VEX důležitý v 24hodinovém formátu: SBOM vám řekne, co je přítomno; VEX vám pomůže určit, co je zneužitelný, čímž se snižuje počet falešných poplachů a brání se provozním týmům v pronásledování nezneužitelného šumu.
5. Příjem a třídění: doporučení dodavatelů, CVE, interní zjištění; upřednostňovat zneužitelnost + expozici.
6. Pracovní postup pro stanovení rozsahu T+24h: Korelace SBOM + VEX + inventáře pro identifikaci postižených populací; počáteční rozhodnutí o omezení šíření; sběr důkazů.
7. Pracovní postup oznámení T+72h: potvrzený rozsah, zmírňující opatření, plán zavádění/vrácení, komunikační záznam.
8. Pracovní postup závěrečné zprávy: validační důkazy + hlavní příčina + prevence, vylepšení po dostupnosti nápravných opatření.
9. Inženýrství kadence patchů: postupné zavádění, plány vrácení zpět, podepsané artefakty, ověřovací brány.
10. Vymáhání řetězce důvěry: Bezpečné spuštění + bezpečné aktualizace firmwaru; podpisové klíče chráněné v HSM/bezpečnostních prvcích.
11. Protokolování založené na důkazech: události certifikátů, změny úložiště důvěryhodných certifikátů, selhání odvolání, stav synchronizace času.

Scénář důvěryhodnosti s vysokou závažností: Pokud je zrušení spuštěno kompromitovaným kořenovým nebo vydávajícím klíčem,
považovat to za incident důvěryhodnosti s nejvyšší závažností vyžadující okamžité omezení, opatření týkající se úložiště důvěryhodnosti v celém vozovém parku,
a připravenost na podávání zpráv v souladu s ratingovými agenturami v závislosti na důkazech o dopadu a využití.

Kontrolní seznam pro odpočítávání reakce na incidenty CRA (operační šablona)

T+0 (Detekce / Povědomí)

• Zmrazení důkazů: protokoly, události certifikátů, verze úložiště důvěryhodných certifikátů, stav synchronizace času
• Identifikace postižených povrchů: firmware EVSE, lokální řadiče, koncové body TLS backendu
• Zapojte poskytovatele PKI / kontaktní osobu pro zabezpečení backendu

T+24h (Včasná výstražná připravenost)

• Hlavní cíl: Použití SBOM + VEX + inventář vozového parku určit postiženou populaci a podat včasné varování podložené důkazy
• Rozhodnutí o omezení: zrušení/rotace, vrácení zpět do úložiště důvěryhodných dat, izolace webu
• Návrh balíčku včasného varování: rozsah, probíhající zmírňující opatření, prozatímní stav

T+72h (Plná připravenost k oznámení)

• Potvrďte postižené populace podle regionu/místa; uveďte plán sanace + metodu jejího zavádění
• Vytváření záznamů o komunikaci se zákazníkem/operátorem a eskalaci

Okno závěrečné zprávy

• Předložení závěrečné zprávy v souladu s požadavky CRA (načasování závisí na třídě incidentu)
• Důkazy o validaci po opravě a získané poznatky

Kvantifikace nákladů a rizik (šablony, které můžete začlenit do svého vozového parku)

Model nákladů na práci při manuálním obnovení

Nechat:

• N = počet koncových bodů TLS (EVSE + řadiče + brány + spravované backendové uzly)
• L = doba trvání certifikátu (dny)
• t = lidský čas na obnovu (hodiny)
• C = náklady na práci při plném zatížení (USD/hod.)

Náklady na práci ≈ N × (365 / L) × t × c

Model rizika výpadku (vypršení platnosti nebo neúspěšné nasazení)

Nechat:

• P_miss = pravděpodobnost zmeškané/neúspěšné obnovy za cyklus
• H_dolů = očekávaná doba prostojů v hodinách na incident
• C_hodina = hodinový dopad na podnikání (ztráta příjmů, sankce, kredity SLA)

Náklady na výpadek ≈ P_miss × H_down × C_hour

Průvodce rozhodováním: Když online kontroly odvolání selžou (časový limit OCSP/CRL)

1. Veřejné místo nebo uzavřený vozový park/depo?
   • Veřejné → preferovat Těžké selhání (nebo přísně kontrolovaná milost pouze s důkazy + kompenzační kontroly)
   • Vozový park/depo → Milost s důkazy může být přijatelné pro omezená okna
2. Je spolehlivost sítě předvídatelná?
   • Ano → Online OCSP/CRL + monitorování
   • Ne → Předběžné ověření na okraji + ukládání do mezipaměti (Okna pro obnovení CRL, řetězce uložené v mezipaměti)
3. Můžete snížit závislost na internetu během sezení?
   • Kde je to proveditelné → přijmout Vzor sešívání OCSP (zatlačte důkaz blíže k okraji)
4. Máte zavedení záznamů + správu synchronizace času?
   • Pokud ne → nejdříve opravte tyto; zásady pro degradovaný režim je bez nich těžké obhájit.

Matice praktické odpovědnosti (hranice, které zabraňují výpadkům)

Glosář

• PKI: Infrastruktura veřejných klíčů (vydávání, validace, důvěryhodné kotvy, zrušení)
• VRCHOL: Automatizované prostředí pro správu certifikátů (automatizované vydávání/obnovování)
• OCSP / CRL: Protokol o stavu online certifikátů / Seznam zneplatněných certifikátů
• Sešívání OCSP: Server poskytuje důkaz o odvolání, aby se snížila závislost na aktivním OCSP.
• Důvěryhodné kotvy: Kořenové/zprostředkující certifikáty, kterým vaši validátoři důvěřují
• SBOM: Kusovník softwaru (inventář komponent pro určení rozsahu zranitelností)
• VEX: Výměna informací o zneužitelné zranitelnosti (prohlášení o stavu zneužitelné zranitelnosti)
• TLS 1.3: Moderní TLS profil; handshake + ověření certifikátu zůstává citlivé na latenci.
• VMP: Proces řízení zranitelností (příjem, třídění, opravy, hlášení, důkazy)

Riziko zaměřené na budoucnost: Agilita kryptoměn a připravenost na PQC

Zatímco rok 2026 se bude vyznačovat krátkou životností TLS a reportingem CRA, nabíjecí infrastruktury by měly začít s hodnocením
krypto-agilitaU zařízení s dlouhou životností (vozidla a nabíječky) by se architektury měly vyhnout hardwarové závislosti tím, že zajistí…
Prvky HSM/zabezpečení a vestavěné zásobníky mohou podporovat budoucí aktualizace algoritmů a profilů certifikátů bez nutnosti aktualizace hardwaru.

Často kladené otázky

Může Plug & Charge fungovat offline?

Částečně – záměrně. Offline P&C je řízená degradace pomocí lokálního ukládání důvěryhodných dat do mezipaměti (kotvy/mezilehlé položky/seznamy CRL, kde je to proveditelné).
explicitní zásady pro odsouhlasení a uložené protokoly auditu pro účely odsouhlasení. Nemělo by se obcházet PKI; mělo by se snížit závislost na živém cloudu.
při zachování integrity a auditovatelnosti.

Jak často musíme obnovovat certifikáty s platností 199/200 dní?

Naplánujte si několik cyklů obnovy ročně pro každý koncový bod. Pro mnoho provozovatelů začíná provozní přechod
24. února 2026 protože DigiCert bude vydávat veřejné TLS certifikáty s maximální 199 dní platnost od tohoto data.
Na širší úrovni ekosystému definují základní požadavky postupné snižování 200/100/47 dní.

Co spouští povinnost ratingových agentur podávat zprávy?

Pravidla pro podávání zpráv ratingových agentur vyžadují 24hodinové včasné varování a 72hodinové oznámení pro aktivně zneužívané zranitelnosti a závažné incidenty,
plus konečné časové rámce pro podávání zpráv. Rozsáhlé narušení důvěryhodnosti P&C (např. škodlivé zrušení nebo kompromitace ověření) se může kvalifikovat v závislosti na
na základě důkazů o dopadu a využití; plán pro hodnocení rizik připravený na CRA by měl podporovat SBOM + VEX + inventář vozového parku vymezení rozsahu během prvních 24 hodin.