Управление на жизнения цикъл на сертификата ISO 15118 през 2026 г.: От спешност на TLS до съответствие с CRA

TL;DR (Резюме на изпълнителните действия)

• Прекъсването на TLS е твърда граница (не е предложение): От 24 февруари 2026 г., DigiCert ще спрете да приемате заявки за публични TLS сертификати с валидност повече от 199 днии сертификатите, издадени от тази дата, имат Максимална валидност 199 дниТова е практическият преход за много оператори – скоростта на подновяване се увеличава незабавно.
• Пътната карта 200→100→47 дни вече е дефинирана: Базовите изисквания на CA/Browser Forum определят поетапно намаляване: 200 дни от 15 март 2026 г., 100 дни от 15 март 2027 г.и 47 дни от 15 март 2029 г..
• CRA добавя часовник за съответствие: Правилата за отчитане на CRA изискват ранно предупреждение в рамките на 24 часа, пълно уведомление в рамките на 72 часаи дефинирани окончателни прозорци за отчитане за активно използвани уязвимости и сериозни инциденти.
• Най-големият скрит риск не е изтичането на срока на годност: Режимът на системна повреда е дрейф на котвата на доверието—промените в корените/междинните компоненти/кръстосаното подписване не са синхронизирани между EVSE, локалните контролери и пътищата за валидиране на backend-а.
• Първа инвестиция за осигуряване на работоспособност: Системно ръководена автоматизация (ACME + инвентаризация + поетапно внедряване) плюс непрекъснатост на ръба (локално валидиране/кеширане, регистрационни файлове с доказателства и управление на синхронизацията на времето).

Въведение: 2026 г. превръща Plug & Charge в оперативна система

През 2026 г. Plug & Charge (P&C) престава да бъде функция „настрой и забрави“ и се превръща в непрекъсната операционна система.
Доверителната равнина на ISO 15118 (PKI + TLS + отмяна + актуализации) вече се управлява от срокове, които не толерират ръчни работни потоци.

За да разберете границите на системата – за какво е отговорен ISO 15118 спрямо за какво е отговорен OCPP – започнете с нашата съпътстваща статия:
ISO 15118 срещу реалността на внедряването на OCPP през 2026 г..

Непосредственият натиск е Компресия на жизнения цикъл на TLSОт оперативна гледна точка, не можете да „чакате до март“.
DigiCert ще спрете да приемате публични TLS заявки, превишаващи 199 дни започване 24 февруари 2026 г.,
и сертификатите, издадени от тази дата нататък, ще имат Максимална валидност 199 дни.
DigiCert също така подчертава критичен оперативен детайл: максимално допустимата валидност се определя от дата на издаване, а не когато е направена поръчката.

Същевременно Законът на ЕС за киберустойчивост (CRA) въвежда втори часовник: правилата за докладване изискват
24-часово ранно предупреждение и 72-часово известие за активно използвани уязвимости и сериозни инциденти, засягащи продукти с цифрови елементи.

Това ръководство се фокусира върху архитектурата и контрола на риска за работа със сертификати по ISO 15118 при тези ограничения.

Етапи и необходими действия за периода 2024–2026 г. (текст на Гант)

Оперативна бележка: 24 февруари 2026 г. често е истинската преходна точка, защото тогава поведението на емитиране се променя за основните CA.

Бележка към политиката: Поетапните намаления на жизнения цикъл са определени в Базовите изисквания (200/100/47 дни).

Ландшафт на жизнения цикъл: Осигуряване → Експлоатация → Подновяване → Анулиране

Карта на жизнения цикъл (какво трябва да можете да управлявате)

1. OEM осигуряване: Генерирани/инжектирани ключове; установен корен на доверие (HSM/сигурен елемент).
2. Записване по договор: Сертификати за договори, обвързани с потребителски договори (зависими от екосистемата).
3. Въвеждане в експлоатация на EVSE: Установени са базови линии, политики и базови линии за синхронизиране на времето за доверени хранилища.
4. Оперативно валидиране: TLS ръкостискания, изграждане на верига, проверка за отмяна, прилагане на политики.
5. Подновяване / преиздаване: Автоматизация + поетапно внедряване + връщане към предишна версия.
6. Реакция на анулиране / инцидент: Компрометиране/неправилно издаване/експлоатация → отмяна/ротация/възстановяване.
7. Възстановяване и помирение: Възстановете услугата, като същевременно запазите възможността за одит и целостта на фактурирането.

Подценената точка на провал: Дрейф на котвата на доверието

Повечето „мистериозни повреди на P&C“ в среди с множество OEM производители не са един-единствен изтекъл сертификат – те са
неуспехи при валидиране на пътя причинено от отклонение на котвата на доверието:

