Проверка цепочки сертификатов windows

Sometimes it is needed to verify a certificate chain. This can be done very easy with the certutil.

To do that download/export at first the certificate and place at on your local hard disk. We use use here the certificate from https://www.google.de. If you have done that open a CMD box and run the following command (adjust the folder and filename if needed):

certutil -f -urlfetch -verify C:\temp\www.google.de.crt

and you got a similar result like this one here:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Users\adminenclave>certutil -f -urlfetch -verify C:\temp\www.google.de.crt
Issuer:
    CN=Google Internet Authority
    O=Google Inc
    C=US
Subject:
    CN=www.google.de
    O=Google Inc
    L=Mountain View
    S=California
    C=US
Cert Serial Number: 2ffc6a42000000006b55
dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)
dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)
dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=Google Internet Authority, O=Google Inc, C=US
  NotBefore: 10.10.2012 19:13
  NotAfter: 07.06.2013 21:43
  Subject: CN=www.google.de, O=Google Inc, L=Mountain View, S=California, C=US
  Serial: 2ffc6a42000000006b55
  SubjectAltName: DNS Name=www.google.de
  f9 e1 65 66 c1 af a3 a5 94 4b 9c 93 e1 80 00 91 ac 82 32 ab
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Certificate AIA  ----------------
  Verified "Certificate (0)" Time: 0
    [0.0] http://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority
.crt
  ----------------  Certificate CDP  ----------------
  Verified "Base CRL (013a)" Time: 0
    [0.0] http://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority
.crl
  ----------------  Base CRL CDP  ----------------
  No URLs "None" Time: 0
  ----------------  Certificate OCSP  ----------------
  No URLs "None" Time: 0
  --------------------------------
    CRL 0137:
    Issuer: CN=Google Internet Authority, O=Google Inc, C=US
    73 08 39 25 6a 7c 40 c0 a3 21 2e 66 aa 59 e0 4e 16 26 84 b8
  Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
  NotBefore: 08.06.2009 22:43
  NotAfter: 07.06.2013 21:43
  Subject: CN=Google Internet Authority, O=Google Inc, C=US
  Serial: 0b6771
  dd 7a 7f 13 1d db a3 3d 3e 86 70 17 94 83 e6 fe a6 98 7d 6a
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Certificate AIA  ----------------
  No URLs "None" Time: 0
  ----------------  Certificate CDP  ----------------
  Verified "Base CRL" Time: 0
    [0.0] http://crl.geotrust.com/crls/secureca.crl
  ----------------  Base CRL CDP  ----------------
  No URLs "None" Time: 0
  ----------------  Certificate OCSP  ----------------
  No URLs "None" Time: 0
  --------------------------------
    CRL (null):
    Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
    81 0b 00 58 1f 86 7c 16 75 71 48 29 07 97 4f da c7 7a 52 78
  Application[0] = 1.3.6.1.5.5.7.3.4 Secure Email
  Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication
  Application[2] = 1.3.6.1.5.5.7.3.3 Code Signing
CertContext[0][2]: dwInfoStatus=10a dwErrorStatus=0
  Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
  NotBefore: 22.08.1998 18:41
  NotAfter: 22.08.2018 18:41
  Subject: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
  Serial: 35def4cf
  d2 32 09 ad 23 d3 14 23 21 74 e4 0d 7f 9d 62 13 97 86 63 3a
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Certificate AIA  ----------------
  No URLs "None" Time: 0
  ----------------  Certificate CDP  ----------------
  Failed "CDP" Time: 0
    Error retrieving URL: Logon failure: unknown user name or bad password. 0x80
07052e (WIN32: 1326)
    ldap:///CN=CRL1, OU=Equifax Secure Certificate Authority, O=Equifax, C=US?ce
rtificateRevocationList;binary,authorityRevocationList;binary,deltaRevocationLis
t;binary
  ----------------  Certificate OCSP  ----------------
  No URLs "None" Time: 0
  --------------------------------
  Application[0] = 1.3.6.1.5.5.7.3.4 Secure Email
  Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication
  Application[2] = 1.3.6.1.5.5.7.3.3 Code Signing
