- Почему сейчас всё работает именно так?
- Основания для прекращения действия сертификата
- Google chrome/cromium
- Microsoft internet explorer/edge
- Mozilla firefox
- Как узнать срок действия электронной подписи
- Как установить отозванные
- Какие бывают корневые сертификаты и для чего нужны
- Какие есть перспективы?
- Конфигурация outlook 2021
- Конфигурация outlook 2021
- Настройка outlook 2000
- Настройка outlook 2002/2003
- Настройка outlook 2007
- Настройка outlook express
- Онлайн-обновление эп
- Офлайн-обновление эп
- Проверки статуса сертификатов, реализованные в веб-браузерах
- Решение проблемы
- Схема для большинства
- Удостоверяющий центр-управление статусом сертификатов
- Часто задаваемые вопросы
Почему сейчас всё работает именно так?
Об этом хорошо написано
. Отсутствие
hard fail
и отказ от явного выполнения OCSP-запросов на стороне клиента обусловлены следующими факторами:
- инфраструктура УЦ станет единой точкой отказа. Недоступность OCSP-сервера может стать причиной отказа в обслуживании целого сегмента Интернета. Инфраструктура УЦ становится новой целью для DDoS;
- увеличение затрат УЦ на поддержку инфраструктуры. УЦ требуется покупать каналы с большей пропускной способностью и обеспечивать защиту от DDoS;
- снижение надёжности TLS-соединений в нестабильных или зашумлённых сетях (например, мобильных сетях);
- увеличивается объём пересылаемого трафика и требуется большая полоса пропускания, что критично, опять же, для мобильных клиентов;
- проблемы использования OCSP вместе captive portal. Пароли, как правило, передаются поверх TLS, однако установить TLS-соединение и аутентифицироваться не получится, пока не были получены ответы от OCSP-серверов. Отправить же OCSP-запросы нельзя, поскольку OCSP-серверы (как минимум для сертификатов промежуточных УЦ), как правило, находятся в Интернете, и на этом этапе доступа к ним нет. Эта проблема может быть решена с помощью прикреплённых OCSP-ответов, однако проверка статуса промежуточных сертификатов на текущий момент всё равно требует отправки OCSP запросов, поскольку ни один браузер не поддерживает прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961).
При этом полного отказа от явного выполнения OCSP-запросов на стороне клиента не происходит, поскольку он всё ещё может защитить от «человека посередине» в случаях, когда он находится «близко» к серверу «далеко» от клиента, т.е., имеет доступ к TLS-трафику, но не может блокировать OCSP:
Основания для прекращения действия сертификата
Регламентируется отмена электронной подписи новым приказом Казначейства России №11н от 16.03.2020. Прекращает действие не сам ключ подписи (электронный носитель), а сертификат, который изначально и запускает действие верифицирующей системы. Инициаторами отзыва выступают не только заказчики и владельцы ЭЦП, но и специалисты Федерального казначейства.
Правила устанавливает Казначейство. Для этого выпускают специальные нормативные акты, в которых закреплены сроки и порядок отзыва ЭП. В регламенте работы с подписью указано, по какой причине удостоверяющий центр отзывает сертификат ЭЦП:
- Завершение срока действия ЭП.
- Закрытие или упразднение территориального органа Федерального казначейства (ТОФК), удостоверяющий центр которого выдал ЭЦП.
- Неисправность ключа, к которому привязан сертификат.
- Инициатива заказчика. В этом случае причиной для прекращения действия ЭЦП является увольнение ответственного сотрудника или снятие с него определенных полномочий по госзакупкам, закрытие организации-заказчика, нарушение функций криптографической защиты самого ключа.
- Инициатива ТОФК. Основания аналогичны (увольнение или смена данных пользователя, ликвидация заказчика или самого органа Казначейства). Если скомпрометирован носитель ЭЦП, то ключ отзовут.
Существует процедура аннулирования ЭП. Аннулируют те ключи, которые не принадлежат владельцу ЭП и которые содержатся в ранее выпущенном сертификате. ЭЦП аннулируют и по решению суда. По регламенту ФК это происходит в течение 12 часов после сообщения заказчика о несоответствии данных, о чем вносится запись в реестр и список аннулированных сертификатов.
Google chrome/cromium
Браузеры Google Chrome и Chromium версии 59 при проверке DV-сертификатов ведут себя следующим образом:
Проверки, выполняемые Chrome похожи, на те, что выполняет Firefox, с тем исключением, что в Chrome вообще отказались от выполнения OCSP-запросов при проверке DV-сертификатов. «CRLSets» в Chrome является аналогом «OneCRL» в Firefox (строго говоря, механизм «CRLSets» появился даже раньше) и обладает теми же проблемами неполноты и неподконтрольности конечному пользователю.
OCSP-запросы используются при проверке EV-сертификатов (тут картина становится практически идентичной той, что мы наблюдали для Firefox):
Как и другие браузеры, Chrome и Chromium работают в режиме soft fail. Прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961) и защита OCSP-ответов от атак повторного воспроизведения не поддерживаются.
Изменить поведение Chrome и Chromium возможно внесением изменений в групповую политику (инструкция здесь) и включением следующих опций:
Эквивалентная настройка возможна и под Linux (здесь).
После внесения этих изменений Chrome и Chromium будут выполнять проверки, аналогичные тем, что делает Internet Explorer (при отсутствии прикреплённых OCSP-ответов начнут выполнять OCSP-запросы с откатом на загрузку CRL для всей цепочки сертификатов), но в режиме hard ail, т.е., при недоступности OCSP-серверов и точек распространения CRL подключение будет запрещено:
Microsoft internet explorer/edge
Браузеры Microsoft Internet Explorer версии 11 и Microsoft Edge версии 40 ведут себя одинаково для DV- и EV-сертификатов:
В схеме, как и ранее, для простоты не показано взаимодействие с кэшем полученных ранее OCSP-ответов и CRL, хотя этому можно посвятить отдельную статью.
Для каждого проверяемого сертификата в цепочке при отсутствии прикреплённых OCSP-ответов выполняется OCSP-запрос. При этом Internet Explorer и Edge не поддерживают прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961) и не обеспечивают защиту OCSP-ответов от атак повторного воспроизведения. Если OCSP-сервер недоступен, то выполняется попытка загрузки CRL.
Проверка также выполняется в режиме soft fail. Таким образом, атака «человек посередине» также проходит успешно и также не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.
Изменить поведение Internet Explorer возможно, например, установив значение ключа реестра «HKEY_LOCAL_MACHINE SOFTWARE Microsoft Internet Explorer Main FeatureControl FEATURE_WARN_ON_SEC_CERT_REV_FAILED iexplore.exe» равным 1.
Для Edge подобных настроек не нашли.
Mozilla firefox
Поведение браузера Mozilla Firefox версии 54 (наиболее актуальной на момент написания статьи) при такой атаке отличается в зависимости от типа сертификата сервера: DV или EV. Выпуская DV-сертификат (domain validated), УЦ лишь подтверждает, что владелец ключа, указанного в сертификате, контролирует указанный в сертификате домен.
Большинство сертификатов являются DV. EV-сертификат (extended validation) подтверждает не только владение доменом, но и личность владельца домена. Такие сертификаты требуют дополнительных проверок со стороны УЦ, потому они значительно дороже и встречаются реже.
Проверка статуса DV-сертификатов, выполняемая Firefox, описывается следующей диаграммой:
В схеме для простоты не показано взаимодействие с кэшем полученных ранее OCSP-ответов, поскольку полагаем, что их либо нет (из-за атаки или из-за того, что к серверу обращаются впервые за достаточно долгое время), либо они устарели и говорят о том, что сертификат не отозван. Во втором случае поведение браузера тривиально: соединение будет разрешено.
Итак, браузер проверяет статус цепочки сертификатов сервера (сертификатов промежуточных УЦ и сертификата самого сервера). Для проверки статуса сертификатов промежуточных УЦ используется хранящуюся локально на клиенте черный список «OneCRL», содержащий информацию об отозванных сертификатах, собранную из различных точек распространения CRL.
1. Агрегатор периодически опрашивает некоторый набор точек распространения CRL.2. Из полученных CRL выбирает наиболее критичную информацию об отозванных сертификатах (например, сертификаты, отозванные из-за компрометации закрытого ключа).3. Обновляет на основе этой информации в чёрные списки в браузерах.
Агрегатор CRL и, как следствие, содержимое чёрного списка «OneCRL» контролируется Mozilla. «OneCRL» не покрывает все отозванные сертификаты, а лишь сертификаты некоторых промежуточных УЦ и небольшое количество сертификатов серверов. Это делается с целью сокращения размера чёрного списка. Текущий список «OneCRL» можно посмотреть тут.
Для проверки статуса сертификата сервера используется информация, полученная из «OneCRL», прикреплённых OCSP-ответов или ответов, полученных в результате выполнения OCSP-запроса. На диаграмме указана проверка наличия прикреплённого OCSP-ответа только для сертификата сервера, поскольку Firefox не поддерживает прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961).
Важно, что если ни один из источников информации о статусе сертификата не доступен, то сертификат не считается отозванным. Иначе говоря, проверка осуществляется в режиме soft fail. Таким образом, атака «человек посередине» проходит успешно. При этом не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.
В дополнение стоит отметить, что клиентская часть протокола OCSP, реализованная в Firefox, не поддерживает одноразовые случайные коды (nonce) и, следовательно, OCSP-ответы не защищены от атак повторного воспроизведения.
Аналогичная ситуация возникает и при проверке EV-сертификатов. Разница заключается лишь в том, что браузер дополнительно выполняет OCSP-запросы и для сертификатов промежуточных УЦ:
Изменить поведение браузера и включить режим hard fail (т.е., запрет установки TLS-соединения в случаях, когда информация о статусе сертификата недоступна) можно, установив в настройках браузера («about:config») параметр «security.OCSP.require» в значение «true»:
Следует отметить, что данная настройка не активирует использование протокола OCSP для сертификатов промежуточных УЦ в случаях, когда сервер предъявляет DV-сертификат.
Для конечного пользователя hard fail в Firefox выглядит так:
Отметим, что атака «человек посередине» всё ещё возможна!.. Нарушителю требуется провести атаку повторного воспроизведения OCSP-ответа, переслав «старый» OCSP-ответ, сгенерированный ещё до того, как сертификат был отозван. Однако проводить эту атаку можно только до тех пор, пока срок действия «старого» OCSP-ответа не истечёт. При этом срок действия OCSP-ответа может быть достаточно велик. Нередко он бывает равен неделе.
Как узнать срок действия электронной подписи
Хорошо, если вы знаете, когда заканчивается срок действия электронной подписи. Но если нет, — не страшно, за несколько дней до истечения срока действия ЭП Контур пришлет уведомление и напомнит о том, что нужно получить новый сертификат.
Получить информацию о сроках действия сертификата ЭП можно двумя способами.
В первом варианте нужен компьютер, на котором установлен сертификат ЭП и программа КриптоПро CSP. Чтобы посмотреть срок действия сертификата, следуйте пунктам ниже или откройте инструкцию с картинками:
- Нажмите «Пуск», перейдите в «Панель управления» и выберите программу «КриптоПро CSP».
- В открывшемся окне перейдите во вкладку «Сервис» и нажмите на клавишу «Просмотреть сертификат в контейнере».
- Затем нажмите на кнопку «Обзор», выберите имя ключевого контейнера, нажмите «ОК» и «Далее».
- В открывшемся окне в строке «Действителен по» указана дата окончания срока действия ЭП.
Второй вариант — воспользоваться Личным кабинетом УЦ Контура.
- Для этого откройте любой браузер и на сайте УЦ войдите в Личный кабинет.
- В открывшемся окне перейдите во вкладку «Действующие» и в правом столбце увидите срок действия каждого вашего сертификата ЭП.
Как установить отозванные
В отдельных случаях понадобится установка списка отозванных сертификатов (СОС) в дополнительном порядке. Для этого выполните следующие действия:
- откройте Internet Explorer;
- перейдите в разделе «Сервис» по пути «Свойства» — «Содержание» — «Сертификаты»;
- в подразделе «Имя точки» скопируйте в файл имеющуюся ссылку на список;
- сохраните файл на жестком диске компьютера;
- кликните по этому файлу правой кнопкой мыши для вызова контекстного меню;
- следуйте инструкциям «мастера».
Иногда в перечне списка СОС может быть две ссылки. В этом случае понадобится повторить данный шаг.
После завершения всех действий перезагрузите ваш компьютер. Если все прошло корректно и действия были правильными, то проблем с исправлением ошибок, установкой СОС не возникает. Проблемой здесь может стать только нестабильность сетевого соединения с интернетом.
Если вам понадобилась дополнительная техническая консультация или появилась необходимость оформить ЭЦП любого типа, сделать это можно в УЦ «Астрал-М». Компания имеет аккредитацию Минкомсвязи и предлагает клиентам возможность открытия цифровых подписей любого типа. Обращаясь к нам, вы получаете:
Получить дополнительную информацию можно по телефону, либо оставив запрос на сайте. Мы в течение 5 минут после получения заявки свяжемся с вами для уточнения вопросов. Мы расскажем, как получить электронную подпись и какие документы потребуются для этого.
Какие бывают корневые сертификаты и для чего нужны
Корневой сертификат участвует в «цепочке доверия». «Цепочка доверия» — это взаимосвязь нескольких сертификатов, которая позволяет проверить, действительна ли электронная подпись и можно ли доверять сертификату ЭП.
Рассмотрим «цепочку доверия», сформированную для квалифицированного сертификата электронной подписи:
1. Корневой сертификат Минцифры РФ (ранее — Минкомсвязь РФ).
Это верхнее звено «цепочки доверия». Минцифры РФ осуществляет функции головного удостоверяющего центра в России. Оно наделяет другие удостоверяющие центры, прошедшие аккредитацию, правом выдавать квалифицированные сертификаты ЭП — выдает им собственные сертификаты, подписанные корневым сертификатом Минцифры РФ.
Например, в Windows корневой сертификат можно найти через «Управление сертификатами» — «Доверенные корневые центры сертификации» — «Сертификаты».
2. Сертификат удостоверяющего центра. Официально его называют «промежуточный сертификат», но распространено также название «корневой сертификат УЦ».
Среднее звено «цепочки доверия». УЦ получает этот сертификат от Минцифры РФ, когда становится аккредитованным. С помощью своего промежуточного сертификата УЦ выдает квалифицированные сертификаты пользователям: организациям, их сотрудникам, простым физлицам (п.2.1 ст.15 63-ФЗ).
В Windows промежуточный сертификат хранится в «Управление сертификатами» — «Промежуточные центры сертификации» — «Сертификаты».
3. Личный сертификат пользователя — квалифицированный сертификат электронной подписи.
Конечное звено «цепочки». Пользователь обращается в УЦ и получает там квалифицированный сертификат ЭП (он же КЭП, ЭП или ЭЦП). В его сертификате указаны данные «вышестоящих» сертификатов — УЦ и Минцифры.
В Windows личный сертификат можно найти через «Управление сертификатами» — «Личное».
Все сертификаты должны быть установлены в хранилище сертификатов (на компьютер) и действительны. Только тогда криптопровайдер сможет проверить доверие к сертификату пользователя и действительность электронной подписи, сформированной на основе этого сертификата.