• Появяват се нови корени/междинни звена (многокоренова реалност).
• Кръстосано подписване промените променят възможните вериги.
• Доверителните хранилища на бекенда се актуализират по-бързо от EVSE/локалните контролери.
• Артефактите за отмяна остаряват в края.

Третирайте актуализациите на доверените котви като процес на промяна, критичен за безопасността:

• Версионирани хранилища за доверени данни
• Разгръщане на Canary
• Планове за връщане към предишните модели
• Телеметрия за неуспешни валидации по издател/сериен номер/път
• Изричен собственик за „кой какво актуализира, кога“

Провали при кръстосаното подписване и изграждането на път (реалност на 2026 г.): В екосистеми с множество корени по ISO 15118,
„Plug & Charge“ често се проваля не защото сертификатът е невалиден, а защото EVSE не може да изгради валиден...
път на сертификата след промени в кръстосаното подписване (нови междинни продукти, мостови сертификати, преиздадени вериги).
С присъединяването на повече производители на оригинално оборудване (OEM) и PKI домейни, сложността на пътя се увеличава. Ако граничните хранилища за доверие (EVSE/локални контролери)
изостават от актуализациите на backend-а, TLS handshake-овете могат да се провалят, дори когато backend сертификатите изглеждат „валидни“ сами по себе си.

Фигура 1 (Препоръчително визуализиране): Валидиране на пътя в Multi-Root ISO 15118

(Показване на V2G Root / OEM Root / Contract Root, междинни продукти и мостове с кръстосани знаци.)
Маркирайте къде новоподписан междинен елемент прекъсва изграждането на път в EVSE, ако хранилищата с доверени данни не се актуализират синхронизирано.)

Основно послание: Повечето прекъсвания на P&C, за които се приписва „PKI“, всъщност са неуспехи при валидиране на пътя задвижвано от дрейф на кръстосаното подписване и несинхронизирани хранилища за доверие.

ACME и автоматизация: Водени от човека срещу водени от системата при жизнен цикъл от 199/200 дни

Защо ръчното подновяване се превръща в детерминистичен генератор на прекъсвания

Краткият живот прави подновяванията непрекъснати. Преместването на DigiCert към 199 дни от 24 февруари 2026 г.
прави това оперативно незабавно за много автопаркове. А по-широката времева рамка за индустрията вече е определена:
200 дни (от 15 март 2026 г.), след това 100 дни, тогава 47 дни.

За всеки автопарк, събитията за обновяване се мащабират както следва:

Брой събития за подновяване годишно ≈ N × (365 / L)

Къде Н е броят на крайните точки на TLS и Л е срокът на валидност на сертификата (дни).
Като Л намалява, обновяването, водено от човек, става математически несъвместимо с целите за време на работа.

Сценарий (оразмеряване на ниво борд)

За работещ CPO 5000 крайни точки, 199-дневен живот означава:

Събития за подновяване/година ≈ 5000 × (365 / 199) ≈ 9 171

В този мащаб, дори и 1% процент на човешки грешки превежда се приблизително като
92 прекъсвания, причинени от сертификати, годишно—преди отчитане на въздействието на пиковите часове,
SLA санкции или каскадни повреди в хъб.

ACME в зарядните мрежи: какво трябва да автоматизира

ACME (Автоматизирана среда за управление на сертификати) превръща подновяванията в операции, управлявани от политики, за:

• EVSE ↔ TLS за бекенд
• Локален контролер / Edge Proxy TLS
• Шлюзове на сайта и контролери на хъбове

Системно ръководен работен процес (архитектурен модел)

1. Инвентар всяка крайна точка (издател, сериен номер, верига, срок на валидност, последна ротация).
2. Политика за подновяване преди (подновяване при фиксиран праг, а не „преди изтичане“).
3. Хардуерно подкрепени ключове където е възможно; избягвайте експортирането на частни ключове.
4. Поетапно внедряване с проверки на състоянието (ръкостискане + оторизация + стартиране на сесия).
5. Автоматично връщане назад при повишени нива на неуспех.
6. Дневници с доказателства за всяко издаване/внедряване (проследимост на ниво съответствие).

Водени от човека срещу водени от системата

• Водени от човека: Заяви, електронни таблици, закъснели подновявания, неясна собственост, рискови промени при извънредни ситуации.
• Системно ръководени: Детерминистични политики, автоматизирано издаване, контролирано внедряване, непрекъсната телеметрия, одитираеми доказателства.

Проверки за анулиране: „убиецът на P&C“ (CRL срещу OCSP, слаби мрежи и защитими политики)