Exclude leaf cert:
  c9 55 8d 60 10 7b 30 7a 6e 00 f7 47 f1 2e ce f1 96 da c4 90
Full chain:
  85 bf 47 43 a6 99 12 37 4c 31 d6 1e 18 4f b6 74 4d 34 31 ab
------------------------------------
Verified Issuance Policies: None
Verified Application Policies:
    1.3.6.1.5.5.7.3.1 Server Authentication
Cert is an End Entity certificate
ERROR: Verifying leaf certificate revocation status returned The revocation func
tion was unable to check revocation because the revocation server was offline. 0
x80092013 (-2146885613)
CertUtil: The revocation function was unable to check revocation because the rev
ocation server was offline.
CertUtil: -verify command completed successfully.

Обеспечение гарантий подлинности сертификатов в среде 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 PKI», опубликованной в журнале Windows IT Pro/RE № 4 за 2006 г.

При выполнении процедуры сличения параметров форматирования проверяется, соответствует ли формат сертификата стандартным требованиям, определенным в рекомендации X.509, выпущенной комитетом International Telecommunications Union Telecom- munication Standardization Sector (ITU-T). При этом также проверяется корректность расширений сертификата, описывающих параметры доверительных отношений с регулируемой степенью доверия, таких как базовые ограничения, ограничения имен, ограничения политик приложений и ограничения политик выдачи. Более подробно эти расширения описаны в статье «Принципы доверия PKI», опубликованной в Windows IT Pro № 7 за 2006 г. Например, большая часть приложений, работающих с Secure MIME (S/MIME), проверяет подлинность параметра сертификата subject’s name, описанного в Internet Engineering Task Force (IETF) Request for Comments (RFC) 822 (по сути дела, это стандартное имя в формате адресов почты Internet, скажем, jan.declercq@hp.com). Для этого значение данного параметра сравнивается с полем адреса отправителя в заголовке сообщения 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 всегда сам подписывает свой сертификат, поэтому для своего сертификата он является как субъектом, так и издателем сертификата.

Картинка с сайта: www.osp.ru

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

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

Картинка с сайта: www.osp.ru

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

Жан де Клерк (jan.declercq@hp.com) — член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасности в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press)

Ошибка: «Не удается построить цепочку сертификатов для доверенного корневого центра. (0x800B010A)»  часто возникает в различных приложениях при создании/проверке подписи. Она означает, что у Вас на машине не установлены необходимые промежуточные/корневые сертификаты для проверкисоздания подписи.

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

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

Шаг 1

Скачайте этот файл. Файл содержит корневые сертификаты всех основных УЦ. Подробный список дан ниже.   

Шаг 2

Если у Вас на компьютере установлен КриптоПро CSP 5.0

Для ОС Windows: Зайдите Пуск-Все программы-КРИПТО-ПРО- Инструменты КриптоПро

Для MAC OS: Зайдите Finder-Программы-Инструменты

Перейдите на вкладку Сертификаты и выберите вверху раздел «Доверенные корневые центры сертификации»

Картинка с сайта: support.cryptopro.ru

Выберите кнопку «Установить сертификаты», выберите скачанный ранее файл и нажмите «Открыть»

Если у Вас на компьютере установлен КриптоПро CSP версии ниже 5.0 или Вы не используете графический интерфейс:

Для Windows: выполните в командной строке:

«C:\Program Files\Crypto Pro\CSP\certmgr.exe» -install -cert -store uRoot -file  <путь к файлу> -all

Для Linux/macOS: выполните в командной строке:

/opt/cprocsp/bin/amd64/certmgr -install -cert -store uRoot -file  <путь к файлу> -all

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

Скачайте этот файл. Файл содержит промежуточные сертификаты рекомендуемых УЦ.

