Не удается построить цепочку сертификатов для доверенного корневого центра

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

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

. Отсутствие

hard fail

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

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

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

Что такое ssl?

SSL (Secure Socket Layer) — это интернет-протокол для создания зашифрованного соединения между пользователем и сервером, который гарантирует безопасную передачу данных.

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

SSL-сертификатыЗащита сайтов любого уровняот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-ответа может быть достаточно велик. Нередко он бывает равен неделе.

Брандмауэр или антивирус, блокирующие сайт

Некоторые сайты блокируются брандмауэром Windows. Для проверки можно отключить брандмауэр и попробовать зайти на нужный сайт. Если SSL-сертификат начал работать корректно, значит дело в брандмауэре. В браузере Internet Explorer вы можете внести некорректно работающий сайт в список надежных и проблема исчезнет.

Включенный экспериментальный протокол quic

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

Показываем как отключить QUIC на примере браузера Google Chrome:

• Откройте браузер и введите команду chrome://flags/#enable-quic;
• В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.

• После этого просто перезапустите браузер.

Этот способ работает и в Windows и в Mac OS.

Детали уязвимости

Исследователь Eduardo Braun Prado из команды Zero Day Initiative

уязвимость локального повышения привилегий в компоненте Windows Certificate Dialog, которая возникает из-за некорректной обработки пользовательских привилегий. Уязвимость позволяет повысить привилегии пользователя до максимально возможных SYSTEM и обойти все защитные механизмы ОС Windows.

В чем суть уязвимости? Сертификат исполняемого файла содержит необязательное численное поле «Идентификатор политики» в формате Microsoft-specific object identifier (OID).

Заголовочный файл Wintrust.h определяет это поле как SPC_SP_AGENCY_INFO_OBJID. Хотя его назначение слабо документировано, скорее всего, оно анализируется при открытии окна с деталями сертификата. При представлении данного поля в корректном формате поле Issued by («Кем выдано») будет отображено в виде гиперссылки со значением, взятым из атрибута SpcSpAgencyInfo.

При клике по ссылке c полем Issued by откроется браузер Internet Explorer с правами SYSTEM. Родительским процессом для него будет выступать процесс consent.exe. Он также выполняется с максимальными привилегиями, и именно в его контексте запускается диалог UAC.

В качестве PoC для демонстрации эксплуатации уязвимости (видео приведено ниже) исследователь предложил использовать утилиту HTML Help ActiveX Control, сертификат которой обладает описанными выше особенностями.

При этом существует возможность подписать любой исполняемый файл подобным образом, например, с помощью powershell командлета Set-AuthenticodeSignature. Предварительно потребуется создать самоподписанный сертификат корневого удостоверяющего центра и конечный сертификат средствами утилиты makecert из набора Windows SDK. Инструкция приведена по ссылке.

Уязвимость получила идентификатор CVE-2021-1388 и CVSS 7.8. Ей оказались подвержены все версии ОС от Windows 7 до Windows Server 2021. После установки патча поле Issued by в деталях сертификата перестает отображаться как гиперссылка.

Массовая эксплуатация этой уязвимости маловероятна ввиду трудности автоматизации. Ведь для реализации атаки на ее основе пользователю потребуется выполнить немало действий — от открытия окна с сертификатом исполняемого файла до запуска командной строки через интерфейс Internet Explorer. Поэтому наиболее вероятный сценарий атаки может быть связан с действиями внутреннего нарушителя.

Использование ssl-сертификата версии 3.0

Некоторые сайты используют устаревший SSL-протокол версии 3.0, который не поддерживают браузеры. По крайней мере, по умолчанию. Чтобы браузер поддерживал устаревший SSL необходимо сделать следующее (на примере браузера Google Chrome):

• Откройте браузер и перейдите в раздел «Настройки».
• Прокрутите страницу настроек вниз и нажмите «Дополнительные».
• В разделе «Система» найдите параметр «Настройки прокси-сервера» и кликните на него.

• Откроется окно. Перейдите на вкладку «Дополнительно».
• В этой вкладке вы увидите чекбокс «SSL 3.0».

• Поставьте галочку в чекбоксе, нажмите кнопку «Ок» и перезагрузите браузер.

Как защититься