Защо OCSP/CRL се провалят в гаражи и депа

• Слаб/периодичен LTE/5G
• Ограничен изход (защитни стени/портали за достъп)
• Стъпки за валидиране, чувствителни към латентност
• Външни зависимости (OCSP отговори, точки за разпространение на CRL)

Резултат: EVSE може да започне сесия, но не успява да я завърши валидиране на отмяната надеждно.

CRL срещу OCSP: практически компромиси

• CRL: по-големи изтегляния, но кешируеми и обновяеми по график (добре за непрекъснатост на периферията).
• OCSP: лек за заявка, но често изисква достъпност в реално време в най-слабия ръб.

През 2026 г. правилната стойка е на пластове:

• Планирано кеширане на CRL за устойчивост
• OCSP, където свързаността е надеждна
• Изрична политика за влошени условия

Защо „мекият провал“ става все по-труден за защита

В исторически план, „soft-fail“ (разрешаване на сесия, ако времето за изчакване на проверките за отмяна изтече) запазваше наличността.
През 2026 г. мекият провал става по-труден за оправдаване, защото:

• Животът е по-кратък (по-малка толерантност към остарели предположения)
• Срокът за докладване на CRA налага по-строга дисциплина при инциденти и проследяване на доказателства

Защитимият дизайн изисква изрична, документирана политика:

• Труднопровално за обществени/високорискови среди
• Благодат с доказателства за затворени автопаркове (ограничен прозорец + компенсиращи контроли)
• Регистриране на доказателства за всяко деградирало решение

Архитектурни смекчаващи мерки (модели, а не продуктови обещания)

Модел 1: Предварителна валидация на ръба + кеширане

• Кеширани CRL с дефинирани прозорци за свежест
• Междинни продукти на кеша и валидирани вериги
• Предварително извличане по време на периоди с „добра свързаност“

Модел 2: OCSP зашиване (където е възможно)

OCSP стаплингът измества доставката на доказателства за отмяна далеч от най-слабия ръб, намалявайки зависимостта от CA инфраструктурата по време на установяване на сесия.

Бележка за внедряване (вградена реалност): В среди за EVSE, потвърдете поддръжката на разширения, свързани с телбодиране
във вашия вграден TLS стек и конфигурация за изграждане (напр. mbedTLS, wolfSSL) и валидирайте поведението в наследен хардуер,
защото пълнотата на функциите и ограниченията на паметта/RTOS варират.

Модел 3: Управление на многокоренно доверие

• Унифициран канал за актуализиране на хранилище за доверие за множество OEM котви
• Актуализации на Canary + връщане към предишните настройки, когато грешките при изграждане на пътеки се повишат

Модел 4: Управление на синхронизацията на времето (не подлежи на договаряне)

• Политика за NTP (или PTP, където е уместно)
• Мониторинг на дрейфа и прагове за предупреждение
• Дефинирано поведение, когато часовниците са ненадеждни

Офлайн непрекъснатост: запазване на Plug & Charge използваем по време на прекъсвания на връзката между edge-to-cloud мрежата

Какво е (и не е) офлайн приемствеността

Офлайн непрекъснатостта не е „заобикаляне на PKI“. Това е контролирана деградация, която запазва:

• Цялостност на ключовете и хранилищата на доверени данни
• Одитируемост за фактуриране и реагиране при инциденти
• Изрични ограничения за това какво може да бъде валидирано локално (и за колко време)

Локални контролери / Edge прокси сървъри като примитиви за достъпност

• Поддържайте локални кешове за доверие (котви/междинни връзки/CRL)
• Прилагане на ограничени локални политики за оторизация
• Буферно измерване/регистрационни файлове за по-късно съгласуване
• Намалете радиуса на WAN взрив, като действате като локална крайна точка за EVSE

Фигура 2 (Препоръчителна визуализация): Edge Proxy като кеш за доверие в сайтове със слаба мрежа

(Показване на EVSE, свързващи се с локален Edge Proxy/Local Controller. Проксито поддържа кеширани доверителни котви/междинни звена,)
планирано обновяване на CRL, наблюдение на синхронизирането на времето и регистрационни файлове с доказателства; буферира събития в облачната CSMS/PKI, когато връзката нагоре е нестабилна.)

Основно послание: Крайните прокси сървъри намаляват зависимостта от външни крайни точки на OCSP/CRL и позволяват контролирана офлайн непрекъснатост, без да се заобикаля PKI.

CRA и VMP: от крайните срокове за отчитане през септември 2026 г. към одитиран оперативен модел

Правила за отчитане на CRA: проектиране към 24-часов/72-часов формат