Если Вы используете CSP 5.0 с графическим интерфейсом, то выполните Шаг 2, выбрав хранилище «Промежуточные центры сертификации», используя файл CA.p7s

Если Вы используете КриптоПро CSP версии ниже 5.0 или Вы не используете графический интерфейс, то используйте данные команды:

Для Windows: выполните в командной строке:

«C:\Program Files\Crypto Pro\CSP\certmgr.exe» -install -cert -store uCA -file  <путь к файлу> -all

Для Linux выполните в командной строке:

/opt/cprocsp/bin/amd64/certmgr -install -cert -store uCA -file  <путь к файлу> -all

Для MACOS выполните в командной строке:

/opt/cprocsp/bin/certmgr -install -cert -store uCA -file  <путь к файлу> -all

Списки сертфикатов, содержащихся в файлах root.p7b, ca.p7b:

Root

CA

1. Автоматическая установка.

Выбрать меню «Пуск» («Настройки») > «Панель управления» > «Свойства обозревателя» («Свойства браузера»). Перейти на вкладку «Содержание» и нажать на кнопку «Сертификаты».

Картинка с сайта: uc-itcom.ru

Выбираем сертификат.

Картинка с сайта: uc-itcom.ru

Если видим ошибку не удалось проверить этот сертификат, значит цепочка сертификата была потеряна.

Для восстановления цепочки сертификатов, скачиваем наше приложение по ссылки,

Далее запускаем наше приложение certs.exe.

В открывшемся окне нажимаете кнопку установить.

Картинка с сайта: uc-itcom.ru

После это перезагрузите компьютер. 

Далее переходим в сертификаты, при открывании вашего сертификата должно уйти сообщение об ошибке.

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

Выбрать меню «Пуск» («Настройки») > «Панель управления» > «Свойства обозревателя» («Свойства браузера»). Перейти на вкладку «Содержание» и нажать на кнопку «Сертификаты».

Картинка с сайта: uc-itcom.ru

Выбираем сертификат.

Картинка с сайта: uc-itcom.ru

Если видим ошибку не удалось проверить этот сертификат, значит цепочка сертификата была потеряна.

Выбираем вкладку «Путь сертификации» и откройте тот сертификат, который выделен красным крестом.

В открывшемся окне необходимо выбрать «Установить сертификат».

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

Картинка с сайта: uc-itcom.ru

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

Картинка с сайта: uc-itcom.ru

В появившемся окне необходимо выбрать куда установить сертификат, есть критерии установки, если:

• Ошибка на 1 сертификате цепочки, выбираем для установки «Доверенные корневые центры сертификации»

Картинка с сайта: uc-itcom.ru

• Ошибка на 2 сертификате цепочки, выбираем для установки «Промежуточные центры сертификации»

Картинка с сайта: uc-itcom.ru

После выбора куда устанавливать сертификат нажимаем «ОК», нажимаем «Далее», затем «Готово».
Соглашаемся со всеми «Предупреждениями системы безопасности».

Завершающим этапом появится сообщение «Импорт успешно выполнен», вернитесь к вкладке «Путь сертификации», обновите ее и проверьте, что ошибка прошла.

3. Если установка корневых сертификатов не решило проблему

Необходимо выполнить следующее:

Выбрать меню «Пуск» («Настройки») > «Панель управления» > «Программы» («Удаление программы»).

Картинка с сайта: uc-itcom.ru

Выбираем КриптоПро CSP и нажать на кнопку «Изменить»> выбираем «Исправить» и нажать на кнопку «Далее»> «Установить»>Готово.

Картинка с сайта: uc-itcom.ru

Выбираем «Исправить» и нажать на кнопку «Далее»> «Установить»>Готово.

Картинка с сайта: uc-itcom.ru

После окончания установки перезагрузите компьютер.

При входе на Сбербанк-АСТ ошибка: «Клиентский сертификат не сопоставлен с пользователем»

Лицензионный ключ активации Windows от