Видалення EKU clientAuth з сертифікатів відкладено до 1 березня 2027р

Гарні новини для тих, кому потрібні сертифікати, що підтримують автентифікацію клієнтів: DigiCert продовжує дату припинення підтримки розширеного використання ключа (EKU) для автентифікації клієнтів (clientAuth) у наших публічних сертифікатах SSL/TLS.

Видалення EKU clientAuth з сертифікатів відкладено до 1 березня 2027 року (раніше це було 1 травня 2026 року).

Це оновлення відповідає нещодавно оновленій кореневій політиці Google Chrome, яка передбачила цю зміну для покращення безпеки та відповідності.

Якщо ви покладаєтеся на автентифікацію клієнтів, у вас є 12 місяців на перехід, перш ніж цю можливість буде видалено з публічного TLS.

Нижче наведено два рішення DigiCert, які можуть задовольнити потреби ваших клієнтів в автентифікації після 1 березня 2027 року.

Примітка: Ця зміна впливає на всі публічні сертифікати TLS DigiCert: DV, OV, EV, EU Qualified Website Authentication Certificate (QWAC) та EU QWAC PSD2, а також на всі бренди DigiCert: DigiCert ®, GeoTrust ®, Thawte ®, RapidSSL ® та Encryption Everywhere ®.

Рішення для автентифікації клієнтів після 1 березня 2027 року

DigiCert пропонує два основні рішення для наших клієнтів та партнерів, яким потрібен EKU для автентифікації клієнтів після 1 березня 2027 року:

• PKI X9 від DigiCert для сертифікатів TLS – захищає зв’язок, що включає кілька організацій (mTLS, VPN-доступ тощо).
• Приватна PKI як послуга – захищає бізнес-операції, які є суто внутрішніми.

SSL-сертифікати Trustwave мають бути замінені до 27 лютого 2026 року

Компанія Trustwave (що працює під брендом VikingCloud) оголосила про припинення випуску публічних SSL/TLS сертифікатів.

• Дедлайн: Усі чинні сертифікати Trustwave відкликаються сьогодні, 27 лютого 2026 року.

• Наслідки: Будь-який вебсайт або сервіс, що все ще використовує сертифікат від Trustwave після сьогоднішнього дня, буде видавати помилку «Підключення не захищене» або «Сертифікат не є довіреним» у браузерах користувачів.

Удосконалення перевірки домену з різних джерел

Починаючи з 24 лютого 2026 року, DigiCert оновить MPIC (Multi-Perspective Issuance Corroboration), щоб забезпечити підтвердження з використанням щонайменше трьох віддалених мережевих розташувань з щонайменше двох різних регіонів регіонального реєстру Інтернету, відповідно до наступного етапу вимог MPIC CA/Browser Forum.

Підтвердження означає, що кілька мережевих точок зору повинні повертати однакові дані запису DNS або вміст файлу веб-сайту для певного домену, перш ніж домен можна буде вважати перевіреним і перш ніж можна буде видавати сертифікат. Вимоги MPIC застосовуються як до перевірки перевірки контролю домену (DCV), так і до перевірок авторизації центру сертифікації (CAA).

У березні 2025 року DigiCert почав перевіряти дані про керування доменами та записи CAA з кількох мережевих розташувань відповідно до вимог CA Browser Forum, перед майбутніми етапами багатоперспективного підтвердження видачі (MPIC).

У вересні 2025 року DigiCert удосконалив свій процес перевірки та видачі сертифікатів, впровадивши наступний етап MPIC та забезпечивши підтвердження з використанням щонайменше двох віддалених мережевих розташувань.

24 лютого 2026 року DigiCert додасть ще один агент користувача та дві нові IP-адреси до IP-адрес агентів MPIC.

Перевірка DNSSEC для верифікації домену

24 лютого 2026 року DigiCert почне перевіряти розширення безпеки системи доменних імен (DNSSEC), якщо вони є, під час перевірки контролю домену та перевірок авторизації центру сертифікації DNS (CAA). Ця зміна впливає на всі продукти, які потребують перевірки домену та/або перевірок CAA перед видачею сертифіката.