Правилата за докладване на CRA изискват производителите да уведомяват за активно използвани уязвимости и сериозни инциденти, които имат въздействие
относно сигурността на продукти с цифрови елементи:

• Ранно предупреждение в рамките на 24 часа осъзнаване на
• Пълно уведомление в рамките на 72 часа
• Окончателен доклад в рамките на определени прозорци (в зависимост от класа на инцидента)

Мащабно прекъсване на Plug & Charge, причинено от масово отменяне или компрометиране на доверителния котвен елемент може да се класира
като сериозен инцидент в зависимост от въздействието и доказателствата за експлоатация.

Процес на управление на уязвимостите (VMP): минимални жизнеспособни възможности

1. Истината за флота: инвентаризация на активи + версии (фърмуер на EVSE, изображения на контролери, версии на хранилища за доверени данни).
2. SBOM интеграция (динамична): SBOM, съпоставен с разгръщащи се артефакти; непрекъсната корелация с информация за уязвимости.
3. Управление на експозицията, управлявано от VEX: Поддържайте VEX оператори, за да разграничите „налично, но не е експлоатираемо“ от „експлоатираемо в нашето внедряване“, което ще позволи надеждно определяне на обхвата в рамките на прозореца T+24h.
4. Защо VEX е важен в 24-часовия формат: SBOM ви казва какво е налично; VEX ви помага да определите какво е експлоатиран, намалявайки фалшивите аларми и предотвратявайки преследването на неизползваем шум от оперативните екипи.
5. Прием и триаж: съвети за доставчици, CVE, вътрешни констатации; приоритизиране на експлоатационността + експозицията.
6. Работен процес за определяне на обхвата T+24 часа: SBOM + VEX + корелация на инвентара за идентифициране на засегнатите популации; първоначални решения за ограничаване; събиране на доказателства.
7. Работен процес за уведомяване T+72h: потвърден обхват, смекчаващи мерки, план за внедряване/връщане назад, протокол от комуникациите.
8. Работен процес на окончателния отчет: доказателства за валидиране + първопричина + подобрения в превенцията след наличието на коригиращи мерки.
9. Инженеринг на пач каденца: поетапно внедряване, планове за връщане към предишни версии, подписани артефакти, портали за проверка.
10. Прилагане на веригата на доверие: сигурно зареждане + сигурни актуализации на фърмуера; ключове за подписване, защитени в HSM/сигурни елементи.
11. Дърводобив, основан на доказателства: събития на сертификати, промени в хранилището за доверени сертификати, неуспешни отмени, състояние на синхронизирането на времето.

Сценарий за доверие с висока степен на сериозност: Ако отмяната е задействана от компрометиран root или издаващ ключ,
третирайте го като инцидент с доверие с най-висока степен на сериозност, изискващ незабавно ограничаване, действия за съхранение на доверителни данни в целия автопарк,
и готовност за отчитане, съобразено с изискванията на CRA, в зависимост от доказателствата за въздействие и експлоатация.

Контролен списък за обратно броене за реагиране при инциденти на CRA (оперативен шаблон)

T+0 (Откриване / Осъзнаване)

• Замразяване на доказателства: лог файлове, събития на сертификати, версии на хранилища за доверени данни, състояние на синхронизиране на времето
• Идентифицирайте засегнатите повърхности: фърмуер на EVSE, локални контролери, крайни точки на TLS от backend системата
• Ангажирайте доставчика на PKI / контакт за сигурност на backend системата

T+24h (Готовност за ранно предупреждение)

• Основна цел: Използвайте SBOM + VEX + инвентаризация на автопарка да се определи засегнатото население и да се подаде ранно предупреждение, подкрепено с доказателства
• Решете ограничаване: отмяна/ротиране, връщане назад към доверено хранилище, изолиране на сайт
• Проект на пакет за ранно предупреждение: обхват, текущи смекчаващи мерки, междинна позиция

T+72h (Пълна готовност за уведомяване)

• Потвърдете засегнатите популации по регион/обект; предоставете план за отстраняване + метод за внедряване
• Създаване на протокол за комуникация с клиент/оператор и ескалация

Прозорец за окончателен отчет

• Подаване на окончателен доклад, съобразен с изискванията на CRA (срокът зависи от класа на инцидента)
• Доказателства за валидиране след корекция + извлечени поуки

Количествено определяне на разходите и риска (шаблони, които можете да включите във вашия автопарк)

Модел на разходите за труд при ръчно подновяване

Нека:

• Н = брой крайни точки на TLS (EVSE + контролери + шлюзове + управлявани backend възли)
• Л = срок на валидност на сертификата (дни)
• т = човешко време за подновяване (часове)
• в = цена на труда при пълно натоварване (USD/час)

