Сертификат выдан не доверенным центром сертификации. VGimly: Сертификаты RDP. Что такое промежуточный сертификат

Успешно решил намедни проблемку с терминалами. Может кому ещё пригодится, да и мне в случае, например, амнезии будет полезно вспомнить:)

Суть проблемки в следующем. Имеются сервера терминалов на windows 7 (а теперь уже и win8 попадаются - а может даже это же решение и для серверных версий подойдёт).
То есть соединения по протоколу Remote Desktop Protocol (RDP) версий 7 и 8 (бинарник версий 6.1 и 6.2 соответственно) к службе "Удалённый рабочий стол" (remote desktop services).
Теперь соединение с ними требует наличия сертификата у сервера и его проверка у клиента.
Сервер автоматически создаёт самоподписанный сертификат при подключении к нему (или если его "нечаянно" удалить).
Но при этом у клиентов в момент подключения выдаётся предупреждение "Не удается проверить подлинность удаленного компьютера: Сертификат выдан не имеющим доверия центром сертификации" - благо пока отключаемое. У серверов на Windows XP такой проблемы нет - но клиенты в XP уже ругается.
Не то, чтобы это была такая уж Проблема - так - мелкое неудобство. Но особо комфортной Ежедневную Работу не делает. Особенно администратору - который по несколько раз в день да к разным машинам цепляется..

Итак. Нужно заменить сертификаты у "серверов" на "правильные".
Как сделать "правильные" сертификаты - отдельная песня - отдельным постом.
Делал через openssl + EasyRSA (1.0 - или 2.0 что идёт в комплекте с openvpn - но пришлось слегка допиливать - но главное разобраться с конфигами - хех).
Вполне вероятно, что средствами MS (тем же certutil или GUI каким) можно было бы получить ключики куда проще, но зато слегка копнул эту x509 - теперь чуть лучше понимаю цели танцев с бубном ключами для openvpn.. Одних CA не считая промежуточных центров сертификатов пока с ними разобрался сколько понаделал:)
Можно (и желательно) получать сертификаты от доверенных сторонних центров сертификации - но они и за денюжку - и по-учиться на сертификатах не дадут.

Продолжим. В процессе кейгенеза должны получить следующие вещи:

1. Сертификат самопального CA в формате x509/CER/base64 - пусть им будет файлик ca.crt .


2. pkcs12/pfx ключик сервера с EKU "remote desktop connection" или "TLS server" подписанный сертификатом, который проверяется через вышеупомянутый CA - им будет файлик test.p12 с паролем "qwe " - хеш ключа - 01:23:..:cd:ef .
3. HTTP сервер, отдающий промежуточные, корневые сертификаты и отзывы на них (crl).
   Без этого пункта работать RDP без ругани не получилось заставить - так что заранее планируйте; благо хватит какого-нибудь mangoose - ибо нашему CA требуется пока лишь отдавать мелкие статичные файлы и достаточно редко.

Всё последующее требует административной консоли (с повышенными правами) на подопытном сервере.

1. Засовываем корневой сертификат в хранилище доверенных корневых сертификатов. Это просто - используем штатную системную утилиту:
   

   certutil -addstore root ca.crt

2. Засовываем ключ сервера в персональное хранилище (но "локального компьютера").
   Тут есть нюанс. При простом импорте ключа - он может поместиться в личное хранилище пользователя - да ещё и с неправильными правами. При продвинутом импорте - через mmc и оснастку "Сертификаты/Локальный компьютер" - потребуется давать права на доступ к закрытому ключу для Network Service - от имени которого работает termserv - опять же много буков и картинок потребуется, чтобы это всё описать. Самое простое найденное решение - через утилитку WinHttpCertCfg.exe - из состава .
   

   WinHttpCertCfg -a NetworkService -c LOCAL_MACHINE\MY -i test.p12 -p qwe

   Да, если ключик таки уже импортировали как-то по-другому, можно дать правильные права командой:
   WinHttpCertCfg.exe -a NetworkService -c LOCAL_MACHINE\MY -g -s SUBJ
   где SUBJ это сабжект ключа - чтобы утилита его смогла найти - и скорее всего он будет совпадать с именем компьютера - достаточно указать %COMPUTERNAME% .
3. Заставляем терминал сервер отдавать наш ключ, вместо самоподписанного. Просто нужно указать хеш нужного ключа в реестре. Перезапуска сервиса а тем более компьютера не потребуется.
   

   reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SSLCertificateSHA1Hash /t REG_BINARY /d 0123456789..DEF

