Сервер отзыва сертификатов недоступен

Почему сейчас всё работает именно так?

Об этом хорошо написано

. Отсутствие

hard fail

и отказ от явного выполнения OCSP-запросов на стороне клиента обусловлены следующими факторами:

• инфраструктура УЦ станет единой точкой отказа. Недоступность OCSP-сервера может стать причиной отказа в обслуживании целого сегмента Интернета. Инфраструктура УЦ становится новой целью для DDoS;
• увеличение затрат УЦ на поддержку инфраструктуры. УЦ требуется покупать каналы с большей пропускной способностью и обеспечивать защиту от DDoS;
• снижение надёжности TLS-соединений в нестабильных или зашумлённых сетях (например, мобильных сетях);
• увеличивается объём пересылаемого трафика и требуется большая полоса пропускания, что критично, опять же, для мобильных клиентов;
• проблемы использования OCSP вместе captive portal. Пароли, как правило, передаются поверх TLS, однако установить TLS-соединение и аутентифицироваться не получится, пока не были получены ответы от OCSP-серверов. Отправить же OCSP-запросы нельзя, поскольку OCSP-серверы (как минимум для сертификатов промежуточных УЦ), как правило, находятся в Интернете, и на этом этапе доступа к ним нет. Эта проблема может быть решена с помощью прикреплённых OCSP-ответов, однако проверка статуса промежуточных сертификатов на текущий момент всё равно требует отправки OCSP запросов, поскольку ни один браузер не поддерживает прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961).

При этом полного отказа от явного выполнения OCSP-запросов на стороне клиента не происходит, поскольку он всё ещё может защитить от «человека посередине» в случаях, когда он находится «близко» к серверу «далеко» от клиента, т.е., имеет доступ к TLS-трафику, но не может блокировать OCSP:

Что значит данная ошибка?

В переводе с английского языка текст данной ошибки звучит как «Ошибка безопасности. Неверно подписанный OCSP сертификат». Аналогичными ошибками с сертификатом SSL являются ssl_error_rx_record_too_long и ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Напомню читателю, что аббревиатура OCSP является сокращением от «Online Certificate Status Protocol» (в переводе – «Протокол статуса онлайн-сертификата»). Данный протокол предназначен для проверки статуса сертификата на предмет его отозванности, когда выданный ранее сертификат для какого-либо сайта, удостоверяющий безопасность работы с данным сайтом, может быть отозван у указанного сайта по каким-либо причинам (например, Центр сертификации посчитал работу с таким сайтом не безопасной).

Таким образом, браузер, переходя на данный сайт с «отозванным» сертификатом, может выдать вам ошибку и сообщение «sec_error_ocsp_invalid_signing_cert».

Какие ещё могут быть причины появления подобного сообщения об ошибке? Я бы отметил следующее:

• Случайный сбой в работе компьютера;
• Некорректные системные дата и время;
• Временные неполадки на нужном сетевом ресурсе.

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 подобных настроек не нашли.

Windows vista

Как убрать ошибку сертификата безопасности веб-узла для Windows VISTA:

1 . Внесите сертификат в доверенные (не рекомендуется ). Затем следует подтвердить дальнейшее открытие окна , и в появившемся «Ошибка сертификата . » вызвать окно недостоверного сертификата , обозначенное «щитом «.

2 . Выбрать «Просмотр сертификата «, затем «Общие «, где возможно отследить время действия сертификата вэб -узла .

3 . В мастере установки выберите «Установить сертификат » и «Вперёд» .

4 . Отметьте галочкой » Автоматически выбранное хранилище сертификата . «, подтверждая нажатием «Вперёд» .

5 . Выполните подтверждение операции , нажав «ДА» и «Финиш» в окне запроса . Избранный сертификат установлен .

6 . Произведенные изменения подтвердите нажатием «ОК» .

7 . Выберите строку «Поместить все сертификаты в следующее хранилище «, выполните подтверждение нажатием «Обзор «.

8 . В окне под названием «Выбор хранилища сертификатов «, отметьте «Доверенные корневые центры сертификации «, подтверждая нажатием «ОК» .