! Якщо у вас не включена функция DNSSEC для ваших доменов - тоді вимога щодо перевірки DNSSEC на вас не поширюватиметься. Однак, для впевненості, ми рекомендуємо перевірити чи не ввімкнено DNSSEC для ваших доменів у вашій організації.

Використання DNSSEC НЕ ОБОВ'ЯЗКОВЕ. Вам не потрібно налаштовувати DNSSEC для видачі DigiCert одного з перелічених вище сертифікатів. Ця інформація стосується лише тих, хто використовує або планує використовувати DNSSEC.

Що таке DNSSEC? DNSSEC (Domain Name System Security Extensions) — це набір специфікацій для захисту інформації в системі доменних імен (DNS). Якщо просто: це "цифровий підпис" для інтернет-адрес, який гарантує, що ви потрапили саме на той сайт, який запитували, а не на підробку.

DNSSEC: Перевірка та захист вашого DNS

Одним із найкращих методів захисту вашого домену на рівні DNS є використання розширень безпеки DNS (DNSSEC). Коротко кажучи, DNSSEC – це протокол, призначений для захисту веб-сайтів від атак шляхом забезпечення безпеки DNS-запитів. Це робиться за допомогою ієрархічної політики цифрового підпису або ланцюжка довіри на всіх рівнях DNS. Якщо DNSSEC увімкнено, кожен рівень процесу пошуку має бути перевірений та підписаний, перш ніж запит можна буде вирішити.

DNSSEC особливо корисний для запобігання поширеним атакам, пов’язаним із DNS, таким як захоплення DNS, отруєння та тунелювання, оскільки він вимагає перевірки для кожної частини процесу пошуку.

Важливе оновлення: Термін дії сертифікатів скорочується

Від 24 лютого 2026 року, сертифікати TLS/SSL, видані через DigiCert матимуть максимальний термін дії 199 днів (замість нинішніх 397 днів). Це стосується також кваліфікованих сертифікатів автентифікації вебсайтів ЄС (QWAC) та сертифікатів QWAC PSD2.

Cертифікати підпису коду  DigiCert Code Signing , матимуть максимальний термін дії 459 днів (раніше це було 39 місяців)

Перехід на коротші терміни дії є загальногалузевою вимогою, встановленою новими базовими стандартами CA/Browser Forum. Хоча це може вимагати певних коригувань у вашій роботі, такі заходи знижують ризики та допомагають підтримувати стійкість вашої інфраструктури.

До 24 лютого 2026 року ви можете продовжувати замовляти сертифікати TLS/SSL із терміном дії понад 199 днів, Code Signing понад 459 днів.

Будь-які сертифікати, видані 24 лютого або пізніше (включаючи запити, створені до цієї дати, але ще не оброблені), будуть обмежені терміном у 199 днів (459 днів для Code Signing), навіть якщо в замовленні вказано довший період.

Якщо вам потрібні сертифікати з довшим терміном дії, рекомендуємо оформити замовлення заздалегідь до 24 лютого 2026 року та переконатися, що валідація домену та організації актуальна.

Існуючі сертифікати не підпадають під дію нових правил. Сертифікати, видані до 24 лютого, залишатимуться дійсними до початкової дати закінчення терміну дії.

Однак, якщо існуючий сертифікат буде перевипущений 24 лютого або пізніше, його термін дії буде обмежений 199 днями (459 днів для Code Signing) .

Вплив на валідацію організації та домену:

З 24 лютого термін повторного використання даних для валідації організації (OV) скоротиться з 825 до 397 днів. 
З 24 лютого термін повторного використання даних для валідації домену скоротиться з 397 до 199 днів.

Client Authentication в SSL сертифікатах