Ну Вот, собственно, и Всё. При следующем подключении - клиент не получит уведомления о неправильном сертификате сервера. Можно снова включать уведомления об этом кошмаре или даже запрещать соединяться с такими серверами.
Не правда ли, Всё очень просто?

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

Какие преимущества дает нам защита RDP при помощи SSL? Во первых надежное шифрование канала, проверку подлинности сервера на основании сертификата и проверку подлинности пользователя на уровне сети. Последняя возможность доступна начиная с Windows Server 2008. Проверка подлинности на уровне сети позволяет повысить безопасность сервера терминалов за счет того, что проверка происходит еще до начала сеанса.

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

Для полноценного использования всех возможностей RDP через SSL клиентские ПК должны работать под управлением Windows XP SP3, Windows Vista или Windows 7 и использовать RDP клиент версии 6.0 или более поздней.

При использовании Windows Server 2003 SP1 и более поздних версий, будут доступны шифрование канала при помощи SSL (TLS 1.0) и проверка подлинности сервера, клиентские ПК должны иметь версию RDP клиента 5.2 или более позднюю.

В нашей статье мы будем рассматривать настройку терминального сервера на базе Windows Server 2008 R2, однако все сказанное будет справедливо и для Windows Server 2003 (за исключением отсутствующих возможностей).

Для успешной реализации данного решения в вашей сети должен находиться работающий центр сертификации, настройку которого мы рассматривали в . Для доверия сертификатам выданным данным ЦС на терминальный сервер необходимо установить сертификат ЦС (или цепочку сертификатов) в хранилище .

Затем следует выполнить запрос сертификата подлинности сервера со следующими параметрами:

Имя - полное имя терминального сервера (т.е. server.domain.com если сервер входит в домен domain.com)

• Тип сертификата - Сертификат проверки подлинности сервера
• Установите опцию Создать новый набор ключей
• CSP - Microsoft RSA SChannel Cryptographic Provider .
• Установите флажок Пометить ключ как экспортируемый .
• Для ЦС предприятия установите флажок Использовать локальное хранилище компьютера для сертификата . (В автономном ЦС данная опция недоступна).

Отправьте запрос центру сертификации и установите выданный сертификат. Данный сертификат должен быть установлен в локальное хранилище компьютера, иначе он не сможет быть использован службами терминалов. Чтобы проверить это запустим консоль MMC (Пуск - Выполнить - mmc ) и добавим оснастку Сертификаты (Файл - Добавить или удалить оснастку ) для учетной записи компьютера.

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

Если вы получали сертификат с помощью изолированного (автономного) ЦС (сеть не имеет доменной структуры) то он по умолчанию будет установлен в хранилище учетной записи пользователя и придется выполнить ряд дополнительных действий.

Откройте Internet Explorer - Свойства обозревателя - Содержимое - Сертификаты , выданный сертификат должен быть установлен в хранилище Личные .

Произведите его экспорт. При экспорте укажите следующие опции:

• Да, экспортировать закрытый ключ
• Удалить закрытый ключ после успешного экспорта

После чего удалите сертификат из данного хранилища. В оснастке Сертификаты (локальный компьютер) выберите раздел Проверка подлинности сервера , щелкните на него правой кнопкой мыши Все задачи - Импорт и импортируйте сертификат.

Теперь в Администрирование - Службы удаленных рабочих столов откройте Конфигурация узла сеансов удаленных рабочих столов (в Windows Server 2003 Администрирование - Настройка служб терминалов).

Выберите необходимое подключение и откройте его свойства. В самом низу нажмите кнопку Выбрать и выберите полученный на предыдущем шаге сертификат (в Windows Server 2003 это окно выглядит несколько по другому).

После выбора сертификата укажите остальные свойства:

• Уровень безопасности SSL
• Уровень шифрования Высокий или FIPS -совместимый
• Установите флажок Разрешить подключаться только с компьютеров... (недоступно в Windows Server 2003)

Сохраните введенный параметры, на этом настройка сервера закончена.

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

Чтобы данный ПК доверял сертификатам выданным нашим центром сертификации не забудьте установить на него сертификат ЦС в хранилище Доверенные корневые центры сертификации .