1. Установить патч Microsoft от 12 ноября для соответствующей версии ОС.

2. Если патч для устранения данной уязвимости установить нельзя, стоит воспользоваться:

Как обнаружить

Для обнаружения эксплуатации уязвимости на платформах Windows x64 мы в Jet CSIRT используем в SIEM-системе правило корреляции, отслеживающее цепочку событий (на контролируемом узле предварительно необходимо включить аудит запуска процессов посредством соответствующей групповой политики либо использовать утилиту Sysmon от Sysinternals):

1. Детектирование запуска процесса constent.exe с правами SYSTEM (код события 4688).
2. Детектирование запуска процесса C:Program Filesiexplore.exe с правами SYSTEM, где в качестве родительского процесса выступает consent.exe.
3. Детектирование запуска процесса C:Program Files (x86)iexplore.exe с правами SYSTEM, где в качестве родительского процесса выступает C:Program Filesiexplore.exe.

   

4. Детектирование запуска командного интерпретатора (cmd.exe, powershell.exe) с правами SYSTEM, где в качестве родительского процесса выступает C:Program Files (x86)iexplore.exe.

   

5. ID процесса C:Program Files (x86)iexplore.exe из п.3 и ID C:Program Files (x86)iexplore.exe в качестве родительского процесса из предыдущего пункта совпадают.

Приведем пример описанного корреляционного правила на стороне FortiSIEM.

Используемые условия

Детализация условия запуска consent.exe

Детализация условия запуска IEx64

Детализация условия запуска IEx86

Детализация условия запуска cmd.exe, powershell.exe

<rules><DataRequest advanced="true" custId="1" type="Rule">
<Name>UAC Privilege Escalation through Secure Desktop</Name>
<Description>Повышение привилегий через UAC Secure Desktop CVE-2021-1388</Description>
<Remediation/>
<CustomerScope groupByEachCustomer="true">
<Include>1</Include>
<Exclude/>
</CustomerScope>
<PatternClause window="300">
<SubPattern id="148021654" name="Consent_Execution">
<SingleEvtConstr>eventType = "Win-Security-4688"  AND  procName CONTAIN "consent.exe"  AND  user IN ("СИСТЕМА","SYSTEM")</SingleEvtConstr>
<GroupEvtConstr>COUNT(*) >= 1</GroupEvtConstr>
<GroupByAttr>user,procName</GroupByAttr>
</SubPattern>
<Operator rank="0" type="FOLLOWED_BY"/>
<SubPattern id="148021655" name="IE_x64_Execution">
<SingleEvtConstr>eventType = "Win-Security-4688"  AND  procName REGEXP (".*Files\\Internet.*\\iexplore\.exe$")  AND  parentProcName CONTAIN "consent.exe"  OR  user IN ("СИСТЕМА","SYSTEM")</SingleEvtConstr>
<GroupEvtConstr>COUNT(*) >= 1</GroupEvtConstr>
<GroupByAttr>procId,user,parentProcName,procName</GroupByAttr>
</SubPattern>
<Operator rank="0" type="FOLLOWED_BY"/>
<SubPattern id="148021664" name="IE_x86_Execution">
<SingleEvtConstr>eventId = 4688  AND  procName REGEXP (".*\(x86\)\\.*\\iexplore\.exe$")  AND  parentProcName REGEXP (".*Files\\Internet.*\\iexplore\.exe$")  AND  user IN ("СИСТЕМА","SYSTEM")</SingleEvtConstr>
<GroupEvtConstr>COUNT(*) >= 1</GroupEvtConstr>
<GroupByAttr>procName,parentProcName,procId,user</GroupByAttr>
</SubPattern>
<Operator rank="0" type="FOLLOWED_BY"/>
<SubPattern id="148021656" name="Cmd_Execution">
<SingleEvtConstr>eventType = "Win-Security-4688"  AND ( procName CONTAIN "cmd.exe"  OR  procName CONTAIN "powershell.exe" ) AND  parentProcName REGEXP (".*\(x86\)\\.*\\iexplore\.exe$")  AND  user IN ("СИСТЕМА","SYSTEM")</SingleEvtConstr>
<GroupEvtConstr>COUNT(*) >= 1</GroupEvtConstr>
<GroupByAttr>user,parentProcName,procName,parentProcId</GroupByAttr>
</SubPattern>
<GlobalConstr>IE_x86_Execution.procId = Cmd_Execution.parentProcId</GlobalConstr>
</PatternClause>
<IncidentDef eventType="UAC_Privilege_Escalation_through_Secure_Desktop" eventTypeGroup="PH_SYS_EVENT_PH_RULE_SEC" fireFreq="900" severity="7">
<ArgList>procName=Cmd_Execution.procName,parentProcName=Cmd_Execution.parentProcName,user=Cmd_Execution.user</ArgList>
</IncidentDef>
<DynWatchListDef/>
<userRoles>
<roles custId="0"></roles>
</userRoles>
<TriggerEventDisplay>
<AttrList>phRecvTime,eventType,reptDevName,reptDevIpAddr,destIpAddr,destName,user,parentProcId,parentProcName,procId,procName,rawEventMsg</AttrList>
</TriggerEventDisplay>
</DataRequest>
</rules>

