Підбір сертификату |
Client Authentication в SSL сертифікатахПочинаючи з 1 жовтня 2025 року, щойно видані сертифікати SSL/TLS більше не містять функцію автентифікації клієнта( Client Authentication). 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 EKUDigiCert припинить включати 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) 1. DigiCert додав нові виділені IPv4-адреси Якщо ваша компанія використовує білі списки для контролю вихідного трафіку вам слід отримати нові IPv4-адреси та оновити свої білі списки. В іншому випадку, після розгортання нової CDN з 8 вересня, у вас можуть виникнути перебої в роботі сервісу. 2. DigiCert припиняє підтримку HTTP/1.0-з’єднань для перевірки статусу сертифікатів OCSP та CRL
Зміни в галузі щодо сертифікатів S/MIME: Припинення дії профілю Legacy10 липня 2025 року DigiCert припинив приймати запити на сертифікат Secure Email з використанням профілю сертифіката Legacy. Сертифікати електронной пошти тепер поділяються на:
Кожен з них може бути представлений у двох опціях - Strict (за замовчуванням) та Multipurpose (обирається) Strict -Secure Email -Цифровий підпис (Digital Signature) Multipurpose- Secure Email: Підтримувані алгоритми та довжини ключів для сертифікатів Secure Email Довжини ключів -2048, 3072 та 4096
Зміни терміну дії сертифікатівТри основні зміни в нових правилах TLS від CA/B Forum почнуть діяти з березня 2026 року: 1 Максимальний термін дії публічного TLS-сертифіката зменшиться з 398 днів до 47 днів. 2 Максимальний період, протягом якого інформація про перевірку домену може бути повторно використана, зменшиться з 398 днів до 10 днів. 3. Максимальний період, протягом якого інформація про ідентифікацію суб'єкта (SII, ідентифікаційні дані про сутність, якій видано сертифікат) може бути повторно використана, зменшиться з 825 днів до 398 днів.
Максимальний термін дії публічного TLS-сертифіката зменшуватиметься протягом наступних кількох років: До 15 березня 2026 року максимальний термін дії SSL сертифіката становить 398 днів. З 15 березня 2026 року максимальний термін дії SSL сертифіката становитиме 200 днів. З 15 березня 2027 року максимальний термін дії SSL сертифіката становитиме 100 днів. З 15 березня 2029 року максимальний термін дії SSL сертифіката становитиме 47 днів. Google скасовує довіру до всіх Entrust сертифікатів SSLУ Google прійняте рішення скасувати довіру до всіх Entrust публічних сертифікатів SSL у веб-переглядачі Chrome після 31 жовтня 2024 року. Протягом останніх кількох місяців у Entrust виникла низка невідповідних вимог, що призвело до надзвичайно запізнілих відкликань і численних іноді гарячих онлайн-діалогів щодо цих помилок. У результаті цих і попередніх інцидентів Google Chrome оголосив, що не довіряє публічним кореням Entrust після 31 жовтня 2024 року. У блозі безпеки Google зазначено: «Протягом останніх шести років ми спостерігали збій у відповідності, недотримання зобов’язань щодо вдосконалення та відсутність відчутного, вимірюваного прогресу у відповідь на публічно оприлюднені звіти про інциденти... довіра Chrome до Entrust більше не виправдовується». Компанії з загальнодоступними сертифікатами SSL Entrust повинні будуть замінити їх, інакше їхні веб-сайти будуть позначені як ненадійні в Chrome. Раніше про недовіру до центру сертифікації Entrust заявила Mozilla Digicert Code Signing - проблема підпису в застарілих ОСПроблема Нещодавня зміна в ієрархії довіри для підпису коду DigiCert призвела до того, що деякі застарілі операційні системи не довіряли правильно підписаному коду та відображали попередження. Помилка перевірки підпису автентикоду з новою перехресною міткою часу У червні 2022 року DigiCert представив новий перехресний корінь «DigiCert Trusted Root G4» для вирішення проблем сумісності із застарілими клієнтами з міткою часу. Запровадження перехресного кореня полягало в тому, що сертифікат часової позначки зв’язувався з більш поширеним коренем, який уже був присутній у кореневих сховищах застарілих систем. У рамках цієї зміни новий крос-корінь включав лише атрибут EKU Time Stamping (1.3.6.1.5.5.7.3.8). Оскільки цей перехресний корінь також використовуватиметься як частина ланцюжка цифрового підпису, Windows не зможе перевірити ланцюжок сертифіката підпису коду через обмежений EKU. Під час перевірки даних цифрового підпису на застарілих платформах можуть з’явитися помилки, подібні до наведених нижче: "Сертифікат недійсний для запитаного використання" "Здається, цей сертифікат недійсний для вибраної мети" ------------- Рішення Щоб вирішити цю проблему, DigiCert опублікував новий тимчасовий міжкореневий центр сертифікації. Для використання цього нового ЦС потрібно змінити процес підписання. Це тимчасовий обхідний шлях для вирішення цієї проблеми, створено ще один крос-корінь спеціально для використання з цифровим підписом. Він містить правильний код підпису (1.3.6.1.5.5.7.3.3) EKU для проходження перевірки підпису Windows.
Ви можете завантажити його тут: digicert-g4-to-haevrca-codesigningcrosscert.crt
CodeSigning Cross Root Serial: 0fd1bbca796bd7f8dd4c82e10a9a9631 Valid From: Jan 13 00:00:00 2022 GMT Valid To: Nov 9 23:59:59 2031 GMT Новий ICA «DigiCert Trusted Root G4» був перехресно підписаний «DigiCert High Assurance EV Root CA» лише з кодовим підписом EKU.
Timestamping Cross Root Serial: 01240afb1e380b8a16f14b719df4d3c0 Valid From: Jun 9 00:00:00 2022 GMT Valid To: Nov 9 23:59:59 2031 GMT Новий ICA «DigiCert Trusted Root G4» був створений і перехресно підписаний «DigiCert Assured ID Root CA» лише з міткою часу EKU.
Підписання коду з новим перехресним підписом проміжного ICA повинно вирішити проблему. Якщо для підпису коду використовується Signtool, передайте параметр /ac у команді підпису: signtool sign /ac DigiCert-G4-to-HAEVRCA-CodeSigningCrossCert.crt /tr http://timestamp.digicert.com /td sha256 /fd sha256 /a "c:\path\to\file_to_sign.exe" Переконайтеся, що файл було правильно підписано за допомогою цієї команди: signtool verify /pa signed_file.exe
Джерело: https://knowledge.digicert.com/solution/authenticode-signature-verification-fails-with-new-timestamping-cross-root.html?om_ext_cid=dc_email_7014z000001p3BtAAI_10783&mth=July%2C%202022 Certum блокує РФПольський Certum CA призупинили продаж наших послуг і продуктів під брендом до Російської Федерації та Республіки Білорусь - це рішення також стосується діяльності з продажу, яку здійснюють партнери Certum, які видавали сертифікати СЦ клієнтам у цих країнах.
Certum призупинили видачу нових сертифікатів SSL/TLS для доменів .RU і .BY, а також для компаній, зареєстрованих в Російській Федерації або Республіці Білорусь.
Certum CA призупинили видачу інших кваліфікованих і некваліфікованих сертифікатів для компаній, організацій і громадян з Російської Федерації та Республіки Білорусь.
У зв’язку з динамічною ситуацією та можливістю нових економічних санкцій з боку Європейського Союзу, також враховується сценарії, коли всі сертифікати, видані на даний момент для вищеописаних випадків, можуть бути відкликані та доступ до послуг Certum буде обмежено та заблоковано.
Слава Україні! Дякуємо Certum!
Digicert блокує РФЗ 10 березня 2022 року о 20:00 год. MST (11 березня, 3:00 ранку UTC) DigiCert призупинив видачу та перевипуск усіх типів сертифікатів, пов’язаних із Росією та Білоруссю. Це включає призупинення видачі та переоформлення сертифікатів для доменів верхнього рівня, пов’язаних з Росією та Білорусією, зокрема .ru, .su, .by, .рф та інших, а також організаціям з адресами в Росії чи Білорусі. Крім того, DigiCert наразі не приймає платежі в рублях.
Слава Україні! Дякуємо Digicert!
https://knowledge.digicert.com/solution/Embargoed-Countries-and-Regions.html
Еще статьи...
Страница 1 из 5
|