OCSP проти CRL: як насправді працює кожна перевірка відкликання

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

Крок 1: Що повертає кожна перевірка і як довго вона залишається придатною

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

Тому кешування — перше, що треба зафіксувати: який компонент тримає копію і якій стелі ця копія підкоряється. На шлюзі стелею має бути nextUpdate мінус запас безпеки, а не те, що випадково запропонує заголовок кешу HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate друкує обидві дати, і список, у якого nextUpdate вже в минулому, слід вважати відсутнім, а не просто старим.

Крок 2: Куди сертифікат спрямовує клієнта

Кінцевий сертифікат зазвичай несе дві підказки: розширення точки розповсюдження CRL і запис доступу до інформації засвідчувального центру для OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints друкує першу, а друга міститься в розділі AIA виводу openssl x509 -in client.pem -noout -text. Будь-яке з розширень — це вказівник, а не обов'язок. Клієнт, який ніколи не реалізує перевірку відкликання, цілком успішно з'єднається із сертифікатом, розширення якого називають відповідач, що вже рік як мертвий.

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

Крок 3: Виберіть fail-closed або fail-open до збою

Недоступний відповідач або прострочений список змушують до рішення: відмовити у з'єднанні або прийняти його й зафіксувати прогалину. Підкоманда verify у OpenSSL робить суворий вибір явним, бо додавання -crl_check перетворює недоступну CRL на unable to get certificate CRL і невдалу перевірку. М'який збій у більшості стеків зовсім не прапорець, а відсутність перевірки, і саме тому він потрапляє у випуск випадково.

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

Крок 4: Доведіть, що перевірка виконується там, де приймається трафік

Знайдіть процес, який завершує або авторизує з'єднання, і спитайте в нього рядок конфігурації, що вмикає перевірку відкликання. Шлюз, який перевіряє ланцюжок, але ніколи не питає про відкликання, застосовує іншу політику, ніж та, що у вашій документації, і жоден знімок екрана ланцюжка сертифікатів не доводить протилежного. OpenVPN записує цю опцію як crl-verify; strongSwan тримає пошук CRL і OCSP у конфігурації CA, де задаються crl_uris або ocsp_uris. Якщо ви не можете вказати на жодне з них, вважайте, що перевірки немає.

Відповідь OCSP дійсна лише тоді, коли її підписав видавець CA, або коли її підписав відповідач, який має розширене використання ключа OCSPSigning, делеговане цим CA, тому відповідь сторонньої служби нічого не доводить. Якщо ви самі експлуатуєте відповідач, стежте за ним як за жорсткою залежністю, бо одна мертва служба одразу стає збоєм для кожного клієнта fail-closed.

Крок 5: Відкличте один сертифікат навмисно

Візьміть тестовий сертифікат, відкличте його тим самим каналом, який використовує виробництво, і запитайте відповідач напряму. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text має повідомити Cert Status: revoked разом із часом відкликання, а відповідь good означає, що ваше відкликання не дійшло до відповідача, який запитують ваші клієнти. Потім запустіть openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem, щоб побачити те саме рішення шляхом списку. Читайте рядок причини, а не код виходу, бо відмова через відкликання і помилка ланцюжка однаково закінчуються невдачею.

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