Исследователь Florian Roth

Sigma-правило для обнаружения попытки эксплуатации данной уязвимости. Однако из-за ограничений языка с помощью правила можно выявлять только событие запуска Internet Explorer с правами SYSTEM и родительским процессом consent.exe без последующего детектирования запуска командных интерпретаторов.

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

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

hard fail

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

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

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

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

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

Нарушение прав доступа к ветке реестра.

Решить эту проблему так же поможет полное удаление КриптоПРО CSP с использованием указанной ранее утилиты по очистке следов программы.

Если не поможет, то попробуйте предоставить пользователю, работающему с КриптоПРО CSP, права администратора.

Не работают алгоритмы шифрования криптопро csp

Открываем КриптоПРО CSP и переходим на вкладку “Алгоритмы”.Если увидите, что поля алгоритмов пустые значит программа работает некорректно. Переустановите КриптоПРО CSP.

Некорректный путь сертификации

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

Чтобы устранить ошибку “Этот сертификат содержит недействительную подпись” необходимо восстановить всю цепочку сертификации, установив в хранилище сертификаты всех промежуточных УЦ и Головного удостоверяющего центра.

Открываем хранилище сертификатов при помощью консоли certmgr.msc

Переходим в Личное/Сертификаты. Открываем сертификат, который не работает и переходим на вкладку Путь сертификации.

Как видно на рисунке в качестве корневого удостоверяющего центра указан “Минкомсвязь России”, а промежуточного удостоверяющего центра ООО “КОМПАНИЯ “ТЕНЗОР”.

В поле состояние сертификата наблюдаем ошибку: “Этот сертификат содержит недействительную подпись”.

Теперь нам надо отследить всю цепочку сертификатов, которая содержит промежуточные сертификаты и сертификат головного удостоверяющего центра.

Вернемся на вкладку “Общие”, чтобы проверить кем выдан личный сертификат. Сертификат выдан той же организацией, что указана в пути сертификации в качестве промежуточно центра. Здесь все правильно.

Переходим в Промежуточные центры сертификации и проверяем промежуточный сертификат. Здесь видно сообщение “Этот сертификат не удалось проверить, проследив его до удостоверяющего центра сертификации”. Вот то место где обрывается путь.

Отсутствие обновлений операционной системы

Проблемы с SSL-сертификатами могут возникать и из-за того, что на вашей операционной системе давно не устанавливались обновлений. Особенно это касается устаревших версий Windows (7, Vista, XP и более ранние). Установите последние обновления и проверьте работу SSL.

Ошибка "сертификат безопасности сайта не является доверенным". как ее исправить?

Ошибки «invalid csr» при генерации сертификата из панели управления облачного провайдера

В процессе активации сертификата можно столкнуться с ошибкой «Invalid CSR». Такая ошибка возникает по следующим причинам:

Параноидальная схема проверки статуса сертификатов для меньшинства

В 2021 году вышла спецификация нового расширения сертификатов стандарта X.509, называемого

(на ранних этапах разработки стандарта также известное, как «OCSP must staple»). Это расширение сертификата позволяет зафиксировать в сертификате те опции протокола TLS, которые TLS-сервер, предъявляющий данный сертификат, обязуется поддерживать. Такой опцией протокола TLS в частности являются прикреплённые OCSP-ответы. Пример сертификата с таким расширением схематически изображён ниже:

