непідтримуване призначення сертифіката: чому проміжний CA не проходить

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

Який сертифікат перевіряльник справді відхилив

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

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

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

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

Призначення кінцевого сертифіката та політика ланцюжка — дві перевірки

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

Тому щойно виданий кінцевий сертифікат, правильний у всіх видимих полях, може одразу не пройти. Тому виправлення зазвичай належить до профілю центру випуску, а не до конфігурації VPN.

Відсутній EKU — не обмежувальний EKU

RFC 5280 робить розширення розширеного використання ключа необов'язковим і, коли воно є, обмежувальним. Тому сертифікат CA без розширення не сказав «ні» автентифікації сервера, тоді як той, що перелічує лише стороннє призначення, сказав дещо вельми конкретне. Ставлення до цих двох станів як до рівнозначних дає неправильний діагноз і, що гірше, неправильне виправлення. Різниця також пояснює, чому два центри, схожі в консолі, поводяться зовсім по-різному в ланцюжку.

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

Відтворіть збій офлайн, перш ніж перевипускати

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

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

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

Виправляйте політику випуску, а не виклик перевірки

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

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