Починаючи з 1 жовтня 2025 року, щойно видані сертифікати SSL/TLS більше не містять функцію автентифікації клієнта( Client Authentication).
Якщо ви використовуєте свої сертифікати SSL/TLS лише для безпеки веб-сайту (HTTPS), вам не потрібно вживати жодних дій. Якщо ви використовуєте сертифікати для взаємної автентифікації, яку також називають mTLS або автентифікацією між серверами, це може вплинути на вас.
Ми рекомендуємо перевірити ваші поточні налаштування.
Якщо ви використовуєте сертифікати для взаємної автентифікації, вам потрібно буде перейти на інший тип, зазвичай виданий приватним центром сертифікації (Private CA).
ВАЖЛИВІ ДАТИ
1 жовтня 2025 року – Автентифікацію клієнта видалено з нових, поновлених або перевиданих сертифікатів SSL/TLS.
15 травня 2026 року – Автентифікація клієнта більше не підтримуватиметься в жодних щойно виданих сертифікатах SSL/TLS.

Digicert пропонує 2 варіанти рішення

X9 PKI для сертифікатів TLS

Перехід на X9 PKI DigiCert для сертифікатів TLS для захисту зв'язку, що включає кілька організацій. Регульований органом стандартизації ASC X9, X9 PKI керується незалежною політикою сертифікатів, незалежною від браузерів, але яка забезпечує сумісність завдяки використанню спільного кореня довіри. X9 PKI для сертифікатів TLS може мати EKU автентифікації як клієнта, так і сервера, що задовольняє сучасні унікальні потреби в контролі, безпеці, гнучкості та масштабованості з можливостями шифрування, ідентифікації та перехресної сертифікації.

Private trust Приватна довіра

Перехід на PKI як послугу для бізнес-потреб, які є суто внутрішніми. DigiCert може налаштувати та керувати приватною PKI для вашої організації, використовуючи наш операційний досвід та інвестиції в безпеку.

Зміна стандартів електронної пошти

Стандарти сертифікатів електронної пошти оновлено для підтримки автоматизації ACME та майбутньої безпеки PQC Зміни до базових вимог до сертифіката S/MIME додають підтримку автоматичної перевірки поштових скриньок (через протокол ACME) та тестування алгоритмів постквантової криптографії SMC012: Впровадження ACME для S/MIME було офіційно прийнято як частину Базових вимог S/MIME 2 липня. Цей бюлетень надає центрам сертифікації (CA) стандартизований та автоматизований спосіб реагування на запити на перевірку керування поштовою скринькою за допомогою протоколу ACME. Це пропонує ще один зручний для автоматизації метод для CA для перевірки адрес поштових скриньок. SMC013: Увімкнення алгоритмів PQC для S/MIME вступило в 30-денний період розгляду, який мав завершитися 20 серпня. Цей бюлетень має на меті додати використання двох алгоритмів постквантової криптографії (PQC) до Базових вимог S/MIME. Ці сертифікати призначені для тестування (CA та клієнтами) і не будуть загальнодоступними. Однак цей крок знаменує собою ще один крок на шляху, який зрештою призводить до впровадження та використання PQC у публічних мережах.

Оновлення щодо Client Authentication EKU-та Server Authentication EKU

DigiCert припинить включати EKU для автентифікації клієнта до публічних сертифікатів TLS.

Починаючи з 1 жовтня 2025 року, DigiCert за замовчуванням припинить включати використання розширеного ключа (EKU) автентифікації клієнта (Client Authentication EKU) до публічних сертифікатів TLS.

Ці сертифікати будуть видаватися лише з EKU автентифікації сервера (Server Authentication EKU).

Ця зміна відповідає вимогам кореневої програми Google Chrome щодо підвищення безпеки та сприяння сумісності. Щоб отримати докладнішу інформацію про терміни DigiCert щодо поступового виведення з експлуатації EKU автентифікації клієнта в наших публічних сертифікатах TLS.

Починаючи з 1 травня 2026 року, DigiCert більше не видаватиме публічні сертифікати TLS з використанням розширеного ключа (EKU) для автентифікації клієнта. Відповідно до вимог root-програми Google Chrome, DigiCert видаватиме всі публічні сертифікати TLS з використанням EKU для автентифікації сервера.

Якщо ви використовуєте сертифікати TLS/SSL виключно для захисту веб-сайтів (HTTPS), тоді жодних дій не потрібно. Однак DigiCert рекомендує переглянути процес сертифікації TLS, щоб переконатися, що він включає лише захист веб-сайтів.

