Этот файл не может использоваться как список отзыва сертификатов
Обновлено: 07.07.2024
Как и в случае с любыми другими удостоверяющими документами, кроме возможности выдать сертификат, должна быть возможность прекратить его действие. Прекращение действия сертификата называется его отзывом, и в каждый момент времени существует файл, называемый списком отзыва (CRL), содержащий перечень сертификатов, действие которых прекращено. Ссылка на этот файл может быть вставлена непосредственно в сертификат (параметр crlDistributionPoint В секции ssl_server и ssl_client), кроме того, многим программам необходимо задавать ссылку на список отзыва в явном виде.
В каких случаях сертификат отзывается и помещается в CRL?
superseded - прекращение срока действия. Самая очевидная причина - сертификат отзывается просто потому, что вышел его срок действия и вместо него был выпущен новый сертификат. Эта причина совершенно естественно является одной из наиболее частых причин отзыва.
affilationchanged - прекращение обслуживания в данном СЛ. Как правило, для корпоративных СЛ это увольнение человека, которому был выдан сертификат, либо прекращение работы сервера/сервиса (что встречается гораздо реже, разве только списание техники).
keycompromise - компрометация ключа сертификата. Это, как правило, означает, что устройство, на котором хранился ключ сертификата, утеряно или похищено. Ключи пользовательских сертификатов крайне редко защищаются паролем (в моей практике такого никогда не было - все же стремятся, чтобы работало с «одной кнопки», и даже двухфакторная аутентификация тут не спасает - в 90% случаев пароль будет сохранен в браузере), поэтому при утере/хищении устройства с ключом сертификат должен быть отозван.
cacompromise - компрометация самого СЛ. Вещь куда более серьезная. Можно проработать всю жизнь и ни разу не отзывать ключи с такой причиной. Компрометация самого СЛ означает, что «ушли» ключ сертификата СЛ и пароль, которым этот ключ был защищен, и теперь злоумышленник(и) способен выдавать сертификаты кому угодно от имени данного СЛ. Если ЭТО произошло, как правило, следует массовый отзыв ключей.
cessationojoperation - сертификат больше не требуется. Бывает и такое - изменилась работа у сотрудника, ему больше не нужен доступ к ресурсам и, соответственно, не нужен и сертификат. Впрочем, эту причину не так-то просто отличить от причины «прекращение обслуживания».
Когда происходит что-либо из вышеперечисленного, сертификат помещается в CRL. CRL - это просто файл, где в закодированном виде перечислены все сертификаты, выданные когда-либо данным СА. Из этого следует тот факт, что размер CRL будет постоянно расти с каждым отозванным сертификатом. Занесение сертификата в список отозванных и формирование собственно CRL выполняются той же командой opcnssl са, которой выполняется и формирование сертификата на основе запроса. Важно отметить, что отзыв сертификата не влечет за собой формирования CRL - он просто меняет данные в файле index.txt - меняет признак с V на R, проставляет дату отзыва и причину отзыва. Формирование собственно CRL делается другой командой.
CRL, так же как и сертификат СЛ, должен распространяться без ограничения доступа, в особенности если в сертификат встраивается ссылка на точку распространения CRL crlDistributionPoint. С этой точки CRL будет запрашиваться всякий раз, когда какой-либо из браузеров захочет проверить, а не находится ли предъявленный ему сертификат в списке отозванных?
Проблемой является главным образом то, что срок действия CRL по умолчанию составляет всего 30 дней. После истечения этого срока, например, Apache перестает принимать любые сертификаты, сообщая, что сертификат отвергнут. Конечно, пока сертификаты выдаются только серверам/сервисам, CRL можно и не использовать. Но как только начинается выдача сертификатов сотрудникам - без него уже не обойтись, поэтому, пожалуйста, обращайте внимание на дату последнего обновления CRL! Даже если не было отозвано ни одного сертификата, если ни у кого ничего не крали, пароли не ломались, все вели себя примерно - не забудьте пересоздать CRL и выгрузить его на точку распространения!
Давайте отзовем только что выданный нами сертификат.
Using configuration from openssl.cnf
Enter pass phrase for /usr/local/ca-dhw/ssl.key/caserv.key:
Revoking Certificate 01.
Data Base Updated
Вводим пароль сертификата СЛ. Готово. Теперь запись в index.txt про наш сертификат выглядит вот так:
R 130325210007Z 120326180740Z,cessationOfOperation 01 unknown
Как мы видим, в строке появились дата отзыва и причина отзыва, а также изменился признак. Рассмотрим теперь ключи, которые мы использовали при выполнении этой операции, а также какие могли бы использовать. Их немного.
cortfig - указывает расположение конфигурационного файла OpenSSL. Если не указать, то будет использован файл /etc/ssl/ openssl.cnf.
revoke - указывается файл, содержащий сертификат, который нужно отозвать.
crlcompromise - если сертификат отзывается по причине компрометированное™, то этот параметр позволяет задать время, с которого он стал недоверенным. По умолчанию со дня отзыва. Время задается в формате ГГММДДЧЧММССг.
crl_CA_compromise - если сертификат отзывается по причине компрометации СА, то этот параметр позволяет задать время, с которого он стал недоверенным. По умолчанию со дня отзыва. Время задается в формате ГГММДДЧЧММССг.
Последнее, что нам осталось сделать в рамках управления CRL, - это собственно создать его.
Using configuration from openssl.cnf
Enter pass phrase for /usr/local/ca-dhw/ssl.key/caserv.key:
Конечно, потребуется пароль сертификата СЛ. CRL будет сформирован в файл cacrl.pem, хотя, возможно, было бы лучше дать ему расширение .crl - некоторые программы привередничают и не желают принимать файл, если он не имеет расширения .crl. Для данной команды используется совсем небольшой набор опций
gencrl - указывает как раз на то, что должен быть сформирован CRL, потому что по умолчанию «работой» команды СЛ является создание сертификатов.
out - просто задает имя выходного файла.
config - указывает расположение конфигурационного файла OpenSSL. Если не указать, то будет использован файл /etc/ssl/ openssl.cnf.
crldays, crlhours - число дней или часов до выпуска следующего CRL. После истечения указанного интервала CRL автоматически считается устаревшим. По умолчанию берется из конфигурационного файла openssl.cnf.
crlexts - указывает на имя секции, в которой описаны расширения CRL. По умолчанию имя секции задается в конфигурационном файле openssl.cnf.
Ну и самое последнее, что нам осталось сделать, - это создать Merged Control File (MCF). Что такое MCF? Это изобретение ленивых программистов, не пожелавших ввести еще один параметр конфигурационного файла для CRL. Вместо этого они предложили CRL объединять в один файл с сертификатом СЛ, создавшего данный CRL. Уж не знаю, насколько это экономит код, но вот запутывает это преизрядно. Так что MCF - это всего лишь текстовый файл, где записан сначала сертификат СЛ, а потом сразу же, без каких бы то ни было разделителей - CRL данного СЛ. Этот шедевр кривизны будет нам периодически встречаться - как минимум в dovecot и racoon. Создается он чрезвычайно просто:
Сертификаты
Я написал несколько инструкций по этому процессу, в том числе с чего начать, как грамотно обновить и как использовать двойные сертификаты. Это всё здорово, не правда ли? Но в чём проблема? А проблема возникнет тогда, когда всё пойдёт не по плану и у вас случится плохой день.
Нас хакнули
Если злоумышленник завладел нашим секретным ключом, то он может выдать себя за нас. Повторим это: кто-то в интернете может доказать, что он — это вы, хотя в реальности он таковым не является. Это реальная проблема, и прежде чем вы подумаете «Со мной такого никогда не произойдёт», вспомните Heartbleed. Этот крошечный баг в библиотеке OpenSSL позволял злоумышленнику украсть ваш секретный ключ, даже если вы соблюдали все меры безопасности. Кроме этого, было бесчисленное множество случаев, когда секретные ключи утекали из-за случайности или небрежности. Реальность такова, что мы можем потерять наш секретный ключ, а когда это случается, нам требуется способ помешать злоумышленнику использовать наш сертификат. Нужно его отозвать.
Отзыв
В случае компрометации мы должны отозвать сертификат, чтобы исключить возможность злоупотреблений. Как только сертификат помечен как отозванный, браузер знает, что ему нельзя доверять, даже если у него не закончился срок действия. Владелец запросил отзыв, и ни один клиент больше не должен принимать этот сертификат.
Как только мы узнаём о факте взлома, мы связываемся с CA и просим отозвать наш сертификат. Нужно доказать факт владения сертификатом, и как только мы сделали это, то CA помечает сертификат как отозванный. Теперь нужен способ сообщить об этом факте каждому клиенту, которому может потребоваться данная информация. Прямо в этот момент браузер, конечно, ничего не знает, и это проблема. Есть два механизма, которые используются для распространения информации: это список отозванных сертификатов (Certificate Revocation List, CRL) и протокол проверки статуса сертификата (Online Certificate Status Protocol, OCSP).
Списки отозванных сертификатов
Проблема CRL в том, что списки содержат много сертификатов от конкретных центров сертификации. Не вдаваясь в излишние детали, они разбиваются на промежуточные сертификаты CA, а центр сертификации может выдавать списки меньшими частями, но проблема остаётся той же. У списка CRL немалый размер. Другая проблема в том, что у клиента нет свежей копии CRL, ему нужно запросить её при первоначальном подключении к сайту, что может сделать всю процедуру заметно медленнее. Всё это выглядит не очень приятно, так что посмотрим на OCSP.
Протокол проверки статуса сертификата
OCSP предлагает намного более красивое решение проблемы и имеет значительное преимущество перед CRL. Здесь мы спрашиваем у CA статус единственного, конкретного сертификата. Это значит, что CA должен вернуть только простой ответ: сертификат либо хороший, либо отозван, и такой ответ гораздо меньше по размеру, чем список CRL. Отлично!
Полный сбой
Выше я говорил о CRL и OCSP, двух механизмах проверки сертификатов браузером, и они выглядят таким образом.
После получения сертификата браузер обратится к одному из этих сервисов и отправит запрос для окончательного выяснения статуса сертификата. А что, если у вашего CA плохой день и его инфраструктура в офлайне? Что, если ситуация выглядит так?
Здесь у браузера только два варианта. Он может отказаться принимать сертификат, поскольку не способен проверить его статус. Или взять на себя риск и принять сертификат, не зная его статус, отозван он или нет. У обоих вариантов есть свои преимущества и недостатки. Если браузер откажется принимать сертификат, то каждый раз при уходе инфраструктуры CA в офлайн ваши сайты тоже уходят туда же. Если браузер продолжит принимать сертификаты, то он рискует принять сертификат, который был украден, и подвергает пользователя риску. Это трудный выбор, но прямо сейчас, сегодня, ничего такого на самом деле не происходит…
Частичный сбой
На самом деле сегодня браузеры выполняют так называемую проверку отзыва сертификата с частичным сбоем. То есть браузер попытается проверить статус сертификата, но если ответ не пришёл совсем или не пришёл за короткий промежуток времени, то браузер просто забывает об этом. Ещё хуже, что Chrome даже не пытается проверить сертификат. Да, вы прочитали правильно, Chrome даже не пытается проверить статус сертификата, который ему поступает. Вы можете найти это странным, но я полностью согласен с их подходом и я рад сообщить, что Firefox тоже, вероятно, скоро начнёт работать так же. Позвольте объяснить. Проблема с полным сбоем очевидна: если у CA плохой день, то у нас тоже он будет, вот так мы пришли к логике частичного сбоя. Браузер теперь пытается осуществить проверку сертификата на предмет отзыва, но полностью отказывается от неё, если она занимает слишком много времени или если кажется, что CA ушёл в офлайн. Погодите, какие были последние слова? Проверка сертификата на предмет отзыва отменяется, «если кажется, что CA ушёл в офлайн». Интересно, может ли злоумышленник имитировать такие условия?
Если вы осуществляете атаку MiTM, то вам нужно всего лишь блокировать запрос на проверку сертификата и создать впечатление, что CA не работает. Браузер тогда столкнётся с частичным сбоем проверки и продолжит радостно использовать отозванный сертификат. Если вас никто не атакует, то каждый раз при проверке этого конкретного сертификата вы тратите время и ресурсы на проверку, что сертификат не отозван. И один раз, когда вас атакуют — тот единственный раз, когда вам по-настоящему нужна такая проверка — злоумышленник просто блокирует соединение, и браузер проходит через частичный сбой. Адам Лэнгли из Google лучше всех описал, что такое отзыв сертификата: это ремень безопасности, который рвётся в момент аварии, и он прав. Вы каждый день садитесь в машину и пристёгиваете ремень безопасности — и он даёт вам приятное и комфортное ощущение безопасности. А потом в один день что-то идёт не по плану — вы попадаете в аварию, и вот тут вы вылетаете в ветровое стекло. В тот единственный раз, когда он действительно нужен, ремень безопасности вас подводит.
Исправление проблемы
Проприетарные механизмы
Если сайт скомпрометирован и злоумышленник получил секретный ключ, то он может подделать этот сайт и причинить некоторый вред. Здесь ничего хорошего, но могло быть и хуже. Что если CA скомпрометирован и злоумышленник получил секретный ключ для промежуточного сертификата? Это было бы катастрофой, потому что тогда злоумышленник может подделать буквально любой сайт, который захочет, подписав собственный сертификат. Поэтому вместо онлайновой проверки промежуточных сертификатов на предмет отзыва у Chrome и Firefox есть собственные механизмы для той же задачи.
В Chrome он называется CRLsets, а в Firefox — OneCRL. Эти механизмы проверяют списки отозванных сертификатов, объединяя доступные CRL и выбирая оттуда сертификаты. Так проверяются особо ценные сертификаты вроде промежуточных, но что насчёт обычных, наших с вами?
OCSP Must-Staple
Чтобы объяснить, что такое OCSP Must-Staple, нужно сначала вкратце разобраться, что такое OCSP Stapling. Я не хочу здесь вдаваться в лишние подробности, вы можете получить всестороннюю информацию из моего блога по OCSP Stapling, но вот суть. OCSP Stapling избавляет браузер от необходимости отправлять запрос OCSP, выдавая ответ OCSP вместе с самим сертификатом. Это называется OCSP Stapling, потому что сервер должен «скрепить» (staple) ответ OCSP с сертификатом и выдать их вместе.
На первый взгляд это кажется немного странным, потому что сервер как будто «сам удостоверяет» собственный сертификат как неотозванный, но всё работает правильно. Ответ OCSP действует только короткий промежуток времени и подписан CA точно так же, как сертификат. Так что если браузер может удостовериться, что сертификат подписан CA, то точно так он может удостовериться, что ответ OCSP тоже подписан этим CA. Это устраняет большую проблему приватности и избавляет клиента от бремени выполнять внешний запрос. Лучший вариант! Но на самом деле не лучший, извините. OCSP Stapling — отличная вещь, и все мы должны поддерживать эту технологию на своих сайтах, но действительно ли мы думаем, что её будет поддерживать злоумышленник? Нет, я так не думаю, конечно же он не будет этого делать. Что нам на самом деле нужно — так это заставить сервер поддерживать OCSP Stapling, и вот для чего нужен OCSP Must-Staple. При запросе нашего сертификата у CA мы просим его установить на нём флаг OCSP Must-Staple. Этот флаг указывает браузеру, что сертификат должен поставляться с откликом OCSP или он будет отвергнут. Установить флаг легко.
После установки этого флага мы должны гарантировать, что используется OCSP Staple, иначе браузер отвергнет сертификат. В случае компрометации, если злоумышленник получит наш ключ, ему также придётся использовать OCSP Staple вместе с нашим сертификатом, а если он не включит OCSP Staple, то ответ OCSP скажет, что сертификат отозван, и браузер его не примет. Тада!
OCSP Expect-Staple
Хотя Must-Staple кажется отличным решением проверки отзыва сертификатом, это не совсем так. На мой взгляд, одной из самых больших проблем является то, что я как оператор сайта не могу точно знать, насколько надёжны метки OCSP Staple и как их принимает клиент. Без включенного OCSP Must-Staple это не является проблемой, но если включить OCSP Must-Staple и мы не уверены в надёжности или правильности OCSP Staple, это проблема для сайта. Чтобы попытаться и получить некую обратную связь о качестве меток OCSP Staple, мы можем активировать функцию под названием OCSP Expect-Staple. Я писал о ней раньше, и вы можете узнать все подробности в блоге OCSP Expect-Staple, но здесь тоже объясню вкратце. Вдобавок к списку предзагрузки HSTS вы запрашиваете браузер прислать отчёт, удовлетворён ли он меткой OCSP Staple. Вы можете собирать отчёты сами или использовать мой сервис report-uri.io, в обоих случаях вы точно узнаете, когда ваш сайт столкнулся с проблемами при работе OCSP Must-Staple. Поскольку использование списка предзагрузки HSTS не настолько очевидно, как мне бы хотелось, я также написал спецификацию для определения нового заголовка безопасности под названием Expect-Staple, чтобы обеспечивать ту же функциональность ценой меньших усилий. Идея в том, что теперь вы можете установить этот заголовок и включить функцию отправки отчётов, которые так нам нужны, ещё до активации Must-Staple. Установка заголовка будет простой, как и всех остальных заголовков безопасности:
Поддельные сертификаты
Если мы говорим об отзыве сертификатов, то должны рассмотреть тему их подделки. Если некто пытается скомпрометировать CA или как-то ещё получить сертификат, который ему не положен, то как он будет действовать? Если я прямо сейчас взломаю CA и получу сертификат на ваш сайт, то вы не узнаете об этом до тех пор, пока об этом не сообщат в новостях. У вас в компании даже может быть инсайдер, который получит сертификат в обход внутренних процедур, и он будет делать с ним всё что захочет. Нам нужна стопроцентная прозрачность, и скоро мы её получим. Это Certificate Transparency.
Certificate Transparency
CT — новое требование, которое станет обязательным в начале следующего года. Оно предусматривает, что все сертификаты должны заноситься в публичный журнал, чтобы браузер им доверял. Вы можете почитать статью с более подробным описанием CT, но суть в том, что CA заносит все выданные сертификаты в журнал CT.
Эти журналы полностью открыты, и любой может посмотреть их, так что если кто-то получит сертификат на ваш сайт, то вы об этом узнаете. Например, здесь вы можете увидеть все сертификаты, выданные на мой домен, и поискать свой собственный. Есть также сервис CertSpotter от sslmate для той же цели, а я использую инструмент Facebook Certificate Transparency Monitoring, который присылает вам письмо каждый раз, когда выдан сертификат на заданный домен. Стандарт CT — это фантастическая идея, и я не могу дождаться, когда он станет обязательным, но есть одна оговорка. Дело в том, что CT — это только первый шаг. Знать об этих сертификатах хорошо, но у нас по-прежнему остаются все упомянутые проблемы с их отзывом. Тем не менее, мы можем решать только по одной проблеме за раз, и даже самые лучшие в мире механизмы отзыва неэффективны, если мы не знаем, какие сертификаты нужно отзывать. CT по крайней мере даёт нам эту информацию.
Авторизация центров сертификации
Предотвратить выдачу сертификата намного проще, чем пытаться отозвать его, и именно для этого нужна авторизация центров сертификации (CAA). Опять же, подробности есть в статье по ссылке, но вкратце суть в том, что мы можем авторизовать только конкретные центры сертификации выдавать нам сертификаты, в отличие от нынешней ситуации, когда мы не можем указать вообще никаких предпочтений. Авторизация делается так же просто, как создание записи DNS:
scotthelme.co.uk. IN CAA 0 issue "letsencrypt.org"
Хотя авторизация CA — не особенно сильный механизм, и он не способен помочь во всех ситуациях некорректной выдачи сертификатов, но в некоторых случаях он полезен, так что следует заявить о своих предпочтениях, создав запись CAA.
Заключение
В настоящий момент существует реальная проблема, что мы не можем отозвать сертификат, если кто-то получил наш секретный ключ. Только представьте, во что это выльется при раскрытии следующей глобальной уязвимости масштаба Heartbleed! Одна вещь, которую вы можете попытаться сделать — это ограничить размер ущерба от утечки, сократив срок действия своего сертификата. Вместо трёх лет указывайте один год или даже меньше. Let's Encrypt выдаёт только сертификаты, которые действительны всего лишь 90 дней! С сокращением времени жизни вашего сертификата у злоумышленника будет меньше времени для злоупотреблений. Кроме этого мы мало что можем сделать.
Я бы хотел закончить статью вопросом: следует ли нам исправлять процедуру отзыва сертификатов? Впрочем, это тема для другой статьи.
Список отзывов сертификатов (Certificate revocation list) - представляет собой файл указывающий на список сертификатов с указанием серийного номера сертификата, даты отзыва, причина отзыва. В целом списки отзыва сертификатов (CRL) используются для передачи сведений об отзыве сертификатов пользователям, компьютерам и приложениям, пытающимся проверить подлинность сертификата.
При каких ситуациях ваш сертификат может попасть в указанный список:
1. При выдаче сертификата УЦ ошибся в части реквизитов, поэтому был выдан новый сертификат.
2. Сертификатом завладело третье лицо, кто мог бы подписывать за вас (т.н. компрометация ключа).
3. Сертификат был отозван по заявлению владельца сертификата.
4. Сменилось уполномоченное лицо, владеющее сертификатом;
Формируется указанный список центром сертификации и публикуется в любое доступное место для пользователей, чтобы пользователь в свою очередь мог его установить.
После проведенной установки CRL файла ПО использующее функции подписания и шифрования будет проверять находится ли ваш сертификат в указанном списке. В случае если ваш сертификат находится в списке, то подписывать и шифровать файлы и документы данным сертификатом вы уже не сможете.
Что это нам дает? Прежде всего вы всегда можете быть уверены, что сертификат, с которым вы сейчас работаете, является действующим и легитимность выполняемых действий будет подтверждена. Соответственно все законно и мы можем работать в дальнейшем спокойно.
Предположим, что кому-то (или чему-то) сертификат больше не нужен (человек уволился, скомпрометирован секретный ключ и т.п.). Срок действия сертификата ещё не кончился, но нужно, чтобы он не работал. Для этого администратор CA обновляет список отозванных сертификатов и размещает его в доступном для всех месте.
Петя уволился (сам или нет..)
1. На место Пети посадили Колю, который получил полный доступ к всей информации Пети. При этом ещё не все знают, что Пети нет.
2. Маша (которая ещё не знает, что случилось) шлёт Пете файл (что-то личное?!), зашифровав его Петиним открытым ключом.
3. Коля имеет доступ к секретному ключу Пети и может прочитать информацию от Маши. Так же не забываем, что он может ставить ЭЦП от имени Пети.
Если бы Маша проверила Петин сертификат по CRL, то она бы узнала, что сертификатом Пети шифровать уже нельзя. Да и другие люди должны знать, что Петя ничего больше подписывать не должен. Т.е. все должны регулярно обновлять CRL (если это не делается автоматически или ПО само не производит on-line проверку сертификата).
Таким нехитрым образом происходит работа CRL. Более глубже вдаваться в теорию работы со списками отзывов сертификатов нет смысла, поэтому перейдем к практике.
Итак, что же нам прежде всего необходимо сделать, чтобы мы могли полноценно использовать CRL в практических целях организации? Во-первых, если ЦС не развернут в вашей организации, то желательно запрашивать раз в неделю (т.к. CRL во внешних организациях, зачастую формируются именно раз в неделю), и проводить его установку на локальные машины в профиль пользователя. Если же в вашей организации развернут ЦС, то формирование crl и его применение в дальнейшем лежит на ваших плечах. Подробнее опишем ситуацию ниже.
Ситуация: ЦС был выдан сертификат. В DIRECTUM указанным сертификатом даже было подписано задание, задачи, документы. Выданным сертификатом завладело третье лицо, нам необходимо обеспечить, чтобы в рамках системы DIRECTUM, указанный сертификат уже не мог использоваться.
В дальнейшем будем иметь дело со следующим сертификатом:
А вот и подписанное задание данным сертификатом.
Отзыв сертификата
Итак опишу действия необходимые для отзыва сертификата.
1. Заходим в консоль ЦС. Открываем раздел "Выданные сертификаты".
2. Вызываем контекстное меню на необходимом нам сертификате, выбираем пункт "Все задачи" -> "Отзыв сертификата".
3. Проверяем, что сертификат отозван. На рисунке будет также видно, что серийный номер совпадает с тем, что был изначально указан в задаче.
На этом операции по отзыву сертификата окончены. Сейчас переходим к следующему пункту
Формирование CRL
CRL формируется также на самом ЦС довольно нехитрыми действиями.
1. Зайдите в консоль ЦС. Выбираем раздел "Отозванные сертификаты. Вызовем контекстное меню и выберем пункт "Все задачи" -> "Публикация".
Выберите тип публикуемого CRL: полный или разностный. Основное отличие это формирование полного списка или за выбранный при настройке период публикации. Если в вашей организации выдачей сертификатов не занимаются каждый день, и список формируемых сертификатов не велик, то лучше выбрать тип "Полный". После выполнения указанных действий, получаем список отозванных сертификатов.
Также сформировать список CRL можно и при помощи командной строки вызвав команду certutil -crl.
2. После публикации указанного списка, необходимо его сформировать в файл. Для этого зайдите в веб-форму ЦС. Выберите действие "Загрузка сертификата ЦС, цепочки сертификатов или CRL" -> "Загрузка сертификата ЦС, цепочки сертификатов или CRL". Сохраните указанный файл на компьютере.
После проделанных операций мы получаем список отзывов сертификата. Выглядит он следующим образом:
Замечаем, что в указанном списке уже есть наш сертификат, который мы отозвали. Операция формирования CRL завершена, перейдем к следующему пункту
Установка CRL
Установка CRL проводится на каждом локальном профиле. При этом устанавливается указанный список, как обычный сертификат:
Далее знакомый интерфейс по установке сертификатов предложит нам установить сертификат. Особенностей в этом случае нет: выбираем "Автоматический выбор хранилища". После установки списка отзывов, можно проверять работает ли он, и можем ли мы подписать, что-либо после указанных операций.
Проверка работоспособности CRL
Как видно из скриншота, информация совпадает, выполнять подписание указанным сертификатом мы больше не можем. Главное предназначение списка отзыва сертификатов выполняется.
Дополнительную информацию о процедуре формирования CRL, а также необходимых команд, вы можете найти на следующем ресурсе:
Эту процедуру можно использовать для настройки WEB1 веб-сервера для распространения списков отзыва сертификатов.
Для выполнения этой процедуры необходимо быть членом группы "Администраторы домена".
В приведенной ниже процедуре замените имя учетной записи пользователя, имя веб-сервера, имена папок и расположения, а также другие значения соответствующими параметрами развертывания.
Настройка WEB1 для распространения сертификатов и CRL
в WEB1 запустите Windows PowerShell от имени администратора, введите explorer c:\ и нажмите клавишу ввод. Windows Обозреватель открывается на диске C.
Создайте новую папку PKI на диске C:. Для этого щелкните Домой, затем щелкните Создать папку. Создается новая папка с выделенным временным именем. Введите pki и нажмите клавишу ВВОД.
в обозревателе Windows щелкните правой кнопкой мыши созданную папку, наведите указатель мыши на пункт поделиться с, а затем выберите определенные пользователи. Откроется диалоговое окно " общий доступ к файлам ".
В окне " общий доступ к файлам" введите Издатели сертификатови нажмите кнопку добавить. Группа издателей сертификатов будет добавлена в список. В списке на странице уровень разрешенийщелкните стрелку рядом с пунктом Издатели сертификатов, а затем щелкните чтение и запись. Щелкните общий доступ, а затем — Готово.
Откройте консоль IIS. В диспетчере серверов откройте меню Сервис и выберите пункт Диспетчер служб Internet Information Services (IIS).
в дереве консоли диспетчера службы IIS (IIS) разверните узел WEB1. Если появится приглашение приступить к работе с веб-платформой Майкрософт, нажмите кнопку Отмена.
Разверните Сайты, щелкните правой кнопкой мыши Default Web Site и выберите Добавить виртуальный каталог.
В списке псевдонимвведите PKI. В качестве физического пути введите к:\пки, а затем нажмите кнопку ОК.
Разрешите анонимный доступ к виртуальному каталогу инфраструктуры открытых ключей, чтобы любой клиент мог проверить срок действия сертификатов ЦС и списки отзыва сертификатов. Для этого сделайте следующее:
Убедитесь, что на панели Подключения выбрано pki.
На домашней странице pki щелкните Проверка подлинности.
На панели Действия щелкните Изменение разрешений.
На вкладке Безопасность щелкните Изменить.
В диалоговом окне Разрешения для pki нажмите кнопку Добавить.
На панели Домашняя страница pki дважды щелкните Фильтрация запросов.
Вкладка Расширения имен файлов на панели Фильтрация запросов выбрана по умолчанию. На панели Действия щелкните Изменение параметров функций.
В диалоговом окне Изменение параметров фильтрации запросов выберите Разрешить двойное преобразование символов и нажмите кнопку ОК.
в MMC диспетчера службы IIS (IIS) щелкните имя веб-сервера. Например, если веб-сервер называется WEB1, щелкните web1.
В меню действиявыберите команду перезапустить. Службы Интернета остановлены, а затем перезапускаются.
Добрый день всем.
Как работает функция
МенеджерКриптографии.НачатьПроверкуСертификата(ОписаниеОповещения, Сертификат, РежимПроверки)?
Какие свойства сертификата она проверяет или какие системные свойства ОС она использует?
(4) Martinian, речь не про конфигурацию, а про процедуры встроенного языка.Конфигурации - все, где используются ЭД (1) Stim213, а в саму процедуру не зайти? Это "МенеджерКриптографии" модуль или компонента? Если второе, то идите к разрабам компоненты.
(6) TMV, МенеджерКриптографии - это внутренний 1С объект, который инициируется программно. Это не компонента.
Описание процедуры в СП ничего не говорит.
МенеджерКриптографии (CryptoManager)
НачатьПроверкуСертификата (BeginCheckingCertificate)
Синтаксис:
НачатьПроверкуСертификата(<ОписаниеОповещения>, <Сертификат>, <РежимПроверки>)
Параметры:
Тип: ОписаниеОповещения.
Содержит описание процедуры, которая будет вызвана после завершения проверки сертификата со следующими параметрами:
<ДополнительныеПараметры> - значение, которое было указано при создании объекта ОписаниеОповещения.
В случае ошибки генерируется исключительная ситуация и вызывается процедура обработки ошибок из ОписаниеОповещения.
<Сертификат> (обязательный)
Тип: СертификатКриптографии.
Проверяемый сертификат.
<РежимПроверки> (необязательный)
Тип: РежимПроверкиСертификатаКриптографии; Массив.
Указывает режим проверки.
Содержит один объект или массив объектов режимов проверки.
Описание:
Начинает проверку сертификата.
(7) Stim213, ну а режим проверки, разве не отвечает на этот вопрос ? Насколько я понимаю, эти параметры сертификата он и проверяет скопом, либо можно конкретно указать что проверятьРежимПроверкиСертификатаКриптографии (CryptoCertificateCheckMode)
Значения
ИгнорироватьВремяДействия (IgnoreTimeValidity)
ИгнорироватьДействительностьПодписи (IgnoreSignatureValidity)
ИгнорироватьПроверкуВСпискеОтозванныхСертификатов (IgnoreCertificateRevocationStatus)
РазрешитьТестовыеСертификаты (AllowTestCertificates)
Читайте также: