Листовий сертифікат чинний, ланцюг прострочено: читайте глибину

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

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

Глибина називає сертифікат, який не пройшов

У діагностиці OpenSSL глибина 0 — це цільовий сертифікат, а глибина 1 — видавець, який його підписав; більші числа продовжуються до якоря довіри. Закінчення строку, про яке повідомлено на глибині 1, не спростовується чинним notAfter на листі, тому повторна перевірка видимого сертифіката ніколи не пояснить помилку.

Запишіть відбиток невдалого сертифіката разом з його subject, бо різні сертифікати можуть мати однакове ім'я CA. Перехресне підписування створює саме таку ситуацію: той самий орган з'являється більше ніж один раз, з різними датами чинності, і перевіряльник вибрав той, якого ви не чекали. Знайома мітка — не ідентифікатор, а відбиток — це те, що відрізняє два об'єкти з однаковим ім'ям.

Зверніть увагу й на продукти з більш ніж однією роллю сертифіката. У OpenVPN Access Server сертифікати, що захищають веб-інтерфейси, відокремлені від тих, що використовуються для VPN-з'єднань, тож браузер, який відкриває сторінку адміністратора, нічого не доводить про шлях тунелю.

Вхідні дані довіри — не те саме, що кандидати ланцюга

Дайте перевіряльнику два входи окремо й явно. Файл довіри містить якорі, які ви приймаєте; недовірений пакет містить проміжні сертифікати, запропоновані для побудови шляху. Змішувати їх — це спосіб, у який люди випадково підносять проміжний сертифікат до кореня, а потім дивуються, чому та сама помилка переслідує їх між машинами.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Вимкнення стандартного шляху й сховища за допомогою -no-CApath -no-CAstore зберігає тест чесним: результат тоді залежить від названих вами файлів, а не від того, чому робоча станція випадково довіряє. Довідка з перевірки OpenSSL документує ці параметри та діагностику, яку вони створюють.

-show_chain друкує побудований ланцюг, коли перевірка успішна, що корисно для підтвердження того, що шлях — саме задуманий. Коли вона не вдається, збережіть повідомлені глибину й subject; ці два поля підкажуть наступному читачеві, який сертифікат перевіряти.

Чого це не робить — не відтворює політику кожного клієнта. Pin, обмеження призначення або перевірка ідентичності, специфічна для клієнта, живе в клієнті, а не в цій команді. Саме ці налаштування треба перевіряти, коли на сервері перевірка проходить, а з'єднання все одно не встановлюється. Тримайте два діагнози окремо, інакше ви оновите здоровий сертифікат, ганяючись за помилкою pinning.

Що доводить перевірка і що залишає поза увагою

Це перевірка шляху й призначення щодо файлу довіри, який ви надали. Для перевірки імені HTTPS додайте очікуване ім'я хоста через відповідний параметр; для VPN-з'єднання збережіть налаштовані перевірки ідентичності клієнта й використовуйте той матеріал довіри, який цей клієнт справді читає.

Те, що надсилає сервер, — це набір кандидатів, а не шлях, який зрештою побудує ваш клієнт. Локальна довіра й правила побудови бібліотеки разом формують результат, тому та сама відповідь може пройти перевірку на одній машині й не пройти на іншій. Порівняйте підтримуване сховище довіри й реалізацію TLS невдалого клієнта з такими в робочого, перш ніж припускати ідентичну оцінку. Різниця там пояснює багато повідомлень «не працює лише на цьому ноутбуці».

Щоб побачити вікно кожного сертифіката, а не по одному, виведіть їх як набір:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Друга команда перелічує subject і видавців, не декодуючи кожен файл вручну, так ви помічаєте проміжний сертифікат, чия дата вже минула, поки лист ще виглядає добре.

Виправте шлях, не послаблюючи перевірку

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

Поводження з коренем варте примітки, бо підсумки часто його перебільшують. RFC 5280 розглядає якір як вхід, що стоїть поза передбачуваним шляхом, тоді як OpenSSL документує перевірки чинності, які включають його кореневий сертифікат CA. Обидва твердження слушні для їхніх систем; узагальнення поведінки закінчення строку кореня однієї бібліотеки на кожного клієнта дає впевнені неправильні відповіді.

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

Схожі статті