Відкликання сертифікатів не працює: який хост і куди не може дістатися

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

За шлях завантаження відповідає перевіряльник

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

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

Прочитайте точку публікації із сертифіката

Сертифікат зазначає, де розташований його стан. Читайте ці поля, а не вгадуйте адресу CA.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

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

Перевірте завантаження з пристрою, який виконує перевірку

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

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

Запуск certutil перевіряє ланцюжок і повідомляє, які завантаження URL вдалися чи не вдалися, а виклик curl перевіряє одну адресу публікації з того самого хоста й повертає лише код стану. Невдале завантаження з доступної адреси вказує на проблеми з вмістом або підписом; помилка підключення вказує на маршрутизацію, DNS або проксі. Збережіть обидва результати, бо одне вдале завантаження не доводить, що весь ланцюжок придатний. Замініть приклад хоста й шляху на точку розповсюдження, знайдену в сертифікаті.

Відокремте відсутні дані від відкликаного стану

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

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