Цена_труд ≈ N × (365 / L) × t × c

Модел на риск от прекъсване (изтичане или неуспешно внедряване)

Нека:

• P_miss = вероятност за пропуснато/неуспешно подновяване на цикъл
• H_down = очаквани часове престой на инцидент
• C_час = почасово въздействие върху бизнеса (загубени приходи, неустойки, кредити по SLA)

Разход_за_прекъсване ≈ P_пропуск × H_намаление × C_час

Ръководство за вземане на решения: Кога онлайн проверките за отмяна са неуспешни (OCSP/CRL Timeout)

1. Публичен обект или затворен автопарк/депо?
   • Публично → предпочитам Труднопровално (или строго контролирана благодат само с доказателства + компенсиращи контроли)
   • Автопарк/депо → Благодат с доказателства може да е приемливо за ограничени прозорци
2. Предсказуема ли е надеждността на мрежата?
   • Да → Онлайн OCSP/CRL + наблюдение
   • Не → Предварителна валидация на ръба + кеширане (Прозорци за обновяване на CRL, кеширани вериги)
3. Можете ли да намалите онлайн зависимостта по време на сесия?
   • Където е възможно → приемете OCSP шаблон за захващане с телбод (бутнете доказателството по-близо до ръба)
4. Имате ли регистриране на доказателства + управление на синхронизацията на времето?
   • Ако не → първо поправете тези; политиките за влошен режим са трудни за защита без тях

Матрица на практическата отговорност (граници, които предотвратяват прекъсвания)

Речник

• PKI: Инфраструктура на публични ключове (издаване, валидиране, доверителни котви, отмяна)
• АКМЕ: Автоматизирана среда за управление на сертификати (автоматизирано издаване/подновяване)
• OCSP / CRL: Протокол за състоянието на онлайн сертификатите / Списък с анулирани сертификати
• OCSP зашиване с телбод: Сървърът предоставя доказателство за отмяна, за да намали зависимостта от активен OCSP
• Доверителни котви: Коренни/междинни сертификати, на които вашите валидатори се доверяват
• СБОМ: Софтуерна спецификация на материалите (инвентаризация на компонентите за определяне на обхвата на уязвимостите)
• VEX: Обмен на експлоатационна уязвимост (декларации за състояние на експлоатационност)
• TLS 1.3: Съвременен TLS профил; handshake + валидирането на сертификат остават чувствителни към латентността
• ВМП: Процес на управление на уязвимостите (прием, триаж, корекции, докладване, доказателства)

Риск, насочен към бъдещето: крипто гъвкавост и готовност за PQC

Докато 2026 г. е доминирана от краткия живот на TLS и отчитането на CRA, зарядните инфраструктури трябва да започнат да оценяват
крипто-гъвкавостПри дълготрайните активи (превозни средства и зарядни устройства), архитектурите трябва да избягват хардуерна обвързаност, като гарантират
HSM/сигурните елементи и вградените стекове могат да поддържат бъдещи актуализации на алгоритми и профили на сертификати, без да е необходимо обновяване на хардуера.

ЧЗВ

Може ли Plug & Charge да работи офлайн?

Частично - по дизайн. Офлайн P&C е контролирана деградация чрез локално кеширане на доверие (котви/междинни връзки/CRL, където е възможно).
изрични правила за grace и буферирани регистрационни файлове за одит за съгласуване. Не трябва да се заобикаля PKI; трябва да се намали зависимостта от „активен облак“.
като същевременно се запазва целостта и одитируемостта.

Колко често трябва да подновяваме сертификати с валидност от 199/200 дни?

Планирайте няколко цикъла на подновяване годишно за всяка крайна точка. За много оператори оперативното превключване започва
24 февруари 2026 г. защото DigiCert ще издава публични TLS сертификати с максимум 199 дни валидност от тази дата.
На по-широко екосистемно ниво, базовите изисквания определят поетапно намаляване до 200/100/47 дни.

Какво задейства задълженията за докладване на кредитните рейтингови агенции (CRA)?

Правилата за отчитане на CRA изискват 24-часово ранно предупреждение и 72-часово известие за активно използвани уязвимости и сериозни инциденти,
плюс окончателни прозорци за отчитане. Мащабно нарушаване на доверието в P&C (напр. злонамерено отменяне или компрометиране на валидирането) може да се квалифицира в зависимост от
върху доказателства за въздействие и експлоатация; план за управление на риска, готов за анализ на кредитните рейтинги, трябва да поддържа SBOM + VEX + инвентаризация на автопарка обхват в рамките на първите 24 часа.