Застаріння кореневого сертифіката AddTrust призвело до збоїв у системах із OpenSSL та GnuTLS

30 травня минув 20-річний термін дії кореневого сертифіката AddTrust, Який застосовувався для формування перехресного підпису (cross-signed) у сертифікатах одного з найбільших центрів Sectigo (Comodo). Перехресний підпис дозволяв забезпечити сумісність із застарілими пристроями, до сховища кореневих сертифікатів яких не було додано новий кореневий сертифікат USERTRust.

Теоретично припинення дії кореневого сертифіката AddTrust мало призвести лише до порушення сумісності зі застарілими системами (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 тощо), оскільки другий кореневий сертифікат, який використовується в перехресному підписі, залишається сучасні браузери враховують його під час перевірки ланцюжка довіри. На практиці виявились проблеми з перевіркою перехресного підпису в TLS-клієнтах, що не використовують браузери, у тому числі на базі OpenSSL 1.0.x і GnuTLS. Безпечне з'єднання перестало встановлюватися з виведенням помилки про старіння сертифіката, якщо на сервері використовується сертифікат Sectigo, пов'язаний ланцюжком довіри з кореневим сертифікатом AddTrust.

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

Наприклад, виникли проблеми з доступом до деяких репозиторій пакетів у Debian та Ubuntu (apt став видавати помилку перевірки сертифіката), стали завершуватися збоєм звернення зі скриптів за допомогою утиліт «curl» та «wget», спостерігаються помилки при використанні Git, порушилася робота платформи потокового мовлення Roku, перестали викликатися обробники Смуга и DataDog, почали виникати крахи у додатках Heroku, перестали підключатися клієнти OpenLDAP, фіксуються проблеми з надсиланням пошти на сервери SMTPS та SMTP із STARTTLS. Крім того, спостерігаються проблеми в різних Ruby-, PHP- і Python-скриптах, що використовують модуль з http-клієнтом. З браузерів проблема торкається Epiphany, у якому перестали завантажуватись списки блокування реклами.

Програми на мові Go проблемі не схильні, оскільки Go пропонується власна реалізація TLS.

Передбачалося, що проблема стосується старих випусків дистрибутивів (включаючи Debian 9, Ubuntu 16.04, RHEL 6/7) у яких використовуються проблемні гілки OpenSSL, але проблема виявилася також при роботі пакетного менеджера APT в актуальних випусках Debian 10 та Ubuntu 18.04/20.04, оскільки APT використовує бібліотеку GnuTLS. Суть проблеми в тому, що багато TLS/SSL-бібліотеків розбирають сертифікат як лінійний ланцюжок, у той час як відповідно до RFC 4158 сертифікат може представляти орієнтований розподілений циклічний граф з кількома якорями довіри, які потрібно враховувати. Про дану недоробку в OpenSSL та GnuTLS було відомо вже багато років. В OpenSSL проблема була усунена у гілці 1.1.1, а в gnuTLS залишається невиправленою.

Як обхідний шлях усунення збою пропонується видалити із системного сховища сертифікат «AddTrust External CA Root» (наприклад, видалити з /etc/ca-certificates.conf та /etc/ssl/certs, а потім запустити «update-ca-certificates -f -v»), після чого OpenSSL починає нормально обробляти перехресно підписані сертифікати за його участю. У разі використання пакетного менеджера APT на свій страх і ризик можна відключити для окремих запитів перевірку сертифікатів (наприклад, apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false).

Для блокування проблеми в Fedora и RHEL пропонується додати сертифікат AddTrust до чорного списку:

trust dump —filter «pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract

Але цей спосіб не працює для GnuTLS (наприклад, продовжується помилка перевірки сертифіката під час запуску утиліти wget).

На стороні сервера можна змінити порядок перерахування сертифікатів у ланцюжку довіри, що надсилаються сервером до клієнта (якщо пов'язаний з AddTrust External CA Root сертифікат буде прибраний зі списку, то перевірка клієнтом пройде успішно). Для перевірки та генерації нового ланцюжка довіри можна використовувати сервіс whatsmychaincert.com. Компанія Sectigo також надала альтернативний перехресно підписаний проміжний сертифікатСертифікаційні послуги AAA«, який діятиме до 2028 року та дозволить зберегти сумісність зі старими версіями ОС.

Додаток: Проблема також проявляється у LibreSSL.

Джерело: opennet.ru