9 . Завершите процедуру : «Далее «, «Готово «, подтвердите установку , нажимая «ОК» , и презапустите браузер .

Антивирус блокирует работу opera

Если при работе с браузером Опера на экране возникает предупреждение, связанное с проверкой безопасности и имеется надпись: «Неполная цепочка сертификатов серверов Opera», то стоит обратить внимание на антивирус, установленный на компьютере. Дело в том, что антивирус, в целях повышения уровня безопасности, может частично блокировать работу Оперы.

Сообщение о том, цепочка сертификатов неполная, говорит о том, что антивирус ведет проверку протокола SSL, который отвечает за безопасность при обмене данными между двумя компьютерами. Использование протокола SSL для рядовых пользователей не является актуальным, поэтому его следует отключить. Разберем, как убрать сообщение о неполной цепочке, на примере компьютера с антивирусной программы ESET NOD 32.

1. Запустить антивирус.

2. Выбрать раздел «Настройки».

3. Кликнуть на пункт: «Перейти к дополнительным настройкам».

4. В открывшемся окне нажать в меню слева на «Интернет и электронная почта», затем «Фильтрация протоколов» и пункт «SSL».

5. Выбрать пункт «Не сканировать протокол SSL».

6. Нажать кнопку «ОК».

Готово. После того, как пользователь убрал режим фильтрации, отключенный протокол SSL позволит посещать любые сайты и браузер не будет беспокоить назойливым сообщением о проблеме безопасности.

Еще один способ отключить проверку протокола SSL, который подходит для владельцев Opera 12 и ее более поздних версий. Для отключения проверки SSL-сертификатов необходимо:

1. Кликнуть правой кнопкой мыши по ярлыку Оперы. расположенном на рабочем столе.
2. Выбрать раздел «Свойства».
3. Затем вкладку «Ярлык».
4. В графе «Объект» дописать в конце фразу «—ignore-certificate-errors» без кавычек.
5. Нажать кнопку «ОК».

Как видите, причин возникновения проблем с сертификатами может быть несколько, и они требуют разного подхода для их устранения. Перечисленные выше способы избавят пользователей браузера Opera от возникновения ошибки сертификата.

Внимание! в связи с плановой сменой сертификатов сервера «континент tls» всем пользователям гиис «электронный бюджет» необходимо выполнить установку новых корневых сертификатов

Добиваемся ocsp stapling = yes для сертификатов от wosign на nginx

cd /path/to/your/ssl/
wget -O - https://www.startssl.com/certs/ca.pem | tee -a ca-certs.pem > /dev/null 
wget -O - https://www.startssl.com/certs/sub.class1.server.ca.pem | tee -a ca-certs.pem > /dev/null 
wget -O - http://aia.startssl.com/certs/ca.crt | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null 
wget -O - http://aia1.wosign.com/ca1g2-server1-free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null 
wget -O - http://aia6.wosign.com/ca6.server1.free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null 

#########################################################
#
#
 ssl_session_cache shared:SSL:10m;
 ssl_session_timeout 5m;
 ssl_prefer_server_ciphers on;

 ssl_stapling on;
 ssl_stapling_verify on;
 ssl_trusted_certificate "/path/to/your/ssl/ca-certs.pem";

 resolver 8.8.8.8 8.8.4.4 valid=300s;
 resolver_timeout 5s;
#
#
#########################################################

        ssl on;
        ssl_certificate /path/to/your/ssl/ssl.crt;
        ssl_certificate_key /path/to/your/ssl/ssl.key;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 
        ssl_ciphers 'HIGH:!aNULL:!MD5:!kEDH';
        add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";

service nginx restart

openssl s_client -connect YourDomain.com:443 -tls1  -tlsextdebug  -status

Исправление ошибки

Как писалось выше, вся проблема в отсутствующих корневых сертификатах. Для того, чтобы данная ошибка ушла, нужно поставить эти самые корневые сертификаты — взять их можно у издателя сертификата (почти наверняка, они должны быть на их сайте). Издателя сертификата можно увидеть в поле «Кем выдан» свойств сертификата (выделено оранжевым на картинке ниже).

В качестве примера разберем как исправить подобную ошибку для сертификатов выданных Федеральным Казначейством России.

Переходим на сайт федерального казначейства, в раздел «Корневые сертификаты». Скачиваем «Сертификат Минкомсвязи России (Головного удостоверяющего центра) ГОСТ Р 34.10-2021» и «Сертификат Удостоверяющего центра Федерального казначейства ГОСТ Р 34.10-2021 CER». Открываем оба скачанных файла и устанавливаем оба сертификата.

Установка сертификата состоит из следующих действий:

1. Открываем сертификат. В левом нижнем углу нажимаем на кнопку «Установить сертификат«.
   
2. Откроется «Мастер импорта сертификатов«. Нажимаем «Далее«. В следующем окошке выбираем пункт «Поместить все сертификаты в следующее хранилище», и нажимаем кнопку «Обзор».
   
3. В списке выбора хранилища сертификатов выбираем «Доверенные корневые центры сертификации«. Нажимаем кнопку «ОК«, затем кнопку «Далее«.
   
4. В следующем окошке нажимаем на кнопку «Готово«. Затем, в окне предупреждения системы безопасности, на вопрос о том, что вы действительно хотите установить этот сертификат, нажимаем «Да». После этого последует подтверждение установки сертификатов.
   

После установки всех нужных корневых сертификатов, данная ошибка должна исчезнуть.

Как dnscrypt решил проблему просроченных сертификатов, введя срок действия 24 часа

Раньше сертификаты часто истекали из-за того, что их нужно было обновлять вручную. Люди просто забывали это сделать. С появлением Let’s Encrypt и автоматической процедуры обновления вроде бы проблема должна быть решена. Но недавняя история с Firefox показывает, что на самом деле она по-прежнему актуальна. К сожалению, сертификаты продолжают истекать.

Если кто-то пропустил эту историю, в полночь 4 мая 2021 года внезапно прекратили работать почти все расширения Firefox.

Как выяснилось, массовый сбой возник из-за того, что у Mozilla истёк срок действия сертификата, который использовался для подписи расширений. Поэтому они отмечались как «невалидные» и не проходили проверку (технические детали). На форумах в качестве обходного пути рекомендовали отключить проверку подписей расширений в about:config или переводом системных часов.

Mozilla оперативно выпустила патч Firefox 66.0.4, который решает проблему с невалидным сертификатом, а все расширения возвращаются в нормальный вид. Разработчики рекомендуют установить его и не использовать никакие обходные пути для обхода проверки подписей, потому что они могут конфликтовать с патчем.

Тем не менее, эта история ещё раз показывает, что истечение срока действия сертификатов остаётся актуальной проблемой и сегодня.

В связи с этим интересно посмотреть на довольно оригинальный способ, как с этой задачей справились разработчики протокола DNSCrypt. Их решение можно разделить на две части. Во-первых, это краткосрочные сертификаты. Во-вторых предупреждение пользователей об окончании срока действия долгосрочных.

DNSCrypt — протокол шифрования DNS-трафика. Он защищает DNS-коммуникации от перехватов и MiTM, а также позволяет обойти блокировки на уровне DNS-запросов.

Протокол оборачивает DNS-трафик между клиентом и сервером в криптографическую конструкцию, работая по транспортным протоколам UDP и TCP. Чтобы его использовать, и клиент, и DNS-резолвер должны поддерживать DNSCrypt. Например, с марта 2021 года его включил на своих DNS-серверах и в браузере «Яндекс». О поддержке объявили и некоторые другие провайдеры, в том числе Google и Cloudflare. К сожалению, их не так много (на официальном сайте перечислено 152 публичных DNS-сервера). Но программу dnscrypt-proxy можно установить вручную на клиентах под Linux, Windows и MacOS. Есть и серверные имплементации.