В Windows 7 (при использовании RDP клиента версии 7) данный сертификат требуется установить в хранилище учетной записи компьютера , для этого импортируйте его через оснастку Сертификаты (локальный компьютер) в консоли MCC, аналогично тому, как это делали выше. В противном случае подключение будет невозможно и вы получите следующую ошибку:

Установив сертификат ЦС можете пробовать подключиться, обратите внимание, что имя пользователя и пароль будет предложено ввести еще до создания RDP сессии. При успешном соединении обратите внимание на замок в заголовке окна, который свидетельствует о работе через SSL. Нажав на него можно просмотреть информацию о сертификате.

И напоследок капля дегтя в бочке меда. Терминальные службы Windows не умеют проверять подлинность подключающихся клиентов, поэтому если стоит такая необходимость следует использовать дополнительные методы защиты, такие как SSH туннель или IPSec VPN.

Чем более интегрированной, сложной и защищенной становится инфраструктура на Windows Server, тем больше она полагается в добавок к традиционной Active Directory на PKI (Public Key Infrastructure, переводят как инфраструктура открытого ключа) для обеспечения доверительных отношений и проверки подлинности между компьютерами, пользователями и службами. Active Directory Certificate Services — это реализация PKI от Microsoft, которая состоит из следующих элементов:

• Центр сертификации (ЦС, Certification Authority), корневой и подчиненные
• отношения всеобщего доверия к ЦС
• выдаваемые ЦС сертификаты для компьютеров, пользователей и служб
• различные службы поддержки PKI
  • списки отзывов сертификатов (CRL)
  • сетевой ответчик (Online Responder, более прогрессивная альтернатива CRL)
  • Web Enrollment (средство запроса сертификатов через Web)

Автоматический запрос сертификатов

Ручная установка сертификата корневого ЦС

Если в среде Active Directory и локальной сети доверие к корневому центру сертификации настраивается автоматически, то для доверия к ЦС со стороны недоменных удаленных компьютеров необходимо установить сертификат ЦС в их хранилище Доверенные корневые центры сертификации. Иначе либо будут выдаваться предупреждения о потенциальной опасности подписанного неизвестно кем сертификата, либо вообще соединения с таким сервером будут отклонятся, как, например, в случае с Remote Desktop Services Gateway будет выдаваться такая ошибка:

Компьютеру не удаётся проверить удостоверение шлюза удалённых рабочих столов "server.argon.com.ru". Подключаться к серверам без удостоверений небезопасно. This computer can"t verify the identity of the RD "server.argon.com.ru". It"s not safe to connect to servers that can"t be identified. Этот сертификат не удалось проверить, проследив его до доверенного центра сертификации

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

Через MMC

Через свойства сертификата

Запустить командную строку с правами админа » вызвать в ней с:\path\to\cert.crt » откроется окно свойств сертификата » нажать кнопку Установить » отметить галку Показывать физические хранилища » выбрать хранилище для установки сертификата Доверенные корневые центры сертификации » Локальный компьютер.

Через командную строку

Потребуется утилита CertMgr , с помощью нее нужно выполнить следующую команду:

certmgr.exe -add -c "с:\path\to\cert.crt" -s -r localMachine root

Проверка отзыва сертификатов

Некоторые сетевые службы (удаленные рабочие столы, DirectAccess, L2TP и SSTP VPN), которые используют сертификаты для проверки подлинности сервера, требуют проверки этих сертификатов на легитимность (но отозваны ли они центром сертификации). В окружении локальной сети с такими проверками проблем не возникает, так как списки отзыва сертификатов опубликованы в Active Directory и по локальным адресам центра сертификации.

Ситуация меняется, если легитимность сертификата пытаются проверить из интернета, где, естественно, ни Active Directory, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:

Не удалось проверить, не был ли отозван этот сертификат. A revocation check could not be perfomed for the certificate.

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

• CRL (Certificate Revocation List, список отзыва сертификатов) на веб-сервере, регулярно обновляемый
• Online Responder (сетевой ответчик, доступный начиная с Windows Server 2008 редакции Enterprise), который функционирует примерно также, как и предыдущий вариант, но по более прогрессивному протоколу OCSP (но через HTTP)

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