Якщо ви використовуєте публічні сертифікати TLS для автентифікації клієнтів на сервері таких як користувачі або пристрої  або автентифікації між серверами, потрібні вжити заходів. Ви все ще можете включати EKU автентифікації клієнта (Client Authentication EKU) до своїх сертифікатів до 1 травня 2026 року.

Digicert пропонує такі рішення як X9 PKI для сертифікатів TLS і Private trust (PKI послуга для бізнес-потреб)

Оновлення щодо IPv4 та HTTP/1.0

Нагадуємо, що 8 вересня 2025 року DigiCert вніс важливі зміни в інфраструктуру, які можуть вплинути на вас або ваших клієнтів, якщо:

1. Ви використовуєте білі списки (allowlists) 
або
2. Ваші інтеграції OCSP та CRL використовують застарілий протокол HTTP/1.0.

1. DigiCert додав нові виділені IPv4-адреси 
DigiCert додав вторинну мережу доставки контенту (CDN) з додатковими виділеними IPv4-адресами для певних служб DigiCert.

Якщо ваша компанія використовує білі списки для контролю вихідного трафіку вам слід отримати нові IPv4-адреси та оновити свої білі списки. В іншому випадку, після розгортання нової CDN з 8 вересня, у вас можуть виникнути перебої в роботі сервісу. 
Якщо ви не використовуєте білі списки для контролю вихідного трафіку, подальші дії не потрібні.

2. DigiCert припиняє підтримку HTTP/1.0-з’єднань для перевірки статусу сертифікатів OCSP та CRL
8 вересня DigiCert припинив підтримку HTTP/1.0 для відповідності сучасним інтернет-стандартам та оптимізації продуктивності.
Якщо у вас або ваших клієнтів є інтеграція для перевірки статусу сертифікатів OCSP та CRL, вам потрібно переконатися, що інтеграція використовує HTTP/1.1 або пізнішу версію, щоб уникнути потенційних перебоїв у робочому процесі.

Зміни в галузі щодо сертифікатів S/MIME: Припинення дії профілю Legacy

10 липня 2025 року DigiCert припинив приймати запити на сертифікат Secure Email з використанням профілю сертифіката Legacy.
Усі нові запити на сертифікати повинні використовувати профіль сертифіката Strict або Multipurpose. Ця зміна впливає на нові, поновлені та перевидані запити на сертифікати.

Сертифікати електронной пошти тепер поділяються на:

• Secure Email for Individual
• Secure Email for Business

Кожен з них може бути представлений у двох опціях -  Strict (за замовчуванням)  та Multipurpose (обирається)

Strict  -Secure Email
Максимальний термін дії  825 днів
Включає ім'я та прізвище (або псевдонім) як subject в сертифікаті 
Сфера викорристання:

-Цифровий підпис (Digital Signature)
-Шифрування ключів  (Key Encipherment)
-Беззаперечність (Non-Repudiation) -Дозволяє вам стверджувати, хто підписав електронний лист/документ, тим, хто перевіряє підпис, вказуючи на те, що закритий ключ має достатній захист, який особа, зазначена в сертифікаті, не може пізніше спростувати.

Multipurpose- Secure Email:
Автентифікація клієнта (Client Authentication)– автентифікація клієнта дозволяє використовувати сертифікат як цифровий ідентифікатор (Digital ID) для автентифікації на сервері або віддаленому комп’ютері.
Максимальний термін дії  825 днів
Включає ім'я та прізвище (або псевдонім) як subject в сертифікаті 
Сфера викорристання:
-Цифровий підпис (Digital Signature)
-Шифрування ключів (Key Encipherment)
-Беззаперечність (Non-Repudiation)
-Шифрування даних (Data Encipherment ) шифрування даних дозволяє використовувати сертифікат для підписання документів).

Підтримувані алгоритми та довжини ключів для сертифікатів Secure Email

Довжини ключів -2048, 3072 та 4096 
RSA (Рівест-Шамір-Адлеман), ECC (криптографія еліптичної кривої)