Как работает DNSCrypt? Если вкратце, то клиент берёт публичный ключ выбранного провайдера и с его помощью проверяет его сертификаты. Уже там находятся краткосрочные публичные ключи для сессии и идентификатор набора шифров. Клиентам рекомендуется генерировать новый ключ для каждого запроса, а серверам — менять ключи каждые 24 часа. При обмене ключами применяется алгоритм X25519, для подписи — EdDSA, для блочного шифрования — XSalsa20-Poly1305 или XChaCha20-Poly1305.

Один из разработчиков протокола Фрэнк Денис пишет, что автоматическая замена каждые 24 часа решила проблему просроченных сертификатов. В принципе, эталонный клиент dnscrypt-proxy принимает сертификаты с любым сроком действия, но выдаёт предупреждение «Период dnscrypt-proxy ключей для этого сервера слишком велик», если он действителен более 24 часов. Одновременно был выпущен образ Docker, в котором реализовали быструю смену ключей (и сертификатов).

Во-первых, это чрезвычайно полезно для безопасности: если сервер скомпрометирован или ключ утёк, то вчерашний трафик не может быть расшифрован. Ключ уже изменился. Вероятно, это составит проблему для исполнения «закона Яровой», который вынуждает провайдеров хранить весь трафик, в том числе зашифрованный. Подразумевается, что позже его можно будет расшифровать при необходимости, запросив ключ у сайта. Но в данном случае сайт просто не сможет его предоставить, потому что использует кратковременные ключи, удаляя старые.

Но главное, пишет Денис, краткосрочные ключи заставляют серверы с первого дня настроить автоматизацию. Если сервер подключается к сети, а скрипты смены ключей не настроены или не работают, это будет немедленно обнаружено.

Когда автоматизация меняет ключи раз в несколько лет, на неё нельзя положиться, а люди могут забыть об окончании срока действия сертификата. При ежедневной смене ключей это будет обнаружено мгновенно.

В то же время, если автоматизация настроена нормально, то не имеет значения, как часто производится смена ключей: каждый год, каждый квартал или три раза в день. Если всё работает более 24 часов, то будет работать вечно, пишет Фрэнк Денис. По его словам, рекомендация ежесуточной смены ключей во второй версии протокола вместе с готовым образом Docker, реализующим это, эффективно уменьшило количество серверов с истёкшими сертификатами, одновременно улучшив безопасность.

Про сертификаты:  Terra Drive 440 глянцевый - Terra Drive

Однако некоторые провайдеры всё-таки решили по каким-то техническим причинам установить срок действия сертификата более 24 часов. Эту проблему в основном решили с помощью нескольких строк кода в dnscrypt-proxy: пользователи получают информационное предупреждение за 30 дней до истечения срока действия сертификата, другое сообщение с более высоким уровнем серьёзности за 7 дней до истечения срока действия и критическое сообщение, если у сертификата осталось менее 24 часов. Это относится только к сертификатам, изначально имеющим длительный срок действия.

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

Возможно, если бы все пользователи Firefox получили такое сообщение, то уж кто-нибудь наверняка сообщил разработчикам и те бы не допустили истечения срока действия сертификата. «Я не помню ни одного DNSCrypt-сервера из списка общедоступных DNS-серверов, у которых истёк срок действия сертификата за последние два или три года», — пишет Фрэнк Денис. В любом случае, наверное, лучше сначала предупреждать пользователей, а не отключать расширения без предупреждения.

---

Как исправить ошибку sec_error_revoked_certificate

Поскольку данная проблема носит не локальный, а системный характер, то рекомендую попросту использовать другой браузер, разработчики которого продолжают доверять сертификатам «StartCom» и «WoSign» (Opera, Safari, IE). На таких браузерах переход на проблемные сайты осуществляется в нормальном режиме, и всё содержимое указанных ресурсов просматривается без каких-либо проблем. Аналогичной ошибку является NET::ERR_CERT_AUTHORITY_INVALID.

В ином случае пользователям браузера Firfox могу также порекомендовать следующее:

1. Перейдите в настройки вашего браузера, выберите вкладку «Дополнительные», кликните там на вкладке «Сертификаты», и уберите галочку с опции «Запрашивать у OCSP-серверов подтверждение текущего статуса сертификатов»;

   