За инструкциями по настройки ЦС для размещения CRL в интернете обращайтесь к статье TechNet Configuring Certificate Revocation . От себя лишь замечу хитрость: если ваш домен имеет доступное из интернета DNS-имя (то есть argon.com.ru, а не argon.local), а на сервер с корневым ЦС установлена опция Web Enrollment, то ЦС уже настроен на публикацию своих CRL по адресу http://server.argon.com.ru/CertEnroll. Поэтому для полноценной работы CRL достаточно просто опубликовать в интернете порт HTTP по доменному имени server.argon.com.ru.

Настройка и публикация Online Responder немного сложнее, но подробно описана в статьях TechNet Online Responder и Setting Up Online Responder Services in a Network . Тут уже никаких хитростей и настроек по умолчанию нет, честно устанавливаете роль на нужный сервер, конфигурируете эту роль, публикуете HTTP-сайт в интернете и настраиваете ЦС на включение информации об Online Responder’e в публикуемые сертификаты.

Проверить правильность функционирования проверки отзыва (CRL или OCSP) любого сертификата можно с помощью следующей команды:

certutil -url name.cer

где name.cer — имя выданного сертификата.

Следует иметь ввиду, что проверка отзыва по протоколу OCSP проходит успешно только в том случае, если сертификат ЦС, выдавшего проверяемый сертификат, установлен в хранилище доверенных сертификатов локального компьютера.

Веб-службы регистрации сертификатов

Они же Certificate Enrollment Web Services, если по-английски. Весьма полезная роль, которая позволяет:

• запрашивать сертификаты пользователями без участия администратора
• предоставлять по требованию сертификат корневого ЦС
• выполнять особые уже подготовленные запросы (Custom Request), например для веб-серверов под управлением Linux или других сетевых устройств
• делать это все через интернет
• сам Web Enrollment может работать на отличном от ЦС компьютере, что повышает безопасность корневого ЦС

Установка и настройка Web Enrollment проста и тривиальна за исключением следующих моментов

• в случае установки Web Enrollment на отличный от ЦС компьютер, необходимо обязательно выполнить шаги, описанные в статье TechNet Configuring Delegation Settings for the Certificate Enrollment Web Service Account , иначе служба не будет работать, выдавая следующую ошибку:

Произошла непредвиденная ошибка: Служба центра сертификации (ЦС) не запущена. An unexpected error has occurred: The Certification Authority Service has not been started.

• та же ошибка будет выдаваться, если Web Enrollment работает на одном сервере с ISA Server / Forefront TMG, в их системных правилах нужно отключить Enforce strict RPC compliance и разрешить протокол RPC во внутреннюю сеть.
• при публикации Web Enrollment в интернете необходимо включить требование работы через SSL для веб-приложения CertSrv в консоли IIS

Запрос сертификата с альтернативным именем

Насущный вопрос при публикации внутренних служб предприятия в интернете — создание сертификатов со списком альтернативных имен DNS (Subject Alternative Name, SAN).

По умолчанию ЦС на Windows Server не настроен на выдачу сертификатов, содержащих SAN. Чтобы включить эту функцию на компьютере с ЦС нужно выполнить:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

Запрос через консоль MMC

Начиная с Windows Server 2008 появилась возможность запросить сертификат с SAN через MMC-консоль Сертификаты, для этого…

• В консоли управления ЦС для шаблона сертификата Веб-сервер назначить права на запрос и чтение для учетки компьютера, запрашивающего сертификат.
• Компьютер, с которого создается запрос, должен входить в домен, в котором опубликован ЦС
• Создать запрос по шаблону веб-сервера → в свойствах запроса указать список альтернативных DNS-имен на вкладке Субъект → Дополнительное имя → DNS.

Запрос через утилиту certreq

Более гибким и универсальным способом запроса сертификатов с SAN является следующий, использующий утилиту certreq . Чтобы создать сертификат нужно действовать по следующему алгоритму:

1. Подготовить текстовый файл request.inf запроса сертификата со следующим содержанием.

Signature="$Windows NT$"

Subject = "CN=server.argon.local, OU=IT, O=Argon, L=Kirov, S=Kirovskaya, C=RU"
KeySpec = 1
KeyLength = 2048
HashAlgorithm = SHA256
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0xa0
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
FriendlyName = "server.argon.local with SAN"

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

CertificateTemplate = WebServer

2.5.29.17 = "{text}"
_continue_ = "DNS=*.argon.com.ru&"
_continue_ = "DNS=argon.com.ru&"
_continue_ = "DNS=server.argon.local&"
_continue_ = "DNS=server&"
_continue_ = "DNS=localhost"

