Не удается проверить сертификат. Проверка подлинности цифровых сертификатов в инфраструктуре Windows PKI

Сайт Яндекс не открывается. Сертификат сайта не является доверенным

На некоторых ПК в домене Яндекс открывался с ошибкой сертификата сайта:

"Этот сертификат не удалось проверить, проследив его до доверенного центра сертификации".

Люди недовольны, да и неправильно это.

А у корневого сертификата, во вкладке "Путь сертификации", в свойствах сертификата видно, кто виноват. Это корневой сертификат центра сертификации Certum. У него такое сообщение об ошибке:

"нет доверия к этому корневому сертификату центра сертификации"

Соответственно, помогло добавление корневого сертификата центра сертификации, который выдал сертификат Яндексу.

Сам сертификат - вот он . В свойствах сертификатов был указан серийный номер сертификата корневого - 010020, такой же у того, что указан выше.

Помимо вышеописанного случая, причиной такого поведения может быть зараза. Так, что стоит проверить ПК на вирусы антивирусным сканером. Например - drweb cure it . И бывают параноидальные антивирусы, проверяющие соединения - отключение проверки сертификатов может помочь в этом случае.

tagPlaceholder Tags: Яндекс , Сертификаты , Корневые , CertumCA , 2016

Обеспечение гарантий подлинности сертификатов в среде Windows

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

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

Процедуры сличения

В процессе проверки подлинности сертификата для него выполняются процедуры сличения по следующим критериям: цифровая подпись (digital signature), параметры отношений доверия (trust), временные параметры (time), информация об аннулировании сертификата (revocation) и параметры формата (formatting). Если выясняется, что сертификат не соответствует требованиям хотя бы одного из этих критериев, то он считается недействительным. При сличении цифровой подписи программа проверки подлинности с помощью заслуживающего доверия открытого ключа проверяет подлинность цифровой подписи, добавленной в сертификат выдавшим его центром Certificate Authority (CA). В качестве ключа используется открытый ключ выдавшего сертификат центра CA либо другого центра, входящего в цепочку сертификатов в соответствии с иерархической моделью доверительных отношений.

Для проверки подлинности подписи недостаточно просто наличия открытого ключа, он должен быть заслуживающим доверия. В инфраструктурах PKI систем Windows Server 2003 и Windows 2000 Server сертификат и открытый ключ заслуживающего абсолютного доверия центра CA называются трастовыми якорями (trust anchor), а доступ к ним осуществляется через контейнер Trusted Root Certification Authorities хранилища сертификатов клиента Windows PKI. В процессе сличения параметров доверительных отношений производится аутентификация сертификата доверенных CA - эту процедуру также называют проверкой подлинности цепочки сертификатов. При выполнении данной процедуры для каждого сертификата цепочки могут запускаться различные циклы проверки подлинности. Подробнее процедура проверки подлинности цепочки сертификатов будет рассмотрена ниже.

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

Во время выполнения процедуры сличения срока действия (revocation check) проверяется, не аннулирован ли данный сертификат выдавшим его центром CA. В средах PKI систем Windows 2003 и Windows 2000 Server реализована поддержка работы с абсолютными списками аннулированных сертификатов (complete CRL) и узлами распространения списков CRL (CRL Distribution Point, CDP). Помимо этого, служба Windows 2003 Certificate Services может работать и со списками изменений (delta CRL). Используя списки CRL, списки изменений CRL и узлы CDP, можно обеспечить проверку срока действия сертификатов в автоматическом режиме. Более подробно вопросы, связанные с аннулированием сертификатов, рассмотрены в статье , опубликованной в журнале Windows IT Pro/RE № 4 за 2006 г.

При выполнении процедуры сличения параметров форматирования проверяется, соответствует ли формат сертификата стандартным требованиям, определенным в рекомендации X.509, выпущенной комитетом International Telecommunications Union Telecom- munication Standardization Sector (ITU-T). При этом также проверяется корректность расширений сертификата, описывающих параметры доверительных отношений с регулируемой степенью доверия, таких как базовые ограничения, ограничения имен, ограничения политик приложений и ограничения политик выдачи. Более подробно эти расширения описаны в статье , опубликованной в Windows IT Pro № 7 за 2006 г. Например, большая часть приложений, работающих с Secure MIME (S/MIME), проверяет подлинность параметра сертификата subject’s name, описанного в Internet Engineering Task Force (IETF) Request for Comments (RFC) 822 (по сути дела, это стандартное имя в формате адресов почты Internet, скажем, [email protected]). Для этого значение данного параметра сравнивается с полем адреса отправителя в заголовке сообщения SMTP. В случае S/MIME такая проверка обеспечивает защиту от возможного заимствования прав (impersonation) и от атак типа man-in-the-middle. При проведении подобных атак злоумышленник обычно пытается отождествить себя с реальным пользователем, чтобы получить доступ к системе или сети. Сходные типы проверок выполняются и в большинстве реализаций Secure Sockets Layer (SSL). Протокол SSL проверяет соответствие параметра subject’s RFC 822 name имени, находящемуся в поле URL того защищенного Web-сайта, к которому обращается клиент.

Стандартная процедура обработки цепочки сертификатов

Что такое цепочка сертификатов и почему ее следует обрабатывать в процессе проверки подлинности сертификата? С помощью построения цепочки можно организовать проверку подлинности всех сертификатов, с которыми связан данный сертификат. Для того чтобы разобраться в том, что представляет собой цепочка сертификатов, обратимся к иерархической модели доверительных отношений в инфраструктуре PKI. В данной модели (которая также обсуждалась в упомянутой выше статье «Принципы доверия PKI») цепочка сертификатов каждого пользователя состоит из сертификатов всех центров CA, которые образуют в пределах данной иерархии путь от пользователя до корневого (root) центра CA. При использовании иерархической модели доверительных отношений каждый сертификат содержит указатель на родительский (или выдавший сертификат) центр CA, который хранится в поле issuer сертификата X.509. На рис. 1 показан пример цепочки для пользовательского сертификата, выданного центром CA при наличии двухуровневой иерархии в инфраструктуре PKI. Рис. 1 иллюстрирует простейший пример использования параметров certificate subject (субъект) и certificate issuer (издатель сертификата). В данном примере субъектом пользовательского сертификата является пользователь, а издателем сертификата - промежуточный центр CA. В сертификате промежуточного центра субъектом является сам этот центр, издателем же в данном случае будет корневой CA. В иерархической модели доверительных отношений корневой центр CA всегда сам подписывает свой сертификат, поэтому для своего сертификата он является как субъектом, так и издателем сертификата.

Обработка цепочки выполняется программой проверки подлинности сертификатов. Данный процесс разделяется на две составляющие: построение цепочки сертификатов и проверка ее подлинности.

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

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

Для идентификации сертификата центра CA во время процедуры проверки подлинности цепочки используется расширение Authority Key Identifier (AKI) проверяемого сертификата. В поле AKI содержится информация следующих типов.

  • Имя центра, выдавшего сертификат и серийный номер сертификата данного центра. Если эта информация имеется в поле AKI, тогда программа проверки подлинности выполняет поиск совпадающего сертификата, используя поля Serial number и Subject. Данный метод идентификации сертификата называется строгим совпадением.
  • Идентификатор открытого ключа (KeyID) сертификата центра, выдавшего проверяемый сертификат. Если эта информация имеется в поле AKI, тогда программа проверки подлинности выполняет поиск совпадающего сертификата, используя расширение сертификата Subject Key Identifier (SKI), в котором хранится уникальный идентификатор открытого ключа сертификата субъекта. Данный метод идентификации сертификата называется совпадением ключей.

Если в проверяемом сертификате поле AKI отсутствует, программа проверки подлинности пытается идентифицировать сертификат выдавшего центра CA с помощью проверки совпадения имени, взятого из поля Issuer проверяемого сертификата, с содержимым поля Subject сертификата. Данный метод идентификации сертификата называется совпадением имен.

В тех случаях когда проверяемый сертификат недоступен локально, имеющиеся в Windows программные средства проверки подлинности используют расширение Authority Information Access (AIA), с тем чтобы получить копию сертификата путем его загрузки по сети с соответствующего узла. Для этого используется поле AIA, которое содержит указатель на узел хранения сертификатов центров CA для протоколов FTP, HTTP, Lightweight Directory Access Protocol (LDAP) или указатель на соответствующий файловый ресурс. Если поле AIA содержит несколько ссылок, программные средства проверки подлинности пытаются задействовать все эти ссылки в порядке их перечисления в данном поле. Все сертификаты, которые загружаются с использованием поля AIA, кэшируются программой проверки в профиле пользователя PKI на локальном диске (а именно в папке Documents and SettingsusernameLocal SettingsTemporary Internet Files), а также в локальном хранилище сертификатов пользователя.

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

Просмотреть цепочку, относящуюся к конкретному сертификату, можно с помощью закладки Certification Path диалогового окна свойств сертификата, которое показано на экране. Чтобы получить доступ ко всем своим сертификатам, необходимо запустить оснастку Certificates консоли MMC, а для доступа к свойствам отдельного сертификата дважды щелкнуть на соответствующем сертификате в списке, выводимом данной оснасткой.

Если при загрузке сертификата используется Web-интерфейс центра CA систем Windows 2003 или Windows 2000 Server, то в этом случае можно выбрать загрузку только самого сертификата либо загрузку данного сертификата совместно со всеми сертификатами, образующими цепочку. Возможность загрузки цепочки сертификатов иногда бывает весьма полезной, например если для работы используется переносной компьютер. В этом случае все сертификаты цепочки будут доступны для программы проверки подлинности даже тогда, когда пользователь находится в дороге.

Обработка цепочки списков CTL

Данная процедура представляет собой особый случай обработки цепочек сертификатов. Список CTL содержит заверенный перечень сертификатов, заслуживающих абсолютного доверия корневых центров CA, следовательно, здесь содержатся сертификаты центров CA, подписанные ими самими. Формирование списка CTL выполняется через выпадающее меню контейнера объекта групповой политики Enterprise Trust Group Policy Object. Доступ к данному контейнеру осуществляется последовательным выбором Windows SettingsSecurity SettingsPublic Key Policies. Объекты GPO также выполняют автоматическую загрузку списков CTL в контейнер Enterprise Trust хранилища содержимого сертификатов. Отметим, что контейнер Enterprise Trust не является контейнером трастовых якорей - его содержимое не считается заслуживающим абсолютного доверия по умолчанию.

Для того чтобы список CTL и его содержимое считались заслуживающими доверия, сертификат, с помощью которого подписывался этот список, должен быть действительным. Следовательно, данный сертификат должен полностью удовлетворять требованиям проверки процедурами сличения по всем рассмотренным выше параметрам (цифровая подпись, параметры отношений доверия, временные параметры, информация об аннулировании сертификата и параметры формата). Гарантией успешной проверки цифровой подписи служит наличие сертификата из контейнера Trusted Root Certification Authorities в цепочке того сертификата, который использовался для подписи сертификата списка CTL. Как уже говорилось выше, определить, является ли цепочка сертификатов составной частью действительного списка CTL, можно путем просмотра каждого из сертификатов цепочки с помощью закладки Certification Path окна свойств сертификата.

Обработка цепочки кросс-сертификатов

Кросс-сертификация - это новая возможность установления отношений доверия, появившаяся в инфраструктуре PKI среды Windows 2003 (подробнее она рассмотрена в статье «Принципы доверия PKI»). В отличие от списков CTL, кросс-сертификация позволяет устанавливать детальные отношения доверия в PKI между различными инфраструктурами центров CA. При установлении доверительных отношений через кросс-сертификацию между двумя центрами CA, входящими в инфраструктуры различных организаций, каждый из этих центров становится одновременно как родительским, так и подчиненным, при этом в процессе построения цепочек сертификатов наблюдаются весьма интересные эффекты.

На рис. 3 показано, как работают доверительные отношения на базе кросс-сертификации и как это отражается на свойствах сертификатов. Доверительным отношениям между инфраструктурами CA в данном случае соответствует связь, показанная в виде стрелки, которая направлена на левую половину рисунка. В рассматриваемом примере имеют место односторонние отношения доверия между OrgВ и OrgA. При этом подчиненный центр SubCA выдал кросс-сертификат центру HPCA (корневому центру сертификации организации OrgA), что позволяет пользователям OrgB доверять сертификату с именем Administrator, выданному центром HPCA. Иначе говоря, в данной схеме пользователи организации OrgB напрямую доверяют центру RootCA, а также центру SubCA, поскольку от него до RootCA построена цепочка сертификатов. Кроме того, они доверяют и центру HPCA (так как SubCA выдал ему кросс-сертификат), а следовательно, доверяют сертификату Administrator, выданному центром HPCA.

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

Жан де Клерк ([email protected] ) - член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасности в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press)

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

О сертификатах

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

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

Причины

Причин, по которым возникает ошибка, несколько:

  1. Срок действия сертификата закончился. В этом случае вовремя не произошло обновление, поэтому и появилась неисправность.
  2. На компьютере сбилось время. Неверно выставленные дата и время могут вызвать конфликт правильно настроенных сертификатах.
  3. Подмена данных. Каждый интернет ресурс имеет собственный сертификат. Opera выявит не доверенный (поддельный), если какой-либо фишинговый сайт попытается провести подмену.
  4. Вредоносное ПО на компьютере. Возможно, ваш ПК заражен вредоносным кодом. Он может подменять ссылку, по которой вы переходите. Из этого злоумышленники могут извлечь выгоду. Также вирусы могут попросту нарушить стабильную работу, как Opera, так и операционной системы Windows в целом.

Как устранить?

Если подобная ошибка возникает часто, проверьте ее наличие в других интернет обозревателях. Также:

  1. Проверьте настройку даты. Важно, чтобы она была выставлено правильно (Настройки → Время и язык → Дата и время → Установить время автоматически или пропишите его вручную).
  2. Убедитесь, что ваш компьютер не заражен. Воспользуйтесь бесплатными сканерами

Когда вы открываете браузер, то планируете, что всё будет в обычном режиме. Но что делать, если компьютер не хочет работать как надо? И сообщает, что сертификат сервера недействителен? В этом случае вам необходимо проверить, как всё работает, всё ли правильно выставлено, и нет ли каких-то проблем. Можно увидеть это сообщение на крупных сайтах (недействительный сертификат сервера Google, "ВКонтакте"), которые просто не могут допустить такую оплошность.

Что это значит?

Для начала: зачем используется данное обозначение? Что это значит, когда компьютер сообщает, что представленный сервером сертификат недействителен? Таким образом, компьютер говорит, что электронные документы сайта, которые он предоставил, имеют какую-то неточность, благодаря чему у машины есть основание для сомнений относительно его подлинности или полноценности функционирования. Данная проблема может возникнуть как из-за неполадок со стороны сервера, так и из-за неточностей на ЭОМ пользователя. Если рассматривать первую версию, то тут может быть такое:

  1. Неполадка с сайтом центра сертификации. Все эти подтверждения выдают специальные организации. И как любой другой, они не застрахованы от возможных проблем вроде террористов, землетрясения, оползней, повреждения линий передач и многих других проблем. Но это случается крайне редко, и уповать на данный пункт особо не приходится.
  2. Проблемы с сайтом вследствие технических неполадок или умышленного вреда. Здесь тоже может пойти что-то не так. Системный администратор что-то не то нажал или злоумышленники ведут атаку сервера, результат один - сертификат сервера недействителен. Но это тоже редко случается.

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

  1. Неправильно установленное время.
  2. Проблема с программным обеспечением, предназначенным для просмотра Всемирной сети.

И как же устранить данные проблемы? Вот этому вопросу сейчас и будет уделено внимание.

Настройка времени

Самая популярная причина. Если на компьютере стоит неверное время или дата, то когда происходит получение всех файлов, машина видит, что параметры не совпадают, и информирует пользователя, что сертификат сервера недействителен. Это всё делается с целью обезопасить человека, который выходит в интернет, и не допустить потери важных для него данных. Исправить данную проблему очень легко - для этого достаточно всего лишь исправить время на и час, и данной проблемы не будет. На этот случай приходится приблизительно 95% подобных происшествий.

Убираем проверку сертификата

Что делать, если проблема не во времени, а в чем-то другом? И что бы вы ни делали, сертификат сервера недействителен и в таком статусе и остается? И при этом доступ к данным следует получить срочно? Что ж, если нет времени искать истинную причину, то можно поступить просто и эффективно - всего лишь отключить проверку сертификата. Для этого необходимо перейти в настройки своего браузера, затем зайти в раздел безопасности и совершить необходимые действия (более конкретный план напрямую зависит от используемой программы). И компьютер не сможет заблокировать доступ к сайту, потому что сертификат сервера недействителен. Но совершайте данные действия относительно только тех сетевых ресурсов, которым вы доверяете.

Заключение

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

Доброго дня!

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

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

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

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

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