Pull to refresh

Comments 16

Как отмечалось выше, отозвать нормальным способом такой сертификат уже нельзя

Чем в этом случае поможет двухуровневая схема со сроком действия CRL в полгода-год?

Срок действия CRL неважен, он просто обновляется вручную по необходимости.

Но ведь он кэшируется на клиенте и до истечении срока действия отзыва не произойдёт.

Если есть OCSP, это не проблема, насколько я понимаю. Если нет… ну, надо завести. :)

Так OCSP не используется для офлайнового корневого ЦС.

Хорошо бы Вадим расписал чем плохо удаление сертификатов CA из AD при компрометации, потому что сейчас плюсы двухуровневой схемы неочевидны.

Почему? OCSP всё равно, с чьим CRL работать.

Оно не плохо, оно очень накладно. Это и значительный простой PKI между процессом изъятия их эксплуатации скомпрометированного ЦС и введением в работу нового. Придётся ещё выяснять как это случилось и принимать меры, чтобы это не повторилось. Второй момент заключается в том, что корневой сертификат часто установлен не только в домене, но и на множестве мобильных устройств, к которым немедленный доступ получить не так легко. И этот сертификат нужно удалять со всех устройств. В теории выглядит легко «ну мы сейчас на MDM всё сделаем за минуту». Из опыта скажу, что при попытке реализовать это в реальной жизни, сразу возникает множество проблем. Плюс, есть ещё корпоративная бюрократия добавляет хлопот.
Это не совсем так. Начиная с Windows Vista, при скачивании CRL по HTTP, клиент CryptoAPI руководствуется следующими заголовками HTTP: E-tag и Cache-Control. Так же, клиент использует функцию pre-fetch. Таким образом, клиент узнает об отзыве гораздо быстрее, в течении нескольких дней даже при 6-месячном CRL. Т.е. клиент периодически проверяет есть ли обновление у CRL на сервере (за счёт E-tag) без скачивания самого списка отзыва. Эти моменты подробно расписаны в этой статье: How Certificate Revocation Works.
Спасибо за пояснение.
Выходит, что первым в CDP Location должен быть HTTP, а не LDAP даже для окружения с преимущественно доменными компьютерами?
LDAP быть вообще не должно, только HTTP. Я во второй части (жду публикации) сделал сноску на статью в моём блоге, которая более подробно разъясняет принципы планирования ссылок CDP/AIA.
Нашел статью, жаль в ультимативной форме про это говорится только у вас в блоге и Брайаном Комаром на технетовских форумах.

А, например, в докладе от PKI Solutions автор называет LDAP в CDP допустимым вариантом для windows shops. Как и старая книжка про PKI, которую похоже не собираются обновлять.
С опытом мы пришли к этому. Что касается «windows shops», в нынешнем гетерогенном мире — это утопия. Достаточно заиметь телефон с андроидом или iOS и здрасьте-приехали, они про этот LDAP ничего не знают. Поэтому мы с Брайаном проповедуем максимальную совместимость с различными клиентскими платформами, а в текущем контексте эта совместимость обеспечивается только транспортом HTTP.

Что касается книги, Брайан собирался её актуализировать до 2012 сервера, но написать и качественно переработать книгу (а она немаленькая) — это не за хлебушком сходить, труд титанический. А с учётом темпов развития технологий, многие книги устаревают уже на стадии черновиков. Я сам желал бы обновления книги, но шансов на успех тут мало по объективным причинам.

А клиент обязан по какому-то стандарту эти настройки проверять, или просто может, если хочет? Допустим, случилась пожарная ситуация, и надо точно убедиться, что любые клиенты на произвольной (более-менее современной, XP и прочие древности забудем), в т.ч. невиндовой платформе в течение, условно, суток получат правильный ответ о том, что сертификат отозван — для этого в принципе возможно что-то предпринять на серверной стороне?

К сожалению, нет индустриальных стандартов на эту тему. Даже поведение кэша нигде не формализовано. То, что я написал про E-tag и Max-Age, pre-fetch это справедливо только для платформ Microsoft Windows и приложений, использующих CryptoAPI для проверки сертификатов, включая .NET Framework (на счёт .NET Core не уверен). И то, это не стандарт (как RFC), а внутренняя спецификация.

Проверка отзыва — это строго прерогатива клиента, следовательно, на сервере ничего нельзя сделать. Клиент сам решает, хочет он проверять сертификат на отзыв или нет. В частности, современные браузеры (Google Chrome, FireFox) проверяют на отзыв только сертификаты Extended Validation (EV, с зелёнкой). Internet Explorer и Edge проверяют сертификаты на отзыв, но тихо пропускают, если актуальная информация об отзыве недоступна. А тот же клиент VPN SSTP не даёт подключиться к серверу, если отзыв сертификата нельзя проверить. Как-то так.
Какую именно проблему тогда решает обновление корневого сертификата? Скорее всего я неверно понимаю эту назначение этой процедуры.

Можно ли ускорить запуск подписанного скрипта PowerShell? Пробовал внедрить подписывание своих скриптов сертификатом издателя, но сразу заметил что запуск исполнения откладывается на пару десятков секунд (скорее всего шла проверка подписи). Использовался stand-alone ЦС. На сколько помню, ЦС иногда был включен, иногда выключен, а как изменялась скорость проверки в этих ситуациях я не помню. На что мне нужно было обратить внимание?
> исполнения откладывается на пару десятков секунд
Это означает, что список отзыва и/или сертификаты промежуточных ЦС недоступны. Но этот вопрос лучше адресовать на профильных форумах.
Sign up to leave a comment.