2. На машине, для которой предполагается запрашивается сертификат, выполнить команду

certreq -new request.inf

3. Отправить запрос центру сертификации и получить в ответ.cer файл. Для этого можно воспользоваться MMC-конcолью управления Certification Authority (и указать.req файл) либо Web Enrollment (в окно расширенного запроса вставить содержимое.req файла и выбрать шаблон веб-сервера).

4. Выполнить установку полученного сертификата на целевой компьютер следующей командой

certreq -accept request.cer

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

Обобщенные лучшие практики

Приведу пример рациональной реализации PKI на предприятии для поддержки передовых служб Windows Server 2008 R2

• На контроллере домена развернут корневой центр сертификации
• Если организации велика, то создано несколько подчиненных ЦС, выделенных для определенных целей (по назначению сертификата, по филиалу организации, для распределения нагрузки…)
• В групповых политиках настроено доверие к корневому ЦС и автоматический запрос сертификатов доменный компьютеров
• На пограничном компьютере-члене домена развернуты и опубликованы с помощью Forefront TMG в интернете службы:
  • Web Enrollment для установки сертификата ЦС и запроса личных сертификатов с недоменных компьютеров
  • Online Responder для проверки отзыва сертификатов по протоколу OCSP
• Опубликованы в интернете с использованием сертификатов с SAN следующие сетевые службы, опирающиеся на использование сертификатов и проверку их отзыва:
  • Remote Desktop Gateway
  • Outlook Web Access
  • DirectAccess
  • SharePoint

Полезные ссылки

• Устанавливаем Certification Authority — Vadims Podans’s blog
• OCSP (часть 1) , OCSP (часть 2) — Vadims Podans’s blog

Доброго дня!

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

С одной стороны это хорошо (все-таки и браузер, и вообще популяризация подобных сертификатов - обеспечивает нашу безопасность), но с другой - подобная ошибка иногда всплывает даже на очень известных сайтах (на том же Google).

Суть происходящего, и что это значит?

Дело в том, что когда вы подключаетесь к сайту, на котором установлен протокол SSL, то сервер передает браузеру цифровой документ (сертификат ) о том, что сайт является подлинным (а не фейк или клон чего-то там...). Кстати, если с таким сайтом все хорошо, то браузеры их помечают "зеленым" замочком: на скрине ниже показано, как это выглядит в Chrome.

Однако, сертификаты могут выпускать, как всем известные организации (Symantec, Rapidssl, Comodo и др.) , так и вообще кто-угодно. Разумеется, если браузер и ваша система "не знает" того, кто выпустил сертификат (или возникает подозрение в его правильности) - то появляется подобная ошибка.

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

Ну а в этой статье я хочу указать на несколько способов устранения подобной ошибки, если она стала появляться даже на белых и известных сайтах (например, на Google, Яндекс, VK и многих других. Их же вы не откажетесь посещать?).

Как устранить ошибку

1) Обратите внимание на адрес сайта

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

Пример ошибки "Сертификат безопасности сайта не является доверенным"

Однако, отмечу, что если ошибка появляется на очень известном сайте, которому вы (и многие другие пользователи) всецело доверяете - то высока вероятность проблемы в вашей системе...

2) Проверьте дату и время, установленные в Windows

Второй момент - подобная ошибка может выскакивать, если у вас в системе неверно задано время или дата. Для их корректировки и уточнения достаточно щелкнуть мышкой по "времени" в панели задач Windows (в правом нижнем углу экрана). См. скрин ниже.

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

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

3) Попробуйте провести обновление корневых сертификатов

Еще один вариант, как можно попробовать решить эту проблему - установить обновление корневых сертификатов. Обновления можно скачать на сайте Microsoft для разных ОС. Для клиентских ОС (т.е. для обычных домашних пользователей) подойдут вот эти обновления:

4) Установка "доверенных" сертификатов в систему

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

Для избавления от ошибки, связанной с недостоверностью сертификата, должен подойти спец. пакет GeoTrust Primary Certification Authority .

Кстати, чтобы скачать GeoTrust Primary Certification Authority:

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

5) Обратите внимание на антивирусные утилиты

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

Поэтому, если у вас установлен антивирус/брандмауэр, проверьте и на время отключите настройку сканирования https трафика (см. пример настроек AVAST на скрине ниже).

На этом у меня всё...

За дополнения по теме - отдельное мерси!

Всего доброго!