2. Если это не помогло, тогда вновь идём в настройки Мозиллы, вкладка «Дополнительные», в ней вкладка «Сертификаты», жмём на кнопку внизу «Просмотр сертификатов». Находим в списке «StartCom Class 1 DV Server CA», кликаем единожды на данной строчке, а затем жмём на кнопку внизу «Изменить доверие». В появившемся меню ставим галочку напротив пункта «Этот сертификат может служить для идентификации веб-сайтов». После этого вопрос о «sec_error_revoked_certificate что делать» может быть решён.

Также можно порекомендовать временно отключить ваш антивирус, в некоторых (довольно редких) случаях данную проблему вызывало блокирование антивирусом доступа к сетевым ресурсам. Также стоит проверить корректность даты и времени на вашем ПК, иногда сбой в работе системных часов становился причиной множества сетевых проблем.

Как убрать сообщения о проблеме с сертификатом, добавив сайт в исключения

Добавить сайт в исключение из проверки защищенных соединений возможно в Kaspersky Anti-Virus, Kaspersky Internet Security, Kaspersky Total Security версии 18 и выше, а также Kaspersky Small Office Security 6 и выше. В более ранних версиях эта функция недоступна.

1. Перейдите в раздел Дополнительно и выберите Сеть .

В общем, так получилось, что у меня опять старый компьютер. На этот раз я работаю за ноутбуком Panasonic 2004 года выпуска, с процессором в 1.2 Гц (512 мб ОЗУ), процессор там стоит Pentium.

Но фишка в том, что это не просто Пентиум 3 или 4, а Пентиум М с 2 Мб кэшем! В общем, браузер Mozilla для этого ноута слишком «тяжелый», а вот Opera 12 — в самый раз.

В общем, установил я Оперу 12 и на ноуте стало намного легче работать, да и признаюсь интерфейсом мне всегда нравилась Opera 12, даже по сравнению с современными браузерами. Но вот незадача — Opera всеми любимая, настолько старая, что сертификаты какие-то там уже просрочены, или что-то вроде этого.

Постоянно выскакивают окошки, что мол сертификат просрочен и нужно его вручную вам принять. При этом такие окошки чуть ли не каждый сайт «посылает» вам, и их все больше и больше.. В общем, не долго думая я завершил процесс Оперы, и потом снова запустил ее и начал быстро искать способ решения этой проблемы, чтобы эти всплывающие окна не успели загрузить полностью мой ноутбук.

Решение есть, вот смотрите что нужно сделать чтобы отключить проверку сертификатов в Opera 12:

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

Отключение проверки защищенных соединений снизит уровень защиты компьютера.

Если вы не хотите, чтобы программа «Лаборатории Касперского» показывала сообщение о проблеме с сертификатом, отключите проверку защищенного соединения:

1. Чтобы узнать, как открыть программу, смотрите инструкцию в статье .

1. Перейдите в раздел Дополнительно и выберите Сеть .

1. Выберите опцию Не проверять защищенные соединения .

1. Ознакомьтесь с предупреждением и нажмите Продолжить .

Проверка защищенных соединений будет выключена.

Какие есть перспективы?

Очевидный вывод из всего сказанного ранее: проверки статуса сертификатов в браузерах не работают, и это не новость. При этом просто взять и перейти на

hard fail

нельзя по объективным причинам.

Есть ли применимое на практике решение данной проблемы? Проанализировав и собрав воедино множество уже предложенных частичных решений данной проблемы (в частности расширение сертификатов «TLS feature», сертификаты с коротким сроком действия, агрегаторы CRL и др., о чём подробно будет рассказано ниже), предлагаем вашему вниманию наше представление о том, как проверка статуса сертификатов должна происходить на практике.

В основе лежит утверждение о том, что не для всех сервисов требуется онлайн-проверки статуса сертификатов. Для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски, связанные с атакой «человек посередине» с использованием отозванных сертификатов. Иначе говоря, с точки зрения проверки статуса сертификатов, сервисы делятся на два типа:

1. Меньшинство, для которого будут проводиться строгие онлайн-проверки статуса сертификатов в режиме hard fail.2. Большинство, для которого онлайн-проверки статуса сертификатов не будут выполняться вовсе (будут предприниматься другие меры по защите).