Выше мы описали «цепочку доверия» для квалифицированных сертификатов. Поскольку такие сертификаты могут выдавать только аккредитованные УЦ, то в цепочке три звена: Минцифры — аккредитованный УЦ — пользователь. Именно такую связь можно увидеть, если открыть личный сертификат пользователя на вкладке «Путь сертификации» (см. скриншот выше).
Для неквалифицированных сертификатов ЭП «цепочка доверия» может состоять только из двух звеньев: УЦ — пользователь. Это возможно потому, что УЦ для выдачи неквалифицированных сертификатов не нужна аккредитация. Звенья такой «цепочки» будут называться: «корневой сертификат» и «пользовательский (личный) сертификат»
Какие есть перспективы?
Очевидный вывод из всего сказанного ранее: проверки статуса сертификатов в браузерах не работают, и это не новость. При этом просто взять и перейти на
hard fail
нельзя по объективным причинам.
Есть ли применимое на практике решение данной проблемы? Проанализировав и собрав воедино множество уже предложенных частичных решений данной проблемы (в частности расширение сертификатов «TLS feature», сертификаты с коротким сроком действия, агрегаторы CRL и др., о чём подробно будет рассказано ниже), предлагаем вашему вниманию наше представление о том, как проверка статуса сертификатов должна происходить на практике.
В основе лежит утверждение о том, что не для всех сервисов требуется онлайн-проверки статуса сертификатов. Для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски, связанные с атакой «человек посередине» с использованием отозванных сертификатов. Иначе говоря, с точки зрения проверки статуса сертификатов, сервисы делятся на два типа:
1. Меньшинство, для которого будут проводиться строгие онлайн-проверки статуса сертификатов в режиме hard fail.2. Большинство, для которого онлайн-проверки статуса сертификатов не будут выполняться вовсе (будут предприниматься другие меры по защите).
Браузеры могут различать такие сервисы по наличию специального расширения в сертификате сервера. В зависимости от типа сервиса клиент либо будет выполнять «параноидальную» проверку статуса сертификатов, либо не будет выполнять её вовсе. Теперь подробнее о каждой из этих двух схем.
Конфигурация outlook 2021
Откройте меню File (Файл), выберите пункт Options (Параметры). В открывшемся окне выберите в закладке Trust Center (Центр управления безопасностью) пункт Trust Center Settings (Параметры Центра управления безопасностью).
Выберите закладку E-mail Security (Защита электронной почты) и выберите Параметры.
Выберите личные сертификаты, соответствующие ключам подписи и шифрования, используя кнопку Choose (Выбрать).
Отображаемый диалог позволяет пользователю указать свои личные сертификаты, которые будут использоваться при выборе личных ключей пользователя для формирования электронной цифровой подписи и расшифровки входящих сообщений. Установите флаг Send these certificates with signed messages (Передавать сертификаты с сообщением).
Окно выбора сертификата:
После выбора сертификата необходимо ввести Security Settings Name (Имя конфигурации). В противном случае Outlook выдаст ошибку:
В закладке E-mail Security (Защита электронной почты) можно включить режимы Encrypt contents and attachments for outgoing messages (Шифровать содержимое и вложения исходящих сообщений) и Add digital signature to outgoing messages (Добавлять цифровую подпись к исходящим сообщениям) для того, чтобы шифрование и электронная подпись выполнялись автоматически для каждого сообщения.
Если эти режимы не включены, опции шифрования и подписи нужно будет включать для каждого отправляемого сообщения. В этом же диалоге дополнительно можно установить опцию Send clear text signed message when sending signed messages (Отправлять подписанные сообщения открытым текстом).
При включенном режиме подпись формируется в виде одного отдельного вложения для сообщения. Если режим выключен — текст сообщения и все вложения объединяются в единое целое и кодируются в соответствии с правилами кодирования BASE64, после чего результат кодирования подписывается.
Конфигурация outlook 2021
Откройте меню File (Файл), выберите пункт Options (Параметры). В открывшемся окне выберите в закладке Trust Center (Центр управления безопасностью) пункт Trust Center Settings (Параметры Центра управления безопасностью).
Выберите закладку E-mail Security (Защита электронной почты).
Выберите личные сертификаты, соответствующие ключам подписи и шифрования, используя кнопку Choose (Выбрать).
Отображаемый диалог позволяет пользователю указать свои личные сертификаты, которые будут использоваться при выборе личных ключей пользователя для формирования электронной цифровой подписи и расшифровки входящих сообщений. Установите флаг Send these certificates with signed messages (Передавать сертификаты с сообщением).
Окно выбора сертификата:
После выбора сертификата необходимо ввести Security Settings Name (Имя конфигурации). В противном случае Outlook выдаст ошибку:
В закладке E-mail Security (Защита электронной почты) можно включить режимы Encrypt contents and attachments for outgoing messages (Шифровать содержимое и вложения исходящих сообщений) и Add digital signature to outgoing messages (Добавлять цифровую подпись к исходящим сообщениям) для того, чтобы шифрование и электронная подпись выполнялись автоматически для каждого сообщения.
Если эти режимы не включены, опции шифрования и подписи нужно будет включать для каждого отправляемого сообщения. В этом же диалоге дополнительно можно установить опцию Send clear text signed message when sending signed messages (Отправлять подписанные сообщения открытым текстом).
При включенном режиме подпись формируется в виде одного отдельного вложения для сообщения. Если режим выключен — текст сообщения и все вложения объединяются в единое целое и кодируются в соответствии с правилами кодирования BASE64, после чего результат кодирования подписывает
Настройка outlook 2000
Выберите пункт меню Сервис, Параметры… и нажмите на закладку Безопасность. Нажмите кнопку Изменить настройки….
Выберите личные сертификаты, соответствующие ключам подписи и шифрования, используя кнопку Выбрать.
Отображаемый диалог позволяет пользователю указать свои личные сертификаты, которые будут использоваться при выборе личных ключей пользователя для формирования электронной цифровой подписи и расшифрования входящих сообщений.
Как уже было отмечено ранее, в диалоге выбора сертификата отображаются только сертификаты, имеющие совпадающий адрес электронной почты и разрешенные для защиты электронной почты.
Выберите пункт меню Сервис, Параметры… и нажмите на закладку Безопасность.
В отображаемом диалоге можно включить режимы Шифровать содержимое и вложения исходящих сообщений и Добавлять цифровую подпись к исходящим сообщениям для того, чтобы шифрование и электронная цифровая подпись
выполнялись автоматически для каждого сообщения.
Если эти режимы не включены, опции шифрования и подписи нужно будет включать для каждого отправляемого сообщения.
В этом же диалоге дополнительно можно установить опцию Отправлять подписанные сообщения открытым текстом. При включенном режиме подпись формируется в виде одного отдельного вложения для всех вложений.
Если режим выключен — сообщения и все вложения будут объединены в единое вложение с включенной в него цифровой подписью.
Настройка outlook 2002/2003
Выберите пункт меню Сервис, Параметры… и нажмите на закладку Безопасность. Нажмите кнопку Параметры.
Выберите личные сертификаты, соответствующие ключам подписи и шифрования, используя кнопку Выбрать. Отображаемый диалог позволяет пользователю указать свои личные сертификаты, которые будут использоваться при выборе личных ключей
пользователя для формирования электронной цифровой подписи и расшифрования входящих сообщений. Как уже было отмечено ранее, в диалоге выбора сертификата отображаются только сертификаты, имеющие совпадающий адрес электронной почты и
разрешенные для защиты электронной почты. Выберите пункт меню Сервис, Параметры… и нажмите на закладку Безопасность. В отображаемом диалоге можно включить режимы Шифровать содержимое и вложения исходящих сообщений и
Добавлять цифровую подписьк исходящим сообщениям для того, чтобы шифрование и электронная цифровая подпись выполнялись автоматически для каждого сообщения.
Если эти режимы не включены, опции шифрования и подписи нужно будет включать для каждого отправляемого сообщения.
В этом же диалоге дополнительно можно установить опцию Отправлять подписанные сообщения открытым текстом. При включенном режиме подпись формируется в виде одного отдельного вложения для всех вложений.
Если режим выключен — сообщения и все вложения будут объединены в единое вложение с включенной в него цифровой подписью.
Настройка outlook 2007
Выберите пункт меню Сервис, Центр управления безопасностью и нажмите на закладку Защита электронной почты. Нажмите кнопку Параметры.
Выберите личные сертификаты, соответствующие ключам подписи и шифрования, используя кнопку Выбрать. Отображаемый диалог позволяет пользователю указать свои личные сертификаты, которые будут использоваться при выборе личных ключей пользователя для формирования электронной цифровой подписи и расшифрования входящих сообщений.
Выберите пункт меню Сервис, Центр управления безопасностью и нажмите на закладку Защита электронной почты.
В отображаемом диалоге можно включить режимы Шифровать содержимое и вложения исходящих сообщений и Добавлять цифровую подпись к исходящим сообщениям для того, чтобы шифрование и электронная цифровая подпись выполнялись автоматически для каждого сообщения.
Если эти режимы не включены, опции шифрования и подписи нужно будет включать для каждого отправляемого сообщения. В этом же диалоге дополнительно можно установить опцию Отправлять подписанные сообщения открытым текстом. При включенном режиме подпись формируется в виде одного отдельного вложения для всех вложений. Если режим выключен — сообщения и все вложения будут объединены в единое вложение с включенной в него цифровой подписью.
Настройка outlook express
Выберите пункт меню Сервис, Учетные записи… и нажмите на закладку Почта. В отображаемом списке учетных записей выберите ту, которую необходимо настроить, и нажмите кнопку Свойства. В отображаемом диалоге выберите закладку Безопасность.
Отображаемый диалог позволяет пользователю указать свои личные сертификаты, которые будут использоваться при выборе личных ключей пользователя для формирования электронной цифровой подписи и расшифрования входящих сообщений.
Как уже было отмечено раннее, в диалоге выбора сертификата отображаются только сертификаты, имеющие совпадающий адрес электронной почты и разрешенные для защиты электронной почты.
Выберите пункт меню Сервис, Параметры… и нажмите на закладку Безопасность.
В отображаемом диалоге можно включить режимы Шифровать содержимое и вложения исходящих сообщений и Включить цифровую подпись во все отправляемые сообщения для того, чтобы шифрование и электронная цифровая подпись
выполнялись автоматически для каждого сообщения. Если эти режимы не включены, опции шифрования и подписи нужно будет включать для каждого отправляемого сообщения.
Нажмите кнопку Дополнительно. В отображаемом диалоге установите следующие режимы:
Шифровать при отправке шифрованной почты самому себе. Установка режима включения дает возможность отправителю расшифровывать отправленные им сообщения.
Добавлять мой сертификат при отправлении сообщений с подписью.
Установка этого режима автоматически будет добавлять сертификат отправителя ко всем сообщениям. Этот режим позволяет производить обмен сертификатами с использованием подписанного сообщения, а затем использовать полученные сертификаты для
последующего шифрования сообщений между адресатами.
Кодировать сообщения перед подписыванием (непрозрачная подпись). При включенном режиме сообщения и все вложения будут объединены в единое вложение с включенной в него цифровой подписью. Если режим выключен — подпись формируется в
виде одного отдельного вложения для всех вложений.
Автоматически добавлять сертификат отправителя в адресную книгу. При включенном режиме сертификаты, передаваемые в составе подписанного сообщения, будут автоматически добавляться в адресную книгу.
Проверять, не были ли отозваны сертификаты:
только при нахождении в сети – установка флага проверки приводит к тому, что каждая операция формирования или проверки электронной цифровой подписи будет сопровождаться проверкой на отзыв сертификата.
Для проверки на отзыв используется список отозванных сертификатов (CRL), информация о нахождении которого, записывается в виде дополнения в сертификате каждого пользователя. По умолчанию данная опция не включена, и Outlook Express
не отслеживает факта компрометации ключей пользователей.
никогда не проверять – проверка на отзыв не выполняется.
Онлайн-обновление эп
Вам не нужно посещать офис УЦ, если вы решили обновить сертификат ЭП онлайн. Однако выполнить такое обновление можно, если:
- у вас есть сертификат, срок действия которого еще не истек;
- этот сертификат квалифицированный;
- действует на момент подписания заявления на выдачу нового сертификата;
- ФИО, СНИЛС и ИНН, которые будут вноситься в новый сертификат полностью совпадают со сведениями в старом сертификате.
Чтобы обновить сертификат в Контуре онлайн, воспользуйтесь инструкцией ниже или перейдите в Личный кабинет УЦ и следуйте подсказкам сервиса. Если хотите обновить сертификат самостоятельно, то сделать это можете минимум за 60 дней до его окончания.
1. Для входа в Личный кабинет введите номер телефона, который указывали при получении первоначального сертификата. На этот телефон мы пришлем смс с кодом, по которому вы сможете войти.
Обычно смс-код поступает в течение двух минут, но если сообщение не пришло, воспользуйтесь клавишей «Получить смс-код повторно», которая появится через две минуты. Если код снова не поступил, обратитесь в техническую поддержку Контура — ее контакты указаны внизу страницы.
2. Если у вас несколько сертификатов, то в перечне выберите сертификат, подлежащий замене и нажмите кнопку «Заполнить заявку». Если у вас один сертификат, то вы сразу попадете на бланк заявки.
3. Приступайте к заполнению заявки. Для этого вам понадобится действующий сертификат Контура или УЦ из списка.
4. Подпишите заявку действующим сертификатом.
5. Наши операторы рассмотрят заявку в течение 1-2 дней. Мы сообщим вам об окончании проверки, после чего вы можете выпустить сертификат.
6. Выпуск сертификата обычно занимает 30 минут, иногда чуть дольше, но не более 4 часов. После чего вам придет смс «Запрос на сертификат ЭП одобрен».
7. После выпуска сертификата подтвердите, что получили его: вернитесь на страницу «Выпуск сертификата» и нажмите клавишу «Подписать расписку». Для подписания можно использовать действующий сертификат, который вы заменяете.
8. Установите сертификат: если для хранения ЭП вы выбрали токен, то его необходимо вставить в компьютер, если сертификат устанавливается на ПК, то ЭП будет помещена в память компьютера.
9. На этом все, сертификат установлен, можете работать.
Офлайн-обновление эп
Теперь разберемся, что делать, если ваша прежняя электронная подпись уже закончилась, сменился сотрудник, на которого обычно выпускали сертификат ЭП, или изменились данные организации.
В этом случае заявку нужно будет заполнить вручную, подписать и загрузить сканы документов. Поясним, как это сделать.
1. Выполните пункты 1-2 из инструкции выше.
2. Так как действующий сертификат ЭП у вас отсутствует, заявку придется подписывать вручную, а для этого понадобится принтер и телефон с камерой, фотоаппарат или цветной сканер.
Также подготовьте оригиналы или заверенные копии:
- паспорта,
- СНИЛС нового владельца ЭП — если сменился владелец сертификата,
- документы организации — если изменились данные организации.
Если все готово, нажмите кнопку «Приступить» и заполните заявку на новый сертификат.
3. Заполняйте данные об организации в соответствии с документами. Сведения о новом владельце сертификата указывайте точно как в паспорте, сохраняя букву Ё, дефисы, пробелы.
Если паспорта РФ нет, то вместо него предоставьте временное удостоверение личности.
А для иностранных граждан — паспорт иностранного государства, переведенный и заверенный нотариусом или ВНЖ. ФИО иностранного гражданина заполняйте кириллицей, точно так, как указано в нотариально заверенном переводе, серию паспорта можно не указывать (если она отсутствует в документе).
4. Внимательно проверьте данные нового владельца и организации. Если вы допустите ошибку, то оператор вернет заявку и попросит исправить неточности. После чего форма вновь отправится на проверку на 1-2 дня.
Убедитесь, что номер телефона, к которому будет привязан сертификат, указан верно. На этот номер вы получите смс-код, подтверждающий выпуск сертификата, также по телефону вы сможете подтвердить доступ к заявке.Когда все проверите, нажмите клавишу «Подтвердить данные».
5. Распечатайте заявление. В строке «Субъект персональных данных» поставьте подпись. Подпись ставится синими чернилами. Нельзя использовать факсимиле и делать исправления.
6. Проверьте актуальность документов. Если данные не изменились — их скопируют из заявки, которую вы подавали на прежний сертификат, если изменились — загрузите фото или сканы документов, подтверждающих изменения. Вы можете загрузить как оригиналы, так и заверенные копии документов.
7. После того, как все документы будут загружены, оператор проверит их. Если все заполнено верно, кнопка «Продолжить» станет активной. Кликните на нее.
8. Выберите сервисный центр, в котором будете получать сертификат. После этого отправьте заявку на проверку.
9. Вашу заявку рассмотрят за 1-2 дня, после чего вы получите инструкцию, что делать дальше.
10. Когда пойдете в сервисный центр, возьмите с собой все оригиналы документов: паспорт, заявление на выдачу сертификата и СНИЛС, если с его проверкой были проблемы.
Проверки статуса сертификатов, реализованные в веб-браузерах
Механизмы проверки статуса сертификатов, реализованные в современных Веб браузерах, представляют собой комбинацию описанных
базовых механизмов (CRL, OCSP, OCSP stapling) и их модификаций. Комбинирование базовых механизмов осуществляется с целью обеспечения резервирования: если один из источников информации о статусе сертификата становится недоступным, то используется резервный.
Для понимания основной проблемы проверок статуса сертификатов, реализованных в современных браузерах, достаточно рассмотреть следующий сценарий атаки «человек посередине».
Закрытый ключ сервера был скомпрометирован. Владелец сервера отозвал сертификат скомпрометированного ключа, сгенерировал новую пару ключей и получил новый сертификат.Нарушитель завладел отозванным закрытым ключом и сертификатом сервера. В данном сценарии мы намеренно не говорим, каким образом он это осуществил: в результате компрометации самого сервера или в результате компрометации удостоверяющего центра (УЦ). Это сделано для того, чтобы продемонстрировать, как браузеры поведут себя в обеих ситуациях.
Нарушитель, «человек посередине», контролирует весь трафик, идущий от клиента. Он может перехватывать или блокировать этот трафик, может пытаться отвечать клиенту от имени других сетевых сервисов.
Веб-браузер клиента при попытке установки TLS-соединения с сервером подключается к «человеку посередине». «Человек посередине» представляется сервером, используя отозванный сертификат без прикреплённого OCSP-ответа (a.k.a. OCSP stapling).
Нарушитель блокирует запросы, идущие от клиента ко всем OCSP-серверам и точкам распространения CRL (a.k.a. CDP). Также нарушитель блокирует попытки клиента обновить Веб-браузер или его компоненты (например, чёрные списки «CRLSets» или «OneCRL», речь о которых пойдёт позже).
Блокирование «человеком посередине» запросов ко всем OCSP-серверам и точкам распространения CRL, во-первых, поддерживает начальное условие, согласно которому нарушитель мог скомпрометировать, как сервер, так и УЦ, и, во-вторых, наиболее полно демонстрирует проверки статуса сертификатов, выполняемые современными браузерами.
Ниже приводится описание проверок статуса сертификатов, выполняемых различными Веб-браузерами под Windows. Для других платформ детали проверок могут незначительно отличаться.
Решение проблемы
Шаг № 1. Переводим программу в экспертный режим, который предоставляет доступ к полному перечню функций.
Шаг № 2. Выбираем подозрительный для операционной системы сертификат ЭЦП. Для этого:
- подключаем носитель с цифровой подписью к вашему компьютеру;
- выбираем действующий криптопровайдер и тип носителя;
- выбираем контейнер с цифровой подписью (если на токене их несколько, выбираем проблемный);
- вводим PIN-код для доступа (стандартный пароль для eToken — 1234567890, для Рутокен — 12345678).
Шаг № 3. Добавляем проблемный сертификат в перечень доверенных (именно отсутствие в последнем служит причиной появления ошибки). Для этого:
- перейдите в меню программы «КриптоАРМ»;
- войдите во вкладку «Свойства» конкретного проблемного сертификата (ее можно найти в подразделе «Личное хранилище» раздела «Сертификаты»);
- зайдите во вкладку «Статус»;
- кликните по кнопке «Посмотреть»;
- нажмите «Установить»;
- выберите раздел «Поместить сертификаты в хранилище»;
- нажмите «Обзор» и выберите пункт «Доверенные корневые сертификаты»;
- подтвердите действие.
Сам процесс занимает несколько секунд и требует последующей перезагрузки системы.
Шаг № 4. Финальным этапом остается проверка сертификата по перечню отозванных. Для этого:
- выберите нужный сертификат во вкладке «Свойства сертификата»;
- выберите пункт «По CRL, полученному в УЦ»;
- кликните по кнопке «Проверить».
Теперь можно перейти в личное хранилище, где должна быть обновлена вся информация. Если появилась зеленая галочка, то это признак устранения проблемы и наличия полного доверия со стороны операционной системы к данной ЭЦП.
Схема для большинства
Как было сказано ранее, для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме
hard fail
, не окупают риски связанные с атакой «человек посередине» с использованием отозванных сертификатов. В таком случае лучше не защищаться от данной атаки, а максимально сократить временной промежуток, в течение которого проведение данной атаки будет возможным. Для этого используются сертификаты с коротким сроком действия (например, 1-2 дня).
Таким образом, большинство сервисов будет использовать сертификаты без расширения «TLS Feature», но с коротким сроком действия. Для таких сертификатов онлайн-проверки статуса сертификатов не будут выполняться вовсе. Вместо этого будет проводиться частое обновление быстро устаревающих сертификатов.
Добавим, что использование сертификатов с коротким сроком действия эквивалентно использованию сертификатов с расширением «TLS Feature», обязывающим использовать прикреплённые OCSP-ответы, вместе с прикреплёнными OCSP-ответами, не защищёнными от атаки повторного воспроизведения (т.е.
Подход с использованием сертификатов с коротким сроком действия обладает целым рядом достоинств, однако малопригоден для сертификатов УЦ. Для проверки статуса таких сертификатов можно использовать периодически обновляемые чёрные списки аналогичные «CRLSets» и «OneCRL», но предоставляющие пользователям больший контроль на агрегаторами CRL.
Пользователи, например, должны иметь возможность добавлять новые опрашиваемые точки распространения CRL. Это важно, поскольку некоторые организации разворачивают собственные не публичные УЦ для внутреннего использования. Решением может стать возможность использования приватных агрегаторов CRL.
Удостоверяющий центр-управление статусом сертификатов
Удостоверяющий центр (далее – УЦ) предоставляет услугу по управлению статусом сертификата открытого ключа, атрибутного сертификата, а именно его приостановление, возобновление и отзыв (аннулирование).
УЦ отзывает сертификат открытого ключа, атрибутный сертификат Абонента в следующих случаях:
УЦ приостанавливает действие сертификата открытого ключа, атрибутного сертификата Абонента в следующих случаях:
Заявление Абонента на отзыв или приостановление действия сертификата открытого ключа, атрибутного сертификата подается Абонентом в письменной форме лично, либо по почте с указанием парольной фразы. Заявление на отзыв или приостановление действия сертификата открытого ключа, атрибутного сертификата оформляется в соответствии с Приложениями к Регламенту.
Отзыв или приостановление действия сертификата открытого ключа, атрибутного сертификата Абонента осуществляется УЦ не позднее 30 минут, после поступления оригинала соответствующего заявления в УЦ.
Действие сертификата открытого ключа, атрибутного сертификата приостанавливается до подачи Абонентом заявления о возобновлении действия СОК, АС. Минимальный срок приостановления действия сертификата открытого ключа, атрибутного сертификата составляет 15 (пятнадцать) дней, максимальный – в пределах срока действия сертификата открытого ключа, атрибутного сертификата.
Официальным уведомлением о факте отзыва или приостановления действия сертификата открытого ключа, атрибутного сертификата является публикация на интернет – сайте УЦ списка отозванных сертификатов открытых ключей, списка отозванных сертификатов центра атрибутных сертификатов, содержащих сведения об отозванном сертификате открытого ключа, отозванном атрибутном сертификате или сертификате открытого ключа, атрибутном сертификате, действие которых приостановлено, за исключением случаев предусмотренных Регламентом.
Временем отзыва или приостановления действия сертификата открытого ключа, атрибутного сертификата считается время издания списка отозванных сертификатов, списка отозванных сертификатов центра атрибутных сертификатов, содержащих сведения об отозванном сертификате открытого ключа, отозванном атрибутном сертификате соответственно или сертификате открытого ключа, атрибутном сертификате, действие которых приостановлено.
Возобновление действия сертификата открытого ключа, атрибутного сертификата осуществляется УЦ на основании соответствующего заявления, составленного в соответствии с Приложениями к Регламенту, либо по факту предоставления в УЦ доверенности (в случае, если действие СОК, АС было временно приостановлено по причине истечения срока действия доверенности уполномоченного представителя Абонента). Срок возобновления сертификата открытого ключа, атрибутного сертификата составляет не более трех рабочих дней с момента регистрации соответствующего заявления.
Заявление на возобновление действия сертификата открытого ключа, атрибутного сертификата подается лично в письменной форме непосредственно в УЦ или может быть направлено по почте с указанием парольной фразы, которая была определена при заключении Договора.
Сертификаты открытого ключа, атрибутные сертификаты, действие которых возобновлено, удаляются из списка отозванных сертификатов, списка отозванных сертификатов центра атрибутных сертификатов УЦ и помещаются в реестр действующих сертификатов открытого ключа, атрибутных сертификатов. УЦ издает актуальный список отозванных сертификатов, список отозванных сертификатов центра атрибутных сертификатов.
Официальным уведомлением о факте возобновления действия сертификата открытого ключа, атрибутного сертификата является публикация списка отозванных сертификатов, списка отозванных сертификатов центра атрибутных сертификатов, не содержащих сведений о соответствующем сертификате открытого ключа, атрибутном сертификате.
Возобновление действия сертификата открытого ключа, атрибутного сертификата возможно только в течение срока, на который сертификат открытого ключа, атрибутный сертификат был выпущен.
Часто задаваемые вопросы
Типичные ошибки Континент-АП при установке связи с сервером доступа
1. Ошибка «Client cert not found»
Для решения данной проблемы необходимо:
· Проверить, запущен ли процесс eapsigner161.exe;
· Если процесс не запущен, зайти в папку с установленной программой и запустить процесс вручную.
2. Ошибка «Неизвестная ошибка импорта сертификатов»
Для решения данной проблемы необходимо:
· удалить все сертификаты с истекшим сроком действия из хранилища «Личные» локального хранилища сертификатов системы (для этого можно воспользоваться оснасткой «mmc» (выбрав в меню Файл -> Добавить или удалить оснастку -> Сертификаты -> Добавить -> Готово -> Ок) или воспользоваться функционалом браузера Internet Explorer (выбрать в меню Сервис -> Свойства браузера -> Содержание -> Сертификаты));
· удалить из хранилища «Личные» локального хранилища сертификатов системы все сертификаты, которые в своем составе, в поле «Субъект», содержат следующие символы: , ; “ ” « ».
3. Ошибка «Не совпадает подпись открытого эфемерного ключа»
Для решения данной ошибки необходимо при установке личного сертификата выбирать правильный контейнер закрытых ключей. Для этого можете воспользоваться функционалом оснастки КриптоПРО CSP, используя функцию «установить личный сертификат» во вкладке «сервис», которая в своем составе имеет возможность, путем проставления галочки, автоматического поиска соответствия между контейнером закрытых ключей (значением закрытого ключа) и значением открытого ключа, содержащегося в сертификате пользователя.
4. Ошибка «Сервер отказал в доступе пользователю не найден корневой сертификат»
Для решения данной ошибки необходимо:
· проверить издателя сертификата, который используется для установления соединения (сертификат для Континент-АП имеет в качестве издателя Корневой сертификат сервера доступа «ЦС СД Интернет», «4800-sd-01.roskazna.ru» или «4800-sd-02roskazna.ru»);
· проверить наличие в хранилище «Доверенные корневые центры сертификации» локального хранилища сертификатов системы сертификата Корневой сертификат сервера доступа «ЦС СД Интернет», «4800-sd-01.roskazna.ru» или «4800-sd-02roskazna.ru», в случае его отсутствия необходимо заново произвести установку сертификата пользователя.
5. Ошибка «Сервер доступа отказал пользователю в подключении. Причина отказа: Неизвестный клиент»
Для решения данной ошибки необходимо проверить правильность, указанных в Континент-АП, адресов серверов доступа. В УФК по Московской области используются следующие адреса серверов доступа:
4800-sd-01.roskazna.ru или 4800-sd-02.roskazna.ru.
Если в процессе подключения к одному из серверов доступа возникает подобная ошибка, необходимо произвести подключение на другой сервер доступа. В случае, если описанное выше не помогает решить проблему, необходимо позвонить в Управление Федерального казначейства по Московской области (по месту получения сертификата, необходимые контактные данные опубликованы на сайте mo.roskazna.ru в разделе ГИС > Удостоверяющий центр > Континент АП > Контакты).
6. Если после установки Континент-АП произошла потеря интернет соединения необходимо в настройках сетевого адаптера, который используется для выхода в интернет, снять галочку в пункте «Continent 3 MSE Filter».
7. Ошибка «Сервер отказал в доступе пользователю. Причина отказа: многократный вход пользователя запрещен»
Для решения данной ошибки необходимо обратится в УФК по Московской области по месту получения сертификата, необходимые контактные данные опубликованы на сайте mo.roskazna.ru в разделе ГИС > Удостоверяющий центр > Континент АП > Контакты).
8. Ошибка 721 либо 628
· Проверить, работает ли подключение к интернету на АРМ.
· Отключить МСЭ, брандмауэр либо другое ПО которое может блокировать служебные порты/протоколы Континент-АП.
· Исключить проблему в канале провайдера, попробовать использовать другого, к примеру, через 3-g модем. Если с другим провайдером работает – нужно обратиться к своему с запросом на открытие служебных портовпротоколов.