В сертификате присутствует расширение «TLS Feature» (выделено красным), сообщающее о том, что TLS-сервер обязан поддерживать прикреплённые OCSP-ответы, специфицированные в RFC 6066 («Status Request (Version 1)»), и более новую версию данной опции («Status Request (Version 2)»), специфицированную в RFC 6961 — множественные прикреплённые OCSP-ответы. Новая версия данной опции протокола TLS позволяет прикреплять OCSP-ответы и для сертификатов промежуточных УЦ.

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

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

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

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

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

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

Причины ошибки в цепочке сертификатов

Ошибки могут возникать по разным причинам — проблемы с Интернетом на стороне клиента, блокировка программного обеспечения Защитником Windows или другими антивирусами. Далее, отсутствие корневого сертификата Удостоверяющего Центра, проблемы в процессе криптографической подписи и другие.

Проблемы с датой и временем

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

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

Проверка корневого сертификата уц в браузере

Проверку можно выполнить в браузере.

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

Теперь попробуйте снова выполнить те действия, в процессе которых возникла ошибка. Чтобы получить корневой сертификат, необходимо обратиться в соответствующий центр, где вы получили СКП ЭП.

Проверки статуса сертификатов, реализованные в веб-браузерах

Механизмы проверки статуса сертификатов, реализованные в современных Веб браузерах, представляют собой комбинацию описанных

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

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

Закрытый ключ сервера был скомпрометирован. Владелец сервера отозвал сертификат скомпрометированного ключа, сгенерировал новую пару ключей и получил новый сертификат.Нарушитель завладел отозванным закрытым ключом и сертификатом сервера. В данном сценарии мы намеренно не говорим, каким образом он это осуществил: в результате компрометации самого сервера или в результате компрометации удостоверяющего центра (УЦ). Это сделано для того, чтобы продемонстрировать, как браузеры поведут себя в обеих ситуациях.

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

Веб-браузер клиента при попытке установки TLS-соединения с сервером подключается к «человеку посередине». «Человек посередине» представляется сервером, используя отозванный сертификат без прикреплённого OCSP-ответа (a.k.a. OCSP stapling).

Нарушитель блокирует запросы, идущие от клиента ко всем OCSP-серверам и точкам распространения CRL (a.k.a. CDP). Также нарушитель блокирует попытки клиента обновить Веб-браузер или его компоненты (например, чёрные списки «CRLSets» или «OneCRL», речь о которых пойдёт позже).

Блокирование «человеком посередине» запросов ко всем OCSP-серверам и точкам распространения CRL, во-первых, поддерживает начальное условие, согласно которому нарушитель мог скомпрометировать, как сервер, так и УЦ, и, во-вторых, наиболее полно демонстрирует проверки статуса сертификатов, выполняемые современными браузерами.

Ниже приводится описание проверок статуса сертификатов, выполняемых различными Веб-браузерами под Windows. Для других платформ детали проверок могут незначительно отличаться.

Прочие браузеры и платформы

Для других популярных браузеров и платформ ситуация такая же: везде проверки статуса сертификатов выполняются в режиме

soft fail

, либо не выполняются вовсе. Подробнее можно почитать

или

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

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

hard fail

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

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

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

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

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

Установка криптопро

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

Перед установкой программы на свой компьютер, все ваши токены должны быть извлечены. Браузер должен быть настроен на работу, исключением является браузер Opera, в нем уже произведены все настройки по умолчанию. Единственное, что остается пользователю — это активировать специальный плагин для работы. В процессе вы увидите соответствующее окно, где Opera предлагает активировать этот плагин.

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

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

В некоторых случаях для электронной подписи используют дополнительные утилиты — КриптоПро Office Signature и КриптоАКМ. Можно устранить ошибку — нет возможности построить цепочку сертификатов для доверенного корневого центра — простой переустановкой КриптоПро. Попытайтесь это сделать, если другие советы не помогли.

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

Устранение ошибки при создании создания цепочки сертификатов для доверенного корневого центра

В первую очередь убедитесь, что у вас нет проблем с интернет-подключением. Ошибка может появляться при отсутствии доступа. Сетевой кабель должен быть подключен к компьютеру или роутеру.