Браузеры могут различать такие сервисы по наличию специального расширения в сертификате сервера. В зависимости от типа сервиса клиент либо будет выполнять «параноидальную» проверку статуса сертификатов, либо не будет выполнять её вовсе. Теперь подробнее о каждой из этих двух схем.

Криптопро revocation provider

В операционных системах семейства Microsoft Windows встроена поддержка технологии Инфраструктуры открытых ключей. Многие приложения, работающие под управлением этих ОС, используют интерфейс CryptoAPI для осуществления функций криптографической защиты информации.

По умолчанию приложения, использующие CryptoAPI, осуществляют проверку статусов сертификатов с использованием списков отозванных сертификатов (СОС). СОС представляет собой список недействительных сертификатов, издаваемый периодически – например, раз в неделю.

СОС не отражает информацию о статусах сертификатов в реальном времени, а также имеет ряд других недостатков, которых лишён протокол OCSP – протокол получения статуса сертификата в реальном времени. Режим установления статуса сертификатов по умолчанию реализован в модуле ОС – Microsoft Revocation Provider.

Но архитектура CryptoAPI предоставляет возможность подключения и внешних модулей проверки статуса сертификата. Таковым и является продукт “КриптоПро Revocation Provider”, который предназначен для встраивания проверки статусов сертификатов открытых ключей в режиме реального времени по протоколу OCSP в операционные системы семейства Microsoft Windows.

Схема встраивания “КриптоПро Revocation Provider” в операционные системы семейства Microsoft Windows представлена на рисунке:

Основные характеристики “КриптоПро Revocation Provider”:

Загрузить “КриптоПро Revocation Provider”.

Криптопро вставлен другой носитель: как исправить

Ошибка «Вставьте ключевой носитель» или «Вставлен другой носитель» возникает при попытке подписания электронного документа. Сначала следует убедиться, что USB-токен с сертификатом подключен к ПК (в качестве носителя используются защищенные криптоключи или обычные флешки).

1. Открыть меню «Пуск» → «Панель управления» → «КриптоПро CSP».
2. Зайти во вкладку «Сервис» → «Посмотреть сертификаты в контейнере» → «Обзор».
3. Выбрать из списка ключевой контейнер, нажать ОК и «Далее».
4. Нажать «Установить». Если появится предупреждение о том, что сертификат уже присутствует в хранилище, дать согласие на его замену.
5. Дождаться загрузки сертификата в хранилище «Личное» и нажать ОК.

После переустановки рекомендуется перезагрузить ПК. Для первичной инсталляции СКПЭП применим аналогичный алгоритм действий.

Настройка шаблона ca

Итак, для начала нам потребуется установленный в сети Certification Authority под управлением Windows Server 2008 (любой редакции, кроме Web). По умолчанию с добавлением роли  AD CS добавляется и служба Online Respnder. Для этого так же потребуется установить службы IIS, о чём мастер вам сообщит и предложит сделать.

fig.1

Данный шаблон характеризуется следующими свойствами:

• срок действия сертификата составляет 2 недели
• на вкалдке Request Handlings добавлено право чтения приватного ключа для службы Network Service, поскольку служба OCSP работает от лица Network Service, а не LocalSystem (для LocalSystem отдельных разрешений не требуется)
• шаблон не содержит CDP и AIA расширений
• шаблон помечен как неподлежащий для проверки на отзыв (см. fig.1)

На вкладке Security необходимо для учётной записи компьютера, на котором размещён OCSP выдать право Allow Read и Allow Enroll. Это единственное изменение, которое необходимо выполнить для шаблона. Теперь нужно открыть оснастку Certificate Authority и добавить этот шаблон для выдачи:

правой кнопкой на Certificate Templates –> New –> Certificate Template to Issue –> OSCP Response Signing. Далее нужно создать оснастку Certificates для учётной записи компьютера и запросить сертификат на основе этого шаблона с компьютера, где установлен OCSP Responder.

После запроса сертификата не стоит закрывать оснастку Certificates, а выбрать новый сертификат и в All Tasks выбрать Manage Privete keys. В открывшемся окне Permissions выдайте право Read для учётной записи Network Service:

fig.2

Перечень мероприятий, которые необходимо выполнить для подключения к гиис «электронный бюджет»

1. Подготовка информационно-технологической инфраструктуры к подключению к подсистемам системы “Электронный бюджет”

1.1. Обеспечить наличие у сотрудников квалифицированных сертификатов ключей проверки электронных подписей

Для входа в личный кабинет и работы в ГИИС «Электронный бюджет» требуется действующий квалифицированный сертификат электронной подписи физического лица, выданный аккредитованным
Минкомсвязью удостоверяющим центром (далее – личный сертификат).

В случае если у сотрудников уже есть личный сертификат, полученный в Удостоверяющем центре Федерального казначейства, например для работы на СУФД-портале, то дополнительно сертификат изготавливать не требуется.

1.2. Получить в органе Федерального казначейства средств криптографической защиты информации (далее – СКЗИ), обеспечивающие создание защищенного соединения с подсистемами системы “Электронный бюджет” : «КриптоПро CSP», «Jinn-client» и «eXtended Container (XC)».

Для получения СКЗИ, лицензионных ключей и эксплуатационной документации к СКЗИ необходимо руководствоваться письмом Управления №79-12-15/15-301 от 06.02.2021г.

1.3. Настройка рабочего места.

Причины возникновения ошибок ssl-соединения

Когда сертификат работает корректно, адресная строка браузера выглядит примерно так:

Но при наличии ошибок она выглядит несколько иначе:

Существует множество причин возникновения таких ошибок. К числу основных можно отнести:

• Некорректную дату и время на устройстве (компьютер, смартфон, планшет и т.д.);
• Ненадежный SSL-сертификат;
• Брандмауэр или антивирус, блокирующие сайт;
• Включенный экспериментальный интернет-протокол QUIC;
• Отсутствие обновлений операционной системы;
• Использование SSL-сертификата устаревшей версии 3.0;
• Появление ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера.

Давайте рассмотрим каждую из них подробнее.

Причины появления сообщения

• Сертификат может быть отозван. Например, по заявлению владельца, если его сайт взломали.
• Сертификат выписан нелегально. Сертификат должен быть получен в удостоверяющем центре после прохождения проверки.
• Нарушена цепочка сертификатов. Сертификаты проверяются по цепочке от самоподписанного до доверенного корневого сертификата, который предоставляет удостоверяющий центр. Промежуточные сертификаты предназначены для подписания (подтверждения) другого сертификата в цепочке.
  Причины, по которым может быть нарушена цепочка сертификатов:
  • Цепочка состоит из одного самоподписанного сертификата. Такой сертификат не заверяется удостоверяющим центром и может быть опасен.
  • Цепочка не завершается доверенным корневым сертификатом.
  • Цепочка содержит сертификаты, не предназначенные для подписывания других сертификатов.
  • Истекло или не наступило время действия корневого или промежуточного сертификата. Удостоверяющий центр выдает сертификат на определенный период времени.
  • Цепочка не может быть выстроена.
• Домен в сертификате не соответствует сайту, с которым устанавливается соединение.
• Сертификат не предназначен для подтверждения подлинности узла. Например, сертификат предназначен только для шифрования соединения между пользователем и сайтом.
• Нарушены политики использования сертификата. Политика сертификата — набор правил, определяющий использование сертификата с заданными требованиями безопасности. Каждый сертификат должен соответствовать хотя бы одной политике сертификата. Если их приведено несколько, сертификат должен удовлетворять всем политикам.
• Нарушена структура сертификата.
• Возникла ошибка при проверке подписи сертификата.

Сертификат истек: чем это грозит на практике?

Как вы знаете, срок действия SSL-сертификатов является ограниченным. Это требование CA/B Forum, регулирующего органа индустрии SSL-сертификации. Несколько лет назад вполне легально можно было заказать трехлетние, четырехлетние или даже пятилетние SSL-сертификаты.

Это ведет к тому, что SSL-сертификат нужно обновлять или заменять – либо каждый год, либо раз в 2 года.

При посещении сайта пользовательский браузер выполняет проверку достоверности SSL-сертификата. Если срок действия сертификата истек, то в таком случае браузер выдаст следующее предупреждение:

Естественно, все это чревато следующими негативными последствиями:

• Трафик вашего сайта кардинально упадет. Как показывают исследования, пользователи, столкнувшиеся с подобным уведомлением, тут же закрывают сайт. Лишь малая часть всех посетителей принимает истекший сертификат.
• Продажи сильно снизятся. Поскольку сайт выдает предупреждение, пользователи могут посчитать, что ресурс является небезопасным, а потому не станут совершать покупки, даже если делали их на этом же сайте ранее.
• Показатели ранжирования сайта сильно упадут. В ближайшей перспективе ваш сайт будет постепенно сваливаться вниз в поисковой выдаче, так как поисковые роботы учитывают многие факторы, в том числе и поведение посетителей. 

Истечение сертификата грозит катастрофическими последствиями для любого бизнеса. Если вы являетесь клиентом LeaderSSL, то вы можете обезопасить себя от подобных чрезвычайных ситуаций.

Схема для большинства

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

hard fail

, не окупают риски связанные с атакой «человек посередине» с использованием отозванных сертификатов. В таком случае лучше не защищаться от данной атаки, а максимально сократить временной промежуток, в течение которого проведение данной атаки будет возможным. Для этого используются сертификаты с коротким сроком действия (например, 1-2 дня).

Таким образом, большинство сервисов будет использовать сертификаты без расширения «TLS Feature», но с коротким сроком действия. Для таких сертификатов онлайн-проверки статуса сертификатов не будут выполняться вовсе. Вместо этого будет проводиться частое обновление быстро устаревающих сертификатов.

Добавим, что использование сертификатов с коротким сроком действия эквивалентно использованию сертификатов с расширением «TLS Feature», обязывающим использовать прикреплённые OCSP-ответы, вместе с прикреплёнными OCSP-ответами, не защищёнными от атаки повторного воспроизведения (т.е.

Подход с использованием сертификатов с коротким сроком действия обладает целым рядом достоинств, однако малопригоден для сертификатов УЦ. Для проверки статуса таких сертификатов можно использовать периодически обновляемые чёрные списки аналогичные «CRLSets» и «OneCRL», но предоставляющие пользователям больший контроль на агрегаторами CRL.

Пользователи, например, должны иметь возможность добавлять новые опрашиваемые точки распространения CRL. Это важно, поскольку некоторые организации разворачивают собственные не публичные УЦ для внутреннего использования. Решением может стать возможность использования приватных агрегаторов CRL.

Сервер отзыва сертификатов недоступен

И так давайте опишу ситуацию, есть у нас в компании для своих внутренних нужд Цент сертификации, развертывал я его на Windows Server 2008 r2 и мы с вами его уже даже лечили от ошибки Не найдены шаблоны сертификатов. Вы не имеете прав запрашивать сертификат на этом ЦС.

В один из дней пишет мой коллега и говорит, что у него не стартует служба, так как он был загружен, он попросил посмотреть, что там. И так заходим на сервер с Windows Server 2008 r2 и в пункте администрирование открываем оснастку Центр Сертификации.

Попытавшись из оснастки запустить его, выскочила ошибка уже с кодом, что уже хорошо так как можно понять причину и как следствие найти решение.

Если зайти в просмотр событий в журнал Приложения, то сможете найти сообщение с кодом события 48, который вам выдаст туже ошибку.

Как видите все они ругаются на недоступность сертификата в цепочке сертификатов, CRL, или как его еще называют списка отозванных. Открываем пуст и вводим mmc, для открытия оснастки. (Я уже рассказывал как создать мега мощную и удобную консоль mmc, почитайте будет очень полезно)

Нажимаем CTRL M для добавления оснастки.

Вам нужно добавить две оснастки

• PKI предприятия
• Учетной записи компьютера

Выбираем локальный компьютер, так как мы сейчас на центре сертификации.