Error 0x40 unknown returned by certverifycertificatechainpolicy

Содержание

1С и Linux
суббота, 15 декабря 2018 г.
Доступ zakupki.gov.ru Not Secure
Error 0x40 unknown returned by certverifycertificatechainpolicy
Answered by:
Question
Answers
All replies

1С и Linux

Пишу для себя, чтобы не забыть как делал. 95 % рабочее. На комментарии отвечаю, когда увижу.

суббота, 15 декабря 2018 г.

Доступ zakupki.gov.ru Not Secure

]# /opt/cprocsp/bin/amd64/csptestf -tlsc -server zakupki.gov.ru -v -nosave -savecert /tmp/t.p7b
[root@test-x64-centos7

]# /opt/cprocsp/bin/amd64/certmgr -list -file /tmp/t.p7b
=============================================================================
1——-
Issuer : E=uc_fk@roskazna.ru, S=г. Москва, INN=007710568760, OGRN=1047797019830, STREET=»улица Ильинка, дом 7″, L=Москва, C=RU, O=Федеральное казначейство, CN=Федеральное казначейство
Subject : INN=007710568760, OGRN=1047797019830, STREET=»ул. Проспект Мира, 105″, E=777@roskazna.ru, C=RU, S=г. Москва, L=Москва, O=Федеральное казначейство, CN=zakupki.gov.ru
Serial : 0x6F064FA71C24CD7E2CE6FAAEA927D8C7EC69A35F
SHA1 Hash : c369b560ce239beddb2fc12b4884dee1cfc923aa
SubjKeyID : 10c6d12e7cd886d022bcdfea4cbe10e32acf82bc
Signature Algorithm : ГОСТ Р 34.11/34.10-2001
PublicKey Algorithm : ГОСТ Р 34.10-2001 (512 bits)
Public key : 04 40 1b ce 0b 15 6a 4a 57 e0 1b d8 39 ee 86 83
32 70 ea db fd f5 39 c1 e6 de 3c c8 be 10 81 03
5d da 0b 3b 09 7a d3 0d 46 33 58 11 3b 20 94 99
fe 04 fe 8e e6 bc 32 53 ff 2e 71 10 8e e2 12 a1
52 cf
Not valid before : 21/12/2017 06:06:33 UTC
Not valid after : 21/03/2019 06:06:33 UTC
PrivateKey Link : No
Subject Alt Names
UPN : ▒㌴ (2.5.4.12)
URL : 0
CDP : http://crl.roskazna.ru/crl/ucfk.crl
CDP : http://crl.fsfk.local/crl/ucfk.crl
Extended Key Usage : 1.3.6.1.5.5.7.3.1
.

При наличии расширения Subject Alt Names RFC требует сверять имя сервера с ним, а не с полем CN. Поэтому CN=zakupki.gov.ru отброшен, а в Subject Alt Names хрень.

]# /opt/cprocsp/sbin/amd64/cpconfig -ini ‘configparameters’ -add long Rfc6125_NotStrict_ServerName_Check 1
[root@test-x64-centos7

]# /opt/cprocsp/bin/amd64/csptestf -tlsc -server zakupki.gov.ru -nosave
HDEContext expired: OK if file is completely downloaded
Reply status: HTTP/1.1 200 OK
1 connections, 586 bytes in 0.186 seconds;
Total: SYS: 0,020 sec USR: 0,140 sec UTC: 0,230 sec
[ErrorCode: 0x00000000]

# /opt/cprocsp/bin/amd64/csptest -keyset -verifycontext
CSP (Type:80) v4.0.9017 KC2 Release Ver:4.0.9944 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 25072019
GetProvParam(PP_NAME): Crypto-Pro GOST R 34.10-2012 KC2 CSP
Total: SYS: 0,000 sec USR: 0,000 sec UTC: 0,010 sec
[ErrorCode: 0x00000000]

L K, [15.12.18 14:12]
[В ответ на Andrey]
root@astra:

# /opt/cprocsp/sbin/amd64/cpconfig -ini ‘configparameters’ -add long Rfc6125_NotStrict_ServerName_Check 1
root@astra:

# /opt/cprocsp/bin/amd64/csptestf -tlsc -server zakupki.gov.ru -nosave
HSECPKG_ATTR_PACKAGE_INFO not supported.
Error 0x800b010f (CERT_E_CN_NO_MATCH) returned by CertVerifyCertificateChainPolicy!
An error occurred in running the program.
/dailybuildsbranches/CSP_4_0/CSPbuild/CSP/samples/csptest/WebClient.c:764:Error authenticating server credentials!
Error number 0x800b010f (2148204815).
CN-имя сертификата не совпадает с полученным значением.
Total: SYS: 0,070 sec USR: 0,290 sec UTC: 1,720 sec
[ErrorCode: 0x800b010f]

Какой релиз КриптоПро нужно ставить?

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ
Andrey, [12.12.18 18:12]
Вышел финальный релиз КриптоПро CSP 4.0 R4 (сборка 4.0.9963 Abel):
https://www.cryptopro.ru/forum2/default.aspx?g=posts&m=97735#post97735
На дистрибутив получено положительное заключение, скоро будет сертификат.
В тестовых целях её можно установить из нашего репозитория:
https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=12507

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ
Andrey, [15.12.18 23:07]
[В ответ на L K]
В любом случае лучше ставить последний, на который сейчас получаем сертификат — 4.0.9963 Abel. В 9944 в этой команде должна помочь замена long на bool и 1 на true.

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

$ /opt/cprocsp/bin/amd64/csptest -keyset -verifycontext
CSP (Type:80) v4.0.9019 KC2 Release Ver:4.0.9963 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 26834115
GetProvParam(PP_NAME): Crypto-Pro GOST R 34.10-2012 KC2 CSP
Total: SYS: 0,000 sec USR: 0,000 sec UTC: 0,020 sec
[ErrorCode: 0x00000000]

$ sudo /opt/cprocsp/sbin/amd64/cpconfig -ini ‘configparameters’ -add long Rfc6125_NotStrict_ServerName_Check 1

$ sudo /opt/cprocsp/bin/amd64/csptestf -tlsc -server zakupki.gov.ru -nosave
HSECPKG_ATTR_PACKAGE_INFO not supported.
DContext expired: OK if file is completely downloaded
Reply status: HTTP/1.1 200 OK
1 connections, 589 bytes in 1.221 seconds;
Total: SYS: 0,040 sec USR: 0,320 sec UTC: 1,300 sec
[ErrorCode: 0x00000000]

Для 4.0.9944
user@astra:

$ /opt/cprocsp/bin/amd64/csptest -keyset -verifycontext
CSP (Type:80) v4.0.9017 KC2 Release Ver:4.0.9944 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 20066515
GetProvParam(PP_NAME): Crypto-Pro GOST R 34.10-2012 KC2 CSP
Total: SYS: 0,000 sec USR: 0,000 sec UTC: 0,030 sec
[ErrorCode: 0x00000000]
user@astra:

$ sudo /opt/cprocsp/sbin/amd64/cpconfig -ini ‘configparameters’ -add bool Rfc6125_NotStrict_ServerName_Check true
user@astra:

Источник

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I have an application set up for deployment, but it seems installation is not starting on client.

After a few minutes from deployment I can see the state under «Unknown» tab with a state on the machine like «Client checks validated» (don’t now what it’s called in English exactly).

Will the installation start at a later time or will I wait forever? Is there a way to push installation a bit if there should be a waiting time?

Thanks for any help,
Melampous

Answers

First check the installation deadline of the deployment (tab Scheduling). If that’s past then check the client, most interesting log file in that case is AppEnforce.log.

In case the installation hasn’t arrived yet, first trigger a machine policy.

I’ve already double checked it. Even set the time some hours earlier just in case there’s an issue with UTC and client time.

About the log: I’ve already found articles considering these App*.log files, but I don’t have them!?

Machine policy has been triggered manually after each test.

I’ve found something that doesn’t look good at all and maybe someone could confirm it may have to do with my issue:

In log files I’ve found an error from BgbAgent complaining about an invalid certificate:

Handshake before was successful.

Another error I’ve found from SoftwareCatalogEndpointUpdate:

Okay, the first installation from yesterday has been provided to client this morning and then sucessfully executed. So it seems there’s really something else I have to restart/force so my installation will begin. Also the App*.log files are present now.

But what do I need to push? Because now I’ve added a second program and have the same behaviour. Not even download is starting on Client even after policy refresh.

Another issue: state in reports is not changing although program Installation finished.

So I guess, I should first concentrate on the issue with notifications and Bgb log. The complete log from Connection tries is as follows:

As you can see client validation fails (is it because it connects to IP instead of DNS?). So it tries HTTP which correctly will fail.

Источник

Всем доброго дня.
Недавно ко мне обратился знакомый с вопросом по реализации шифрованного по алгоритму ГОСТ TLS-канала для работы с веб-сервисами некоторых БКИ.
Немного помыслив, вспомнил, что есть такая замечательная штука как stunnel, которая может TLS как в режиме сервера, так и в режиме клиента. Плюс к этому компания КриптоПро сделала форк stunnel с оптимизацией под российские криптоалгоритмы. В итоге родился небольшой гайд по реализации простого и бюджетного варианта, которым и хочу поделиться с вами.

В качестве примера приводится настройка stunnel в качестве TLS клиента:
1) к серверу НБКИ без авторизации пользователя;
2) к тестовому УЦ КриптоПро с авторизацией пользователя по сертификату.
В данном материале использовались OC Debian 8.3 x86 и КриптоПро CSP 4.0.9708 (Nechaev) от 01.03.2016 (stunnel включен).

1. Установка Крипто-Про CSP и stunnel

Скачиваем архив CSP с сайта КриптоПро и распаковываем

tar zxvf linux-ia32_deb.tgz
cd linux-ia32_deb

Установливаем минимально необходимый набор пакетов

sudo apt-get install lsb-core
sudo dpkg -i lsb-cprocsp-base_4.0.0-4_all.deb
sudo dpkg -i lsb-cprocsp-rdr_4.0.0-4_i386.deb
sudo dpkg -i lsb-cprocsp-capilite_4.0.0-4_i386.deb
sudo dpkg -i lsb-cprocsp-kc1_4.0.0-4_i386.deb
sudo dpkg -i cprocsp-stunnel_4.0.0-4_i386.deb

2. Импорт корневых сертификатов

Импортируем корневые сертификаты КриптоПро в локальное хранилище сертификатов.
Нам понадобятся два сертификата:
— корневой сертификат УЦ Крипто-Про. Данным сертификатом подписан сертификат веб-сервера НБКИ;
— корневой сертификат тестового УЦ КриптоПро. Данным сертификатом подписан сертификат веб-сервера тестового УЦ КриптоПро и тестовый сертификат нашего пользователя.

/opt/cprocsp/bin/ia32/certmgr -inst -file <home>/cert/ca_cryptopro_4aad6f_der.cer -store ROOT
/opt/cprocsp/bin/ia32/certmgr -inst -file <home>/cert/ca_test_cryptopro_4487da_der.cer -store ROOT

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

/opt/cprocsp/bin/ia32/certmgr -list -store ROOT

3. Копирование ключевого контейнера пользователя

Наверное, это самая запутанная и самая важная часть данного руководства.
Сначала немного теории «на пальцах».
В протоколе TLS предусмотрена односторонняя и двусторонняя аутентификация. Под односторонней чаще всего понимается аутентификация веб-сервера, когда сервер доказывает клиенту что действительно владеет закрытым ключом предъявленного цифрового сертификата. Под двусторонней аутентификацией сервер и клиент доказывают это друг другу.
В КриптоПро ключевая информация (ключи шифрования) хранятся в контейнере (с точки зрения файловой системы — это каталог с несколькими файлами). В качестве носителя может выступать (чаще всего) дискета, флешка, токен, ветка реестра (Windows) или каталог (Linux). И если клиент или сервер проходят взаимную аутентификацию (доказывают владение ключами), то они должны иметь не только цифровой сертификат с открытым ключом, но и сам контейнер с ключами.
Опустим процесс создания тестового ключа в тестовом УЦ КриптоПро и начем с того момента, что у нас есть ключевой контейнер с именем «test» на флешке.
Монтируем флешку

sudo mount /dev/sdb1 /media/sdb1/

Копируем контейнер с флешки на HDD
Есть два способа: ручной и с помощью утилиты. Я скопировал вручную

cp -r /media/sdb1/test.000/ /var/opt/cprocsp/keys/stunnel/

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

certmgr -list -cont '\.HDIMAGEtest'

Проверим работоспособность ключей

csptest -keyset -check -cont '\.HDIMAGEtest'

Экспортируем сертификат пользователя в файл (он еще понадобится)

certmgr -export -dest test_user_7a8110.cer -cont '\.HDIMAGEtest'

Делаем привязку данного сертификата пользователя к нашему контейнеру

certmgr -inst -file test_user_7a8110.cer -cont '\.HDIMAGEtest'

Проверяем локальное хранилище сертификатов пользователя

certmgr -list -store My

Проверяем локальное хранилище сертификатов пользователя

PrivateKey Link     : Yes
Container           : HDIMAGE\test.0002EF8

Создаем файл конфигурации с нужными нам настройками для stunnel

sudo mkdir /etc/stunnel
sudo vim /etc/stunnel/stunnel.conf

Содержимое файла конфигурации:

setgid = stunnel
setuid = stunnel
pid=/var/opt/cprocsp/tmp/stunnel_cli.pid
output=/var/opt/cprocsp/tmp/stunnel_cli.log
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
debug = 3
client = yes

[stunnel.nbki]
accept = <IP address>:8181
connect = icrs.nbki.ru:443
verify=2

[stunnel.test_uc]
accept = <IP address>:8282 
connect = www.cryptopro.ru:5555
client = /etc/stunnel/test_user_7a8110.cer
verify=2

Запускаем процесс

/opt/cprocsp/sbin/amd64/stunnel_thread /etc/stunnel/stunnel.conf

Проверяем результат

5. Автоматический запуск Stunnel

Когда все заработало должным образом, то было бы неплохо автоматизировать запуск stunnel при загрузке ОС.
Создаем скрипт запуска. Также будут доступны команды управления start, stop, restart.
Пример команды для перезагрузки stunnel:

sudo service stunnel_thread restart

Создаем скрипт

sudo vim /etc/init.d/stunnel_thread

и помещаем в него следующий текст:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          stunnel
# Default-Start:     3 5
# Default-Stop:      0 1 6
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Short-Description: Start daemon at boot time
# Description:       Enable stunnel by daemon.
### END INIT INFO

PATH_DAEMON=/opt/cprocsp/sbin/ia32
DAEMON=stunnel_thread
CONFIG=/etc/stunnel/stunnel.conf

test -x $PATH_DAEMON/$DAEMON || exit 0

case "$1" in
start)
$PATH_DAEMON/$DAEMON $CONFIG
;;
stop)
        pkill -f $DAEMON
;;
restart)
        pkill -f $DAEMON
        sleep 3
        $PATH_DAEMON/$DAEMON $CONFIG
;;
*)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
;;
esac
exit 0

Добавляем в автозагрузку

sudo update-rc.d stunnel_thread defaults

6. Troubleshooting

Частые ошибки, с которыми я столкнулся и можете столкнуться вы.
1) Не открывается сайт через stunnel
Что нужно сделать:
— проверить адрес и порт в конфиге
— в браузере открывать не только сам адрес stunnel, а полный путь.
Пример: не 10.0.0.123:8181, а 10.0.0.123:8181/se/login
2) Следующие ошибки в логе

Error 0x40 ((unknown)) returned by CertVerifyCertificateChainPolicy!

и/или

Error 0x40 when validate certificate

Ошибка возникает из-за того, что stunnel не может проверить сертификат по списку отзыва CRL. Проблему можно решить тремя вариантами (но с разной эффективностью):
— периодически вручную импортировать актуальный CRL с помощью certmgr;
— отключить проверку сертификатов в TLS в файле настроек CSP

/etc/opt/cprocsp/config.ini

— в файле настроек CSP (написан выше) указать корректный путь к библиотеке curl.

"libcurl.so" = "/usr/lib/i386-linux-gnu/libcurl.so.4"

7. Ссылки

Тестовый Удостоверяющий Центр КриптоПро
КриптоПро CSP
КриптоПро Stunnel
Официальные мануалы по КриптоПро Stunnel

Ключевые слова для поисковых систем: настройка БКИ, автоматизированый обмен с бюро кредитных историй, автоматическое получение отчетов с бюро кредитных историй, КриптоПро и БКИ, обмен с бюро кредитных историй, шифрование трафика криптопро, криптопро на linux

Источник

Boris7772	#1 Оставлено : 24 ноября 2020 г. 12:47:18(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 21.11.2020(UTC) Сообщений: 3	Добрый день, Пытаюсь настроить взаимодейтсвие с ФинЦЕРТ через stunnel установил согласно регламенту ФинЦЕРТ сертификаты из архива: http://cbr.ru/StaticHtml/File/14408/ASOI_docs.zip Приложил лог с ошибкой и конфигурацию stunnel. Использую stunnel из CSP 4.0.9963 Конфигурация stunnel setgid = stunnel setuid = stunnel pid=/var/opt/cprocsp/tmp/stunnel_cli.pid output=/var/opt/cprocsp/tmp/stunnel_cli.log socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 debug = 7 [portal] client=yes accept = localhost:8181 connect = portal.fincert.cbr.ru:443 verify=2 Лог с проблемой: Цитата: 2020.11.24 12:30:44 LOG3[1123:140439079679744]: Error 0x8009030e returned by VerifyCertChain 2020.11.24 12:30:44 LOG3[1123:140439079679744]: ** Error 0x8009030e authenticating server credentials! 2020.11.24 12:30:44 LOG5[1123:140439079679744]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2020.11.24 12:30:44 LOG7[1123:140439079679744]: free Buffers 2020.11.24 12:30:44 LOG7[1123:140439079679744]: delete c->hContext 2020.11.24 12:30:44 LOG7[1123:140439079679744]: delete c->hClientCreds 2020.11.24 12:30:44 LOG5[1123:140439079679744]: incomp_mess = 0, extra_data = 0 2020.11.24 12:30:44 LOG7[1123:140439079679744]: portal finished (0 left) 2020.11.24 12:30:54 LOG7[1123:140439079688000]: portal accepted FD=8 from ::1:48772 2020.11.24 12:30:54 LOG7[1123:140439079679744]: client start 2020.11.24 12:30:54 LOG7[1123:140439079679744]: portal started 2020.11.24 12:30:54 LOG7[1123:140439079679744]: FD 8 in non-blocking mode 2020.11.24 12:30:54 LOG7[1123:140439079679744]: TCP_NODELAY option set on local socket 2020.11.24 12:30:54 LOG7[1123:140439079679744]: FD 10 in non-blocking mode 2020.11.24 12:30:54 LOG7[1123:140439079679744]: FD 11 in non-blocking mode 2020.11.24 12:30:54 LOG7[1123:140439079679744]: Connection from ::1:48772 permitted by libwrap 2020.11.24 12:30:54 LOG5[1123:140439079679744]: portal connected from ::1:48772 2020.11.24 12:30:54 LOG7[1123:140439079688000]: Cleaning up the signal pipe 2020.11.24 12:30:54 LOG6[1123:140439079688000]: Child process 1739 finished with code 0 2020.11.24 12:30:54 LOG7[1123:140439079679744]: FD 16 in non-blocking mode 2020.11.24 12:30:54 LOG7[1123:140439079679744]: portal connecting 2020.11.24 12:30:54 LOG7[1123:140439079679744]: connect_wait: waiting 10 seconds 2020.11.24 12:30:54 LOG7[1123:140439079679744]: connect_wait: connected 2020.11.24 12:30:54 LOG7[1123:140439079679744]: Remote FD=16 initialized 2020.11.24 12:30:54 LOG7[1123:140439079679744]: TCP_NODELAY option set on remote socket 2020.11.24 12:30:54 LOG7[1123:140439079679744]: start SSPI connect 2020.11.24 12:30:54 LOG3[1123:140439079679744]: Credentials complete 2020.11.24 12:30:54 LOG7[1123:140439079679744]: 113 bytes of handshake data sent 2020.11.24 12:30:54 LOG5[1123:140439079679744]: 2018 bytes of handshake(in handshake loop) data received. 2020.11.24 12:30:54 LOG5[1123:140439079679744]: 215 bytes of handshake data sent 2020.11.24 12:30:54 LOG5[1123:140439079679744]: 31 bytes of handshake(in handshake loop) data received. 2020.11.24 12:30:54 LOG5[1123:140439079679744]: Handshake was successful 2020.11.24 12:30:54 LOG5[1123:140439079679744]: PerformClientHandshake finish 2020.11.24 12:30:54 LOG5[1123:140439079679744]: Server subject: 1.2.643.100.111=»#0C818AD0A1D0A0D095D094D0A1D0A2D092D09E20D09AD0A0D098D09FD0A2D09ED093D0A0D090D0A4D098D0A7D095D0A1D09AD09ED09920D097D090D0A9D098D0A2D0AB20D098D09DD0A4D09ED0A0D09CD090D0A6D098D0982022D09AD09ED09DD0A2D098D09DD095D09DD0A220544C532DD0A1D095D0A0D092D095D0A02220D092D095D0A0D0A1D098D0AF2032″, C=RU, L=Москва, O=CBR, OU=Центр мониторинга и реагирования на компьютерные атаки ЦБ РФ, STREET=»ул.Неглинная, д.12″, CN=portal.fincert.cbr.ru, E=info_fincert@cbr.ru 2020.11.24 12:30:54 LOG5[1123:140439079679744]: Server issuer: DC=ru, DC=cbr, DC=region, OU=PKI, OU=GUBZI, CN=ROOTsvc-CA 2020.11.24 12:30:54 LOG3[1123:140439079679744]: Error 0x10000 ((unknown)) returned by CertVerifyCertificateChainPolicy! 2020.11.24 12:30:54 LOG3[1123:140439079679744]: Error 0x10000 when validate certificate 2020.11.24 12:30:54 LOG3[1123:140439079679744]: Error 0x8009030e returned by VerifyCertChain 2020.11.24 12:30:54 LOG3[1123:140439079679744]: ** Error 0x8009030e authenticating server credentials! 2020.11.24 12:30:54 LOG5[1123:140439079679744]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2020.11.24 12:30:54 LOG7[1123:140439079679744]: free Buffers 2020.11.24 12:30:54 LOG7[1123:140439079679744]: delete c->hContext 2020.11.24 12:30:54 LOG7[1123:140439079679744]: delete c->hClientCreds 2020.11.24 12:30:54 LOG5[1123:140439079679744]: incomp_mess = 0, extra_data = 0 2020.11.24 12:30:54 LOG7[1123:140439079679744]: portal finished (0 left) Подскажите, пожалуйста, с чем связана данная проблема и как ее можно решить? Отредактировано пользователем 24 ноября 2020 г. 18:01:23(UTC) \| Причина: Не указана

Михаил Селезнёв	#2 Оставлено : 24 ноября 2020 г. 17:52:02(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 05.04.2017(UTC) Сообщений: 354 Сказал «Спасибо»: 3 раз Поблагодарили: 49 раз в 49 постах	Добрый день! Приложенные файлы пустые. Прошу запаковать их в архив.

Boris7772	#3 Оставлено : 24 ноября 2020 г. 18:02:28(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 21.11.2020(UTC) Сообщений: 3	Автор: Михаил Селезнёв Добрый день! Приложенные файлы пустые. Прошу запаковать их в архив. Что-то не удалось загрузить файлы нормально, опубликовал лог и конфигурацию в посте

Nikolay Batischev	#4 Оставлено : 24 ноября 2020 г. 18:13:58(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 06.11.2013(UTC) Сообщений: 70 Откуда: Тирана Сказал «Спасибо»: 3 раз Поблагодарили: 11 раз в 11 постах	Добрый день! Нужно установить корневой сертификат от сертификата в доверенное хранилище. Или в конфиге использовать verify =0

Boris7772	#5 Оставлено : 24 ноября 2020 г. 18:26:15(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 21.11.2020(UTC) Сообщений: 3	Автор: Nikolay Batischev Добрый день! Нужно установить корневой сертификат от сертификата в доверенное хранилище. Или в конфиге использовать verify =0 Установил этот параметр в 0, ошибка ушла спасибо, запросы к сервису стали отбиваться с 421 статусом, это я так понимаю уже внешняя проблема? Лог при этом следующий: 2020.11.24 18:28:35 LOG7[23480:139871409022784]: portal accepted FD=8 from 192.168.24.98:59128 2020.11.24 18:28:35 LOG7[23480:139871409014528]: client start 2020.11.24 18:28:35 LOG7[23480:139871409014528]: portal started 2020.11.24 18:28:35 LOG7[23480:139871409014528]: FD 8 in non-blocking mode 2020.11.24 18:28:35 LOG7[23480:139871409014528]: TCP_NODELAY option set on local socket 2020.11.24 18:28:35 LOG7[23480:139871409014528]: FD 9 in non-blocking mode 2020.11.24 18:28:35 LOG7[23480:139871409014528]: FD 11 in non-blocking mode 2020.11.24 18:28:35 LOG7[23480:139871409014528]: Connection from 192.168.24.98:59128 permitted by libwrap 2020.11.24 18:28:35 LOG5[23480:139871409014528]: portal connected from 192.168.24.98:59128 2020.11.24 18:28:35 LOG7[23480:139871409022784]: Cleaning up the signal pipe 2020.11.24 18:28:35 LOG6[23480:139871409022784]: Child process 24405 finished with code 0 2020.11.24 18:28:35 LOG7[23480:139871409014528]: FD 15 in non-blocking mode 2020.11.24 18:28:35 LOG7[23480:139871409014528]: portal connecting 2020.11.24 18:28:35 LOG7[23480:139871409014528]: connect_wait: waiting 10 seconds 2020.11.24 18:28:35 LOG7[23480:139871409014528]: connect_wait: connected 2020.11.24 18:28:35 LOG7[23480:139871409014528]: Remote FD=15 initialized 2020.11.24 18:28:35 LOG7[23480:139871409014528]: TCP_NODELAY option set on remote socket 2020.11.24 18:28:35 LOG7[23480:139871409014528]: start SSPI connect 2020.11.24 18:28:35 LOG3[23480:139871409014528]: Credentials complete 2020.11.24 18:28:35 LOG7[23480:139871409014528]: 118 bytes of handshake data sent 2020.11.24 18:28:35 LOG5[23480:139871409014528]: 1975 bytes of handshake(in handshake loop) data received. 2020.11.24 18:28:35 LOG5[23480:139871409014528]: 215 bytes of handshake data sent 2020.11.24 18:28:35 LOG5[23480:139871409014528]: 31 bytes of handshake(in handshake loop) data received. 2020.11.24 18:28:35 LOG5[23480:139871409014528]: Handshake was successful 2020.11.24 18:28:35 LOG5[23480:139871409014528]: PerformClientHandshake finish 2020.11.24 18:28:35 LOG5[23480:139871409014528]: Verify_level = 0, skipping Server certificate verification 2020.11.24 18:28:35 LOG7[23480:139871409014528]: add ssl read socket to pool 2020.11.24 18:28:35 LOG7[23480:139871409014528]: ssl_rd = 1, c->ssl_ptr = 0,c->sock_ptr=0,want_rd = 0 2020.11.24 18:28:35 LOG7[23480:139871409014528]: Enter pool section on transfer 2020.11.24 18:28:35 LOG7[23480:139871409014528]: data reciev from socket = 116 2020.11.24 18:28:35 LOG7[23480:139871409014528]: add ssl read socket to pool 2020.11.24 18:28:35 LOG7[23480:139871409014528]: ssl_rd = 1, c->ssl_ptr = 0,c->sock_ptr=116,want_rd = 0 2020.11.24 18:28:35 LOG7[23480:139871409014528]: Enter pool section on transfer 2020.11.24 18:28:35 LOG5[23480:139871409014528]: SSPI_write start 2020.11.24 18:28:35 LOG7[23480:139871409014528]: SSPI_write data is GET 2020.11.24 18:28:35 LOG7[23480:139871409014528]: send all data after encrypt 2020.11.24 18:28:35 LOG7[23480:139871409014528]: data send to ssl_socket =116 2020.11.24 18:28:35 LOG7[23480:139871409014528]: add ssl read socket to pool 2020.11.24 18:28:35 LOG7[23480:139871409014528]: ssl_rd = 1, c->ssl_ptr = 0,c->sock_ptr=0,want_rd = 0 2020.11.24 18:28:35 LOG7[23480:139871409014528]: Enter pool section on transfer 2020.11.24 18:28:35 LOG7[23480:139871409014528]: SSPI_read start 2020.11.24 18:28:35 LOG7[23480:139871409014528]: recv ok on SSPI_read err= 324 2020.11.24 18:28:35 LOG5[23480:139871409014528]: Received 324 bytes from ssl socket 2020.11.24 18:28:35 LOG7[23480:139871409014528]: SSPI_read data in ssl_buff is HTTP 2020.11.24 18:28:35 LOG7[23480:139871409014528]: data read from ssl_sock =315 2020.11.24 18:28:35 LOG7[23480:139871409014528]: add ssl read socket to pool 2020.11.24 18:28:35 LOG7[23480:139871409014528]: ssl_rd = 1, c->ssl_ptr = 315,c->sock_ptr=0,want_rd = 0 2020.11.24 18:28:35 LOG7[23480:139871409014528]: add write socket to poll 2020.11.24 18:28:35 LOG7[23480:139871409014528]: Enter pool section on transfer 2020.11.24 18:28:35 LOG7[23480:139871409014528]: data send to socket = 315 2020.11.24 18:28:35 LOG7[23480:139871409014528]: SSPI_read start 2020.11.24 18:28:35 LOG7[23480:139871409014528]: recv ok on SSPI_read err= 0 2020.11.24 18:28:35 LOG3[23480:139871409014528]: recv return 0 and ask more but there is not complete data for decrypt. Peer disconnected? 2020.11.24 18:28:35 LOG5[23480:139871409014528]: SSPI_read: read socket closed 2020.11.24 18:28:35 LOG7[23480:139871409014528]: Socket write shutdown 2020.11.24 18:28:35 LOG7[23480:139871409014528]: c->ssl_ptr = 0 2020.11.24 18:28:35 LOG7[23480:139871409014528]: Enter pool section on transfer 2020.11.24 18:28:35 LOG3[23480:139871409014528]: readsocket: Connection reset by peer (104) 2020.11.24 18:28:35 LOG5[23480:139871409014528]: Connection reset: 116 bytes sent to SSL, 315 bytes sent to socket 2020.11.24 18:28:35 LOG7[23480:139871409014528]: free Buffers 2020.11.24 18:28:35 LOG7[23480:139871409014528]: delete c->hContext 2020.11.24 18:28:35 LOG7[23480:139871409014528]: delete c->hClientCreds 2020.11.24 18:28:35 LOG5[23480:139871409014528]: incomp_mess = 2, extra_data = 0 2020.11.24 18:28:35 LOG7[23480:139871409014528]: portal finished (0 left) Отредактировано пользователем 24 ноября 2020 г. 18:29:32(UTC) \| Причина: Не указана

Пользователи, просматривающие эту тему

Guest (2)

Быстрый переход

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Источник

Remove From My Forums

Question
I was using SSL Diagnostics to troubleshoot client cert problem, and I got this:

    CertVerifyCertificateChainPolicy=»0x1″
    CertGetCertificateChain_dwFlags=»0x40000000″
    CERT_CHAIN_PARA.dwUrlRetrievalTimeout=»0 ms»
    CERT_CHAIN_PARA.fCheckRevocationFreshnessTime=»FALSE»
    CERT_CHAIN_PARA.dwRevocationFreshnessTime=»0 sec»
    CERT_CHAIN_POLICY_STATUS.dwError=»0x800b010f»
    CERT_CHAIN_POLICY_STATUS.lChainIndex=»0″
    CERT_CHAIN_POLICY_STATUS.lElementIndex=»1″

I want to know what CERT_CHAIN_POLICY_STATUS.dwError=»0x800b010f» means. Microsoft documentation gives out the error in string only, rather long ones too. Does anyone know how to interpret the error code in hex?

Answers

It stands for CERT_E_CN_NO_MATCH (from winerror.h). The explain text for this error is «The certificate’s CN name does not match the passed value». It literally means the target server name does not match the CN name in the certificate used in authentication. You can choose to ignore this error when calling CertVerifyCertificateChainPolicy (which may or may not be a good idea depending what is app is built for) by setting pPolicyPara->pvExtraPolicyPara->fdwChecks with SECURITY_FLAG_IGNORE_CERT_CN_INVALID.

http://msdn.microsoft.com/en-us/library/aa377163.aspx

Hope this helps.

Thanks!

GK
- Marked as answer by
  
  Tuesday, May 25, 2010 4:33 PM

Источник

ИгорьК	#31 Оставлено : 15 декабря 2022 г. 13:15:40(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 11.01.2017(UTC) Сообщений: 21 Откуда: Москва	Поддержка КриптоПро попросила запустить тест «C:Program FilesCrypto ProCSPcsptest.exe» -tlsc -server 212.40.208.62 –v все пошло хорошо, но в конце Server certificate: Subject: CN=212.40.208.62 Valid : 05.09.2022 13:24:27 — 03.09.2032 13:24:27 (UTC) Issuer : SERIALNUMBER=20220906132427, CN=Ideco UTM CA subject: SERIALNUMBER=20220906132427, CN=Ideco UTM CA issuer : SERIALNUMBER=20220906132427, CN=Ideco UTM Error 0x80092012 ((unknown)) returned by CertVerifyCertificateChainPolicy! Total: SYS: 0.063 sec USR: 0.031 sec UTC: 12.355 sec [ErrorCode: 0x80092012] Error authenticating server credentials Функция отзыва не смогла произвести проверку отзыва сертификата разбираемся дальше

ИгорьК	#32 Оставлено : 15 декабря 2022 г. 14:30:41(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 11.01.2017(UTC) Сообщений: 21 Откуда: Москва	Разобрались с нашими сетевиками Мне недостаточно было поменять основной шлюз в сетевых настройках, который напрямую в интернет идет Надо было еще переключиться с автоматического получения адреса в настройках сетевого адаптера , на ручной с явным указанием своего IP и прочая Иначе весть трафик шел через локальную сеть и при выходе в интернет что то с ним случалось Об этом и поддержка ЦБ говорила, а я был уверен, что одной смены основного шлюза было достаточно. Сейчас получаю подпись со штампом времени. И сертификатов в личном полно, как и было. Попрошу наших сетевиков придумать прямой проброс из локалки

ew-mc	#33 Оставлено : 15 декабря 2022 г. 15:08:02(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 12.12.2022(UTC) Сообщений: 10 Откуда: Москва	Игорь, а можете скинуть рекомендации поддержки ЦБ? Мне непонятно почему траффик не ломается если сертификат один в хранилище и ломается если сертификатов несколько…. Мы сейчас можем подписывать только если сертификат в хранилище один. Как только добавляются другие сертификаты, всё ломается. Нам ссылка на сертификат в конфиге не помогает.

ИгорьК	#34 Оставлено : 15 декабря 2022 г. 15:13:33(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 11.01.2017(UTC) Сообщений: 21 Откуда: Москва	Сетевики убрали на Ideco проверку траффика по этим IP (212.40.208.62 и 212.40.193.62) и через локалку тоже все заработало!

ИгорьК	#35 Оставлено : 15 декабря 2022 г. 15:19:00(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 11.01.2017(UTC) Сообщений: 21 Откуда: Москва	Автор: ew-mc Игорь, а можете скинуть рекомендации поддержки ЦБ? Мне непонятно почему траффик не ломается если сертификат один в хранилище и ломается если сертификатов несколько…. Мы сейчас можем подписывать только если сертификат в хранилище один. Как только добавляются другие сертификаты, всё ломается. Нам ссылка на сертификат в конфиге не помогает. Так ЦБ ничего нового не посоветовало (они сразу говорили, проверьте ваши прокси, что бы не лезло в анализ трафика!) Лучше выполните это, от КриптоПРо, и посмотрите что будет Цитата: Запустите cmd и выполните последовательно: «C:Program FilesCrypto ProCSPcsptest.exe» -tlsc -server 212.40.208.62 -v и «C:Program FilesCrypto ProCSPcsptest.exe» -tlsc -server 212.40.193.62 -v Приложите полный вывод. Сертификат запрашивается при выполнении?

ew-mc	#36 Оставлено : 15 декабря 2022 г. 15:56:43(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 12.12.2022(UTC) Сообщений: 10 Откуда: Москва	Выполнил, ошибка одинаковая: Server certificate: Subject: C=RU, S=77 г. Москва, L=г. Москва, STREET=»ул. Неглинная, д. 12″, O=Банк России, CN=Центральный банк Российской Федерации, ОГРН=1037700013020, OID.1.2.643.100.4=7702235133 Valid : 06.10.2021 16:36:34 — 30.08.2036 12:32:44 (UTC) Issuer : C=RU, S=77 г. Москва, L=г. Москва, STREET=»ул. Неглинная, д. 12″, O=Банк России, CN=Центральный банк Российской Федерации, ОГРН=1037700013020, ИНН=007702235133 PrivKey: 06.10.2021 16:36:34 — 06.01.2023 16:36:33 (UTC) Error 0x800b010f (CERT_E_CN_NO_MATCH) returned by CertVerifyCertificateChainPolicy! An error occurred in running the program. WebClient.c:794:Error authenticating server credentials! Error number 0x800b010f (-2146762481). CN-имя сертификата не совпадает с полученным значением. Total: SYS: 0,156 sec USR: 0,078 sec UTC: 0,606 sec [ErrorCode: 0x800b010f]

ИгорьК	#37 Оставлено : 15 декабря 2022 г. 16:56:25(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 11.01.2017(UTC) Сообщений: 21 Откуда: Москва	Кстати, у нас такая же ошибка csptest.exe (я им в ЦБ переслал ее) но и WEB и КриптоАрм ГОСТ работают!

Dmitry-G	#38 Оставлено : 15 декабря 2022 г. 21:34:08(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 08.12.2022(UTC) Сообщений: 17 Откуда: Москва	Автор: ИгорьК Разобрались с нашими сетевиками Мне недостаточно было поменять основной шлюз в сетевых настройках, который напрямую в интернет идет Надо было еще переключиться с автоматического получения адреса в настройках сетевого адаптера , на ручной с явным указанием своего IP и прочая Иначе весть трафик шел через локальную сеть и при выходе в интернет что то с ним случалось Об этом и поддержка ЦБ говорила, а я был уверен, что одной смены основного шлюза было достаточно. Сейчас получаю подпись со штампом времени. И сертификатов в личном полно, как и было. Попрошу наших сетевиков придумать прямой проброс из локалки Добрый день, коллеги! Игорь, вопрос, что называется, «на засыпку»)) Как же у Вас, без изменения обозначенных выше сетевых настроек, раньше все заработало с одним сертификатом в справочнике?

ИгорьК	#39 Оставлено : 16 декабря 2022 г. 9:55:01(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 11.01.2017(UTC) Сообщений: 21 Откуда: Москва	Автор: Dmitry-G Игорь, вопрос, что называется, «на засыпку»)) Как же у Вас, без изменения обозначенных выше сетевых настроек, раньше все заработало с одним сертификатом в справочнике? Не, я же написал, что на новой, чистой. Наши сетевики сделали новую виртуалку с прямым выходом в интернет — и там все отработало. Чуть раньше у нас был прокси, который просто пробрасывал соединение из локалки наружу. А теперь мы все через Ideco, а он по умолчанию анализирует весь трафик: ему что-то не нравилось в потоке от stunnel и он обрывал соединение. Сейчас эти внешние IP добавлены в исключения и Ideco их не просматривает и на моей рабочей станции все работает.

Dmitry-G	#40 Оставлено : 16 декабря 2022 г. 10:36:36(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 08.12.2022(UTC) Сообщений: 17 Откуда: Москва	Автор: ИгорьК Автор: Dmitry-G Игорь, вопрос, что называется, «на засыпку»)) Как же у Вас, без изменения обозначенных выше сетевых настроек, раньше все заработало с одним сертификатом в справочнике? Не, я же написал, что на новой, чистой. Наши сетевики сделали новую виртуалку с прямым выходом в интернет — и там все отработало. Чуть раньше у нас был прокси, который просто пробрасывал соединение из локалки наружу. А теперь мы все через Ideco, а он по умолчанию анализирует весь трафик: ему что-то не нравилось в потоке от stunnel и он обрывал соединение. Сейчас эти внешние IP добавлены в исключения и Ideco их не просматривает и на моей рабочей станции все работает. Я просто хочу сказать, что на Вашей «рабочей станции все работает» не потому (или не только потому), что изменились сетевые настройки, а вероятно потому, что у Вас в хранилище HKLM (локального компьютера) как и на этой Вашей новой машине, всего один личный сертификат. Дело в том, что служба Stunnel, запущенная от имени локальной системы, смотрит в хранилище личных HKLM, а не HKCU (текущий пользователь) и ей абсолютно все равно, сколько и каких сертификатов установлено у Вас в HKCU. Могу конечно ошибаться с Вашим случаем, но очень на то похоже. Отредактировано пользователем 16 декабря 2022 г. 10:48:16(UTC) \| Причина: Не указана

Пользователи, просматривающие эту тему

Guest

Быстрый переход

Источник

Содержание

Troubleshooting SSL related issues (Server Certificate)
Tools Used in this Troubleshooter:
Overview
Scenarios
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario 5
Scenario 6
Troubleshooting SSL related issues (Server Certificate)
Tools Used in this Troubleshooter:
Overview
Scenarios
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario 5
Scenario 6

Tools Used in this Troubleshooter:

This material is provided for informational purposes only. Microsoft makes no warranties, express or implied.

Overview

This document will help you in troubleshooting SSL issues related to IIS only. Client Certificates troubleshooting will not be covered in this document. Server Certificates are meant for Server Authentication and we will be dealing only with Server Certificates in this document.

If the Client certificates section is set to «Require» and then you run into issues, then please don’t refer this document. This is meant for troubleshooting SSL Server certificates issue only.

It is important to know that every certificate comprises of a public key (used for encryption) and a private key (used for decryption). The private key is known only to the server.

The default port for https is 443.

I am under the assumption the reader is well-versed in SSL Handshake and the Server Authentication process during the SSL handshake.

Description of the Secure Sockets Layer (SSL) Handshake:

Description of the Server Authentication Process during the SSL Handshake:

Scenarios

The following error message is seen while browsing the website over https:

The first thing that has to be checked is whether the website is accessible over http. If it is not, there likely is a separate issue not covered here. You will need to have the website working on http first before continuing with this troubleshooter.

Now let’s assume the website is accessible over http and we get the above error when trying to browse over https. The problem is seen because the SSL handshake failed and hence the error message was seen. There could be many reasons. We will follow a step-by-step approach to solve this problem.

Scenario 1

Check if the server certificate has the private key corresponding to it. Refer the below picture:

If private key is missing, then you need to get a certificate containing the private key, which is essentially a .PFX file. There is a command that we could try to run in order to associate the private key with the certificate:

If the association is successful, then you would see the following window:

Note: 1a 1f 94 8b 21 a2 99 36 77 a8 8e b2 3f 42 8c 7e 47 e3 d1 33 is the thumbprint of the certificate. Open the certificate and click on the details tab. Scroll down to find the thumbprint section. Select the thumbprint section and click on the text below. Do a «Ctrl+A» and then «Ctrl+C» to select and copy it. Below is a snapshot for your reference:

Note: This command doesn’t succeed always. If this fails, then you need to get a certificate containing the private key from the CA. The file extension for a certificate containing private key is .pfx.

Scenario 2

We went pass the first hurdle and now we have a server certificate containing the private key installed on the website. However, we still get the same error as above. The website is still not accessible over https.

The SSLDiag tool comes in handy here.

Windows Server 2003:

Download X64 ( https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5329 )

Download X86 ( https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=674 )

For IIS 7 and IIS 7.5, use vijaysk’s SSL Diagnostics tool. Below is the link:

Install the tool and run it on the server. If you have a certificate containing private key and still not able to access the website, then you may want to run this tool or check the system event logs for SChannel related warnings/errors.

While running the SSLDiag tool you may get the following error:

You have a private key that corresponds to this certificate but CryptAcquireCertificatePrivateKey failed

There will also be a SChannel warning in the system event logs as shown below:

Event Type: Error
Event Source: Schannel
Event Category: None
Event ID: 36870
Date: 2/11/2012
Time: 12:44:55 AM
User: N/A
Computer:
Description: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x80090016.

This event/error indicates that there was a problem acquiring certificate’s private key. So let’s try the below steps one by one:

Firstly, verify the permissions on the machinekeys folder as per the KB Article: https://support.microsoft.com/kb/278381. All the private keys are stored within the machinekeys folder, so we need to ensure that we have necessary permissions.

If the permissions are in place and if the issue is still not fixed. Then it must be a problem with the certificate. It may have been corrupted (You may see an error code of 0x8009001a in the SChannel event log).

Event Type: Error
Event Source: Schannel
Event Category: None
Event ID: 36870
Date: 2/11/2012
Time: 12:44:55 AM
User: N/A
Computer:
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009001a.

We will test if the website works with a test certificate. Take a back-up of the existing certificate and then replace it with a self-signed certificate. Try accessing the website via https. If it works then the certificate used earlier was corrupted and it has to be replaced with a new working certificate.

Sometimes the problem may not be with the certificate but with the issuer. You may see the following error in SSLDiag:

CertVerifyCertificateChainPolicy will fail with CERT_E_UNTRUSTEDROOT (0x800b0109), if the root CA certificate is not trusted root.

To fix this add the CA’s certificate to the «Trusted Root CA» store under My computer account on the server.

You may also get the following error:

CertVerifyCertificateChainPolicy returned error -2146762480(0x800b0110).

If the above error is received then we need to check the usage type of the certificate. Open the certificate, click on the «Details» tab and then click on «Edit Properties…» button. Under General tab make sure «Enable all purposes for this certificate» is selected and most importantly «Server Authentication» should be present in the list.

Scenario 3

The first 2 steps check the integrity of the certificate. Once we have confirmed that there are no issues with the certificate, a big problem is solved. But, what if the website is still not accessible over https. Check the HTTPS bindings of the website and determine what port and IP it is listening on. You could run the following command to ensure no other process is listening on the SSL port used by the website.

If there is another process listening on that port then check why that process is consuming that port. Try changing the IP-Port combination to check if the website is accessible or not.

Scenario 4

By now we are sure that we have a proper working certificate installed on the website and there is no other process using the SSL port for this website. However, I still get «Page cannot be displayed» error while accessing over https. When a client connects and initiates an SSL negotiation, HTTP.sys looks in its SSL configuration for the «IP:Port» pair to which the client connected. The HTTP.sys SSL configuration must include a certificate hash and the name of the certificate store before the SSL negotiation will succeed. The problem may be with the HTTP.SYS SSL Listener.

The Certificate hash registered with HTTP.SYS may be NULL or it may contain invalid GUID. Execute the following from a command prompt:

httpcfg is part of Windows Support tools and is present on the installation disk. You could download it from here as well: https://www.microsoft.com/download/en/details.aspx?id=7911

Below is a sample of a working and non-working scenario:

Working scenario:

Configuration	Setting
IP	0.0.0.0:443
Hash
Guid
CertStoreName	MY
CertCheckMode
RevocationFreshnessTime
UrlRetrievalTimeout
SslCtlIdentifier
SslCtlStoreName
Flags

Non-working scenario:

Configuration	Setting
IP	0.0.0.0:443
Hash	c09b416d6b 8d615db22 64079d15638e96823d
Guid
CertStoreName	MY
CertCheckMode
RevocationFreshnessTime
UrlRetrievalTimeout
SslCtlIdentifier
SslCtlStoreName
Flags

The Hash value seen above is the Thumbprint of your SSL certificate. Notice, that the Guid is all zero in a non-working scenario. You may see the Hash either having some value or blank. Even if we remove the certificate from the web site, and then run «httpcfg query ssl», the website will still list Guid as all 0’s. If you see the GUID as «<0000. 000>, then there is a problem.

We need to remove this entry by running the command:

Delete any entries in the IP Listen list.

To determine whether any IP addresses are listed, open a command prompt, and then run the following command:

If the IP Listen list is empty, the command returns the following string:

If the command returns a list of IP addresses, remove each IP address in the list by using the following command:

restart IIS after this via command «net stop http /y»

Scenario 5

After all this if you are still unable to browse the website on https, then capture a network trace either from the client or server. Filter the trace by «SSL or TLS» to look at SSL traffic.

Below is a network trace snapshot of a non-working scenario:

Well, this is definitely now how you look at a network trace. You need to expand the frame details and see what protocol and cipher was chosen by the server. Select «Server Hello» from the description to get those details.

In the non-working scenario, the client was configured to use TLS 1.1 and TLS 1.2 only. However, the web server was IIS 6, which can support until TLS 1.0 and hence the handshake failed.

Do check the registry keys to determine what protocols are enabled or disabled. Here’s the path:

The «Enabled» DWORD should be set to «1». If «0» then the protocol is disabled.

For example, SSL 2.0 is disabled by default.

Scenario 6

If everything has been verified and if you are still running into issues accessing the website over https, then it most likely is some update which is causing the SSL handshake to fail.

Microsoft has released an update to the implementation of SSL in Windows:

There is potential for this update to impact customers using Internet Explorer, or using an application that uses Internet Explorer to perform HTTPS requests.

There were actually two changes made to address information disclosure vulnerability in SSL 3.0 / TLS 1.0. The MS12-006 update implements a new behavior in schannel.dll, which sends an extra record while using a common SSL chained-block cipher, when clients request that behavior. The other change was in Wininet.dll, part of the December Cumulative Update for Internet Explorer (MS11-099), so that IE will request the new behavior.

If a problem exists, it may manifest as a failure to connect to a server, or an incomplete request. Internet Explorer 9 is able to display an «Internet Explorer cannot display the webpage» error. Prior versions of IE may simply display a blank page.

Fiddler does not use the extra record when it captures and forwards HTTPS requests to the server. Therefore, if Fiddler is used to capture HTTPS traffic, the requests will succeed.

Registry keys

As documented in https://support.microsoft.com/kb/2643584, there is a SendExtraRecord registry value, which can:

Globally disable the new SSL behavior
Globally enable it, or
(Default) enable it for SChannel clients that opt in to the new behavior.

Источник

Tools Used in this Troubleshooter:

This material is provided for informational purposes only. Microsoft makes no warranties, express or implied.

Overview

If the Client certificates section is set to «Require» and then you run into issues, then please don’t refer this document. This is meant for troubleshooting SSL Server certificates issue only.

It is important to know that every certificate comprises of a public key (used for encryption) and a private key (used for decryption). The private key is known only to the server.

The default port for https is 443.

I am under the assumption the reader is well-versed in SSL Handshake and the Server Authentication process during the SSL handshake.

Description of the Secure Sockets Layer (SSL) Handshake:

Description of the Server Authentication Process during the SSL Handshake:

Scenarios

The following error message is seen while browsing the website over https:

Scenario 1

Check if the server certificate has the private key corresponding to it. Refer the below picture:

If the association is successful, then you would see the following window:

Scenario 2

The SSLDiag tool comes in handy here.

Windows Server 2003:

Download X64 ( https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5329 )

Download X86 ( https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=674 )

For IIS 7 and IIS 7.5, use vijaysk’s SSL Diagnostics tool. Below is the link:

While running the SSLDiag tool you may get the following error:

You have a private key that corresponds to this certificate but CryptAcquireCertificatePrivateKey failed

There will also be a SChannel warning in the system event logs as shown below:

Event Type: Error
Event Source: Schannel
Event Category: None
Event ID: 36870
Date: 2/11/2012
Time: 12:44:55 AM
User: N/A
Computer:
Description: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x80090016.

This event/error indicates that there was a problem acquiring certificate’s private key. So let’s try the below steps one by one:

Event Type: Error
Event Source: Schannel
Event Category: None
Event ID: 36870
Date: 2/11/2012
Time: 12:44:55 AM
User: N/A
Computer:
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009001a.

Sometimes the problem may not be with the certificate but with the issuer. You may see the following error in SSLDiag:

CertVerifyCertificateChainPolicy will fail with CERT_E_UNTRUSTEDROOT (0x800b0109), if the root CA certificate is not trusted root.

To fix this add the CA’s certificate to the «Trusted Root CA» store under My computer account on the server.

You may also get the following error:

CertVerifyCertificateChainPolicy returned error -2146762480(0x800b0110).

If the above error is received then we need to check the usage type of the certificate. Open the certificate, click on the «Details» tab and then click on «Edit PropertiesвЂ¦» button. Under General tab make sure «Enable all purposes for this certificate» is selected and most importantly «Server Authentication» should be present in the list.

Scenario 3

If there is another process listening on that port then check why that process is consuming that port. Try changing the IP-Port combination to check if the website is accessible or not.

Scenario 4

The Certificate hash registered with HTTP.SYS may be NULL or it may contain invalid GUID. Execute the following from a command prompt:

httpcfg is part of Windows Support tools and is present on the installation disk. You could download it from here as well: https://www.microsoft.com/download/en/details.aspx?id=7911

Below is a sample of a working and non-working scenario:

Working scenario:

Configuration	Setting
IP	0.0.0.0:443
Hash
Guid
CertStoreName	MY
CertCheckMode
RevocationFreshnessTime
UrlRetrievalTimeout
SslCtlIdentifier
SslCtlStoreName
Flags

Non-working scenario:

Configuration	Setting
IP	0.0.0.0:443
Hash	c09b416d6b 8d615db22 64079d15638e96823d
Guid
CertStoreName	MY
CertCheckMode
RevocationFreshnessTime
UrlRetrievalTimeout
SslCtlIdentifier
SslCtlStoreName
Flags

We need to remove this entry by running the command:

Delete any entries in the IP Listen list.

To determine whether any IP addresses are listed, open a command prompt, and then run the following command:

If the IP Listen list is empty, the command returns the following string:

If the command returns a list of IP addresses, remove each IP address in the list by using the following command:

restart IIS after this via command «net stop http /y»

Scenario 5

After all this if you are still unable to browse the website on https, then capture a network trace either from the client or server. Filter the trace by «SSL or TLS» to look at SSL traffic.

Below is a network trace snapshot of a non-working scenario:

In the non-working scenario, the client was configured to use TLS 1.1 and TLS 1.2 only. However, the web server was IIS 6, which can support until TLS 1.0 and hence the handshake failed.

Do check the registry keys to determine what protocols are enabled or disabled. Here’s the path:

The «Enabled» DWORD should be set to «1». If «0» then the protocol is disabled.

For example, SSL 2.0 is disabled by default.

Scenario 6

If everything has been verified and if you are still running into issues accessing the website over https, then it most likely is some update which is causing the SSL handshake to fail.

Microsoft has released an update to the implementation of SSL in Windows:

There is potential for this update to impact customers using Internet Explorer, or using an application that uses Internet Explorer to perform HTTPS requests.

Fiddler does not use the extra record when it captures and forwards HTTPS requests to the server. Therefore, if Fiddler is used to capture HTTPS traffic, the requests will succeed.

Registry keys

As documented in https://support.microsoft.com/kb/2643584, there is a SendExtraRecord registry value, which can:

Globally disable the new SSL behavior
Globally enable it, or
(Default) enable it for SChannel clients that opt in to the new behavior.

Источник

Remove From My Forums

Question
Hi there,

I have an application set up for deployment, but it seems installation is not starting on client.

After a few minutes from deployment I can see the state under «Unknown» tab with a state on the machine like «Client checks validated» (don’t now what it’s called in English exactly).

Will the installation start at a later time or will I wait forever? Is there a way to push installation a bit if there should be a waiting time?

Thanks for any help,
Melampous

Answers

BGB has nothing to do with installing applications. That component is used when you force an update of policies using the console. That’s not really needed. The client will check for policies every 60min (default) automatically. It also takes a while until
the state is sent to the site. Nothing is happening in real time.

Torsten Meringer | http://www.mssccmfaq.de
- Marked as answer by
  
  Saturday, May 3, 2014 6:54 PM

Источник

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ
Andrey, [05.10.18 11:28]
[В ответ на Дмитрий Давидович]
У них кривой сертификат сервера.
Диагностировать можно так:
[root@test-x64-centos7 ~]# /opt/cprocsp/bin/amd64/csptestf -tlsc -server zakupki.gov.ru -v -nosave -savecert /tmp/t.p7b
[root@test-x64-centos7 ~]# /opt/cprocsp/bin/amd64/certmgr -list -file /tmp/t.p7b
=============================================================================
1——-
Issuer              : E=uc_fk@roskazna.ru, S=г. Москва, INN=007710568760, OGRN=1047797019830, STREET=»улица Ильинка, дом 7″, L=Москва, C=RU, O=Федеральное казначейство, CN=Федеральное казначейство
Subject             : INN=007710568760, OGRN=1047797019830, STREET=»ул. Проспект Мира, 105″, E=777@roskazna.ru, C=RU, S=г. Москва, L=Москва, O=Федеральное казначейство, CN=zakupki.gov.ru
Serial              : 0x6F064FA71C24CD7E2CE6FAAEA927D8C7EC69A35F
SHA1 Hash           : c369b560ce239beddb2fc12b4884dee1cfc923aa
SubjKeyID           : 10c6d12e7cd886d022bcdfea4cbe10e32acf82bc
Signature Algorithm : ГОСТ Р 34.11/34.10-2001
PublicKey Algorithm : ГОСТ Р 34.10-2001 (512 bits)
Public key          : 04 40 1b ce 0b 15 6a 4a 57 e0 1b d8 39 ee 86 83
                      32 70 ea db fd f5 39 c1 e6 de 3c c8 be 10 81 03
                      5d da 0b 3b 09 7a d3 0d 46 33 58 11 3b 20 94 99
                      fe 04 fe 8e e6 bc 32 53 ff 2e 71 10 8e e2 12 a1
                      52 cf
Not valid before    : 21/12/2017 06:06:33 UTC
Not valid after     : 21/03/2019 06:06:33 UTC
PrivateKey Link     : No
Subject Alt Names
UPN               : ▒㌴ (2.5.4.12)
URL               : 0
CDP                 : http://crl.roskazna.ru/crl/ucfk.crl
CDP                 : http://crl.fsfk.local/crl/ucfk.crl
Extended Key Usage : 1.3.6.1.5.5.7.3.1
…

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ
Andrey, [05.10.18 11:35]
Но мы сделали параметр для отключения требований RFC6125, который может подвергнуть систему опасности для атак с подменой сертификатов:
[root@test-x64-centos7 ~]# /opt/cprocsp/sbin/amd64/cpconfig -ini ‘configparameters’ -add long Rfc6125_NotStrict_ServerName_Check 1
[root@test-x64-centos7 ~]# /opt/cprocsp/bin/amd64/csptestf -tlsc -server zakupki.gov.ru -nosave
HDEContext expired: OK if file is completely downloaded
Reply status: HTTP/1.1 200 OK
1 connections, 586 bytes in 0.186 seconds;
Total: SYS: 0,020 sec USR: 0,140 sec UTC: 0,230 sec
[ErrorCode: 0x00000000]

L K, [15.12.18 14:12]
[В ответ на Andrey]
root@astra:~# /opt/cprocsp/sbin/amd64/cpconfig -ini ‘configparameters’ -add long Rfc6125_NotStrict_ServerName_Check 1
root@astra:~# /opt/cprocsp/bin/amd64/csptestf -tlsc -server zakupki.gov.ru -nosave
HSECPKG_ATTR_PACKAGE_INFO not supported.
Error 0x800b010f (CERT_E_CN_NO_MATCH) returned by CertVerifyCertificateChainPolicy!
An error occurred in running the program.
/dailybuildsbranches/CSP_4_0/CSPbuild/CSP/samples/csptest/WebClient.c:764:Error authenticating server credentials!
Error number 0x800b010f (2148204815).
CN-имя сертификата не совпадает с полученным значением.
Total: SYS: 0,070 sec USR: 0,290 sec UTC: 1,720 sec
[ErrorCode: 0x800b010f]

Какой релиз КриптоПро нужно ставить?

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

user@astra:~$ /opt/cprocsp/bin/amd64/csptest -keyset -verifycontext
CSP (Type:80) v4.0.9019 KC2 Release Ver:4.0.9963 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 26834115
GetProvParam(PP_NAME): Crypto-Pro GOST R 34.10-2012 KC2 CSP
Total: SYS: 0,000 sec USR: 0,000 sec UTC: 0,020 sec
[ErrorCode: 0x00000000]

user@astra:~$ sudo /opt/cprocsp/sbin/amd64/cpconfig -ini ‘configparameters’ -add long Rfc6125_NotStrict_ServerName_Check 1

user@astra:~$ sudo /opt/cprocsp/bin/amd64/csptestf -tlsc -server zakupki.gov.ru -nosave
HSECPKG_ATTR_PACKAGE_INFO not supported.
DContext expired: OK if file is completely downloaded
Reply status: HTTP/1.1 200 OK
1 connections, 589 bytes in 1.221 seconds;
Total: SYS: 0,040 sec USR: 0,320 sec UTC: 1,300 sec
[ErrorCode: 0x00000000]

Для 4.0.9944
user@astra:~$ /opt/cprocsp/bin/amd64/csptest -keyset -verifycontext
CSP (Type:80) v4.0.9017 KC2 Release Ver:4.0.9944 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 20066515
GetProvParam(PP_NAME): Crypto-Pro GOST R 34.10-2012 KC2 CSP
Total: SYS: 0,000 sec USR: 0,000 sec UTC: 0,030 sec
[ErrorCode: 0x00000000]
user@astra:~$ sudo /opt/cprocsp/sbin/amd64/cpconfig -ini ‘configparameters’ -add bool Rfc6125_NotStrict_ServerName_Check true
user@astra:~$ sudo /opt/cprocsp/bin/amd64/csptestf -tlsc -server zakupki.gov.ru -nosave
HSECPKG_ATTR_PACKAGE_INFO not supported.
DContext expired: OK if file is completely downloaded
Reply status: HTTP/1.1 200 OK
1 connections, 589 bytes in 0.388 seconds;
Total: SYS: 0,050 sec USR: 0,200 sec UTC: 0,450 sec
[ErrorCode: 0x00000000]

Источник

Mark Ciccarello

unread,

Dec 19, 2003, 9:02:14 PM12/19/03

I’m trying to get L2TP/IPSEC VPN to work with EAP-TLS
client authentication. The VPN works fine with CHAP2
authentication.

Setup:

Client — XP
VPN — RAS on W2K3
Authentication — IAS on W2K3

[all patched and up to date; but these are NOT domain machines]

I have valid X.509 certificate on server. It is 3rd party;
the key was made with SChannel CSP and the server
certificate has the Server Auth EKU.

When I construct a remote access policy on IAS, the only
two authentication methods that appear are MD5 and PEAP.
There is no indication regarding EAP-TLS.

If I try to make an EAP-TLS based connection from the
client; then RAS tracing on the IAS indicates that no
server name could be found on the certificate during EAP
setup.

Any ideas ?
Thanks,
Mark Ciccarello

Ashwin Palekar(MS)

unread,

Dec 21, 2003, 2:47:42 AM12/21/03

Is the IAS server a member of a domain? EAP-TLS option is available only if
IAS is member of domain.

—
—
===========================================================
This posting is provided «AS IS» with no warranties and confers no rights
===========================================================

«Mark Ciccarello» <anon…@discussions.microsoft.com> wrote in message
news:0b6b01c3c65a$3bce7bd0$a601…@phx.gbl…

Mark Ciccarello

unread,

Dec 21, 2003, 6:28:46 PM12/21/03

The IAS server was not a domain member at first.

I put it into a domain and the EAP-TLS option showed
up in the Remote Access Policy. So far so good.

But certificate/smart card client still cannot connect.
The client side error is 0x8009030C.

The IAS error in the RASTLS tracing file is:
——————————————
[2108] 10:16:23:086: AuthenticateUser
[2108] 10:16:23:086: FGetEKUUsage
[2108] 10:16:23:086: FCheckPolicy
[2108] 10:16:23:096: CertVerifyCertificateChainPolicy
succeeded but policy check failed 0x800b0112.
[2108] 10:16:23:096: FCheckPolicy done.
[2108] 10:16:23:096: The user’s cert does not have
correct usage.
[2108] 10:16:23:096: MakeAlert(49, Manual)
[2108] 10:16:23:096: State change to SentFinished. Error:
0x800b0112
[2108] 10:16:23:096: BuildPacket
[2108] 10:16:23:096: << Sending Request (Code: 1) packet:
Id: 6, Length: 17, Type: 13, TLS blob length: 7. Flags: L
[1960] 10:16:23:096:
[1960] 10:16:23:106: EapTlsMakeMessage(labnetmark)
[1960] 10:16:23:106: >> Received Response (Code: 2)
packet: Id: 6, Length: 6, Type: 13, TLS blob length: 0.
Flags:
[1960] 10:16:23:106: EapTlsSMakeMessage
[1960] 10:16:23:106: Negotiation unsuccessful
[1960] 10:16:23:106: BuildPacket
[1960] 10:16:23:106: << Sending Failure (Code: 4) packet:
Id: 6, Length: 4, Type: 0, TLS blob length: 0. Flags:
[1960] 10:16:23:106: AuthResultCode = (-2146762478),
bCode = (4)

————————————

The error in the IASSAM tracing is:

[2108] 12-21 10:16:23:096: Issuing Access-Challenge.
[1960] 12-21 10:16:23:096: NT-SAM EAP handler received
request.
[1960] 12-21 10:16:23:096: Successfully retrieved session
state for user LABNETmark.
[1960] 12-21 10:16:23:106: Processing output from EAP DLL.
[1960] 12-21 10:16:23:106: Inserting outbound EAP-Message
of length 4.
[1960] 12-21 10:16:23:106: EAP authentication failed: A
certification chain processed correctly, but one of the
CA certificates is not trusted by the policy provider.

——————————————————

Is this an error in the client side certs or a problem
on the server side?

This is a 3rd party CA; it is only one deep; the CA
signs the client and server certs directly.

I suspect it may not be registered correctly in the
domain.

The CA cert is correctly installed in the trusted
root certification authorities.

However, certutil -dcInfo indicates that there are
no CA certs in the Ent Root Store.

What is meant by the «policy provider». How do I get
it to trust the CA cert ?

>.
>

Ashwin Palekar(MS)

unread,

Dec 21, 2003, 8:25:49 PM12/21/03

To verify if the cert is trusted —> Using MMC certificate snap-in, view the
client cert on the RADIUS server; and the RADIUS server cert on the client.
MMC will show if the cert is trusted on the machine.

The policy may occur due to the following —> In addition to verifying
trust in certificate, IAS verifies that the account in AD refers to the
corresponding certificate. In other words, the cert must be mapped to a
account in AD. You can map all certificates issued by 3rd party CA to 1
account or individual accounts in AD. The later method is preferred. Refer
to Windows 2003 IAS online help for details on how to configure IAS to use
account mapping.

—
—
===========================================================

This posting is provided «AS IS» with no warranties and confers no rights
===========================================================

news:001601c3c7d7$1faf8b00$a101…@phx.gbl…

Mark Ciccarello

unread,

Dec 21, 2003, 10:14:55 PM12/21/03

Regarding Point A)

Certs are trusted — verified.

Regarding Point B)

User cert was not previously mapped. I successfully
did a one-to-one mapping in AD.

No change in result. Fails with the same errors.

I also tried a many to one mapping.

No change in result. Fails with the same errors.

Any further suggestions would be much appreciated.

To summarize.
The client cert was made with Microsoft SChannel CSP.
Has EKU client auth.

Is there an issue regarding registration of the CA
certificate with AD ?

Thanks,
Mark C.

>——Original Message——
>To verify if the cert is trusted —> Using MMC
certificate snap-in, view the
>client cert on the RADIUS server; and the RADIUS server
cert on the client.
>MMC will show if the cert is trusted on the machine.
>
>The policy may occur due to the following —> In
addition to verifying
>trust in certificate, IAS verifies that the account in
AD refers to the
>corresponding certificate. In other words, the cert must
be mapped to a
>account in AD. You can map all certificates issued by
3rd party CA to 1
>account or individual accounts in AD. The later method
is preferred. Refer
>to Windows 2003 IAS online help for details on how to
configure IAS to use
>account mapping.
>
>
>—
>—

>=========================================================
==
>This posting is provided «AS IS» with no warranties and
confers no rights
>=========================================================
==
>
>»Mark Ciccarello» <anon…@discussions.microsoft.com>
wrote in message

>.
>

Ashwin Palekar(MS)

unread,

Dec 21, 2003, 10:39:24 PM12/21/03

Mark,

The error message says «The user’s cert does not have correct usage.» which
could mean the right contents (Client authentication EKU et al).

Does the client cert meet ALL the requirements of mentioned in W2k3 IAS
online help for certificate requirements? Does it have any extra EKUs like
Smartcard Logon EKUs?

Regards,

Ashwin

—
—
===========================================================

This posting is provided «AS IS» with no warranties and confers no rights
===========================================================

news:011b01c3c7f6$b7b01b80$a101…@phx.gbl…

Mark Ciccarello

unread,

Dec 22, 2003, 12:27:34 AM12/22/03

Ashwin —

Attached are the results of running certutil -verify
against the user cert in question. The lack of
revocation capability may be the issue here.

[the names have been changed in the output]

Mark
———————————————————
Issuer:
CN=Our CA
OU=Our OU
O=Our O
C=US
Subject:
CN=mark
OU=Our OU
O=Our O
C=US
Cert Serial Number: 15cdae52bf2b8c3c

dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags =
CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT
(0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
——— CERT_CHAIN_CONTEXT ———
ChainContext.dwInfoStatus =
CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwErrorStatus =
CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

SimpleChain.dwInfoStatus =
CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwErrorStatus =
CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

CertContext[0][0]: dwInfoStatus=101 dwErrorStatus=40
Issuer: CN=Our CA, OU=Our OU, O=Our O, C=US
Subject: CN=mark, OU=Our OU, O=Our O, C=US
Serial: 15cdae52bf2b8c3c
8b de 96 88 c8 b0 8f ee 6d 8b 74 ab 55 d8 a5 62 03 5d
38 ee
Element.dwInfoStatus =
CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER
(0x100)
Element.dwErrorStatus =
CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication

CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=Our CA, OU=Our OU, O=Our O, C=US
Subject: CN=Our CA, OU=Our OU, O=Our O, C=US
Serial: 373cee6665cb0827
b0 74 51 dd 26 ef a7 f9 b9 38 56 90 a2 61 e9 61 9f 3e
83 8e
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER
(0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER
(0x100)

Exclude leaf cert:
8b de 96 88 c8 b0 8f ee 6d 8b 74 ab 55 d8 a5 62 03 5d
38 ee
Full chain:
70 47 e3 43 80 8e 5e fc 53 aa b0 e4 49 9a db 3e 53 ad
42 f4
Issuer: CN=Our CA, OU=Our OU, O=Our O, C=US
Subject: CN=mark, OU=Our OU, O=Our O, C=US
Serial: 15cdae52bf2b8c3c
8b de 96 88 c8 b0 8f ee 6d 8b 74 ab 55 d8 a5 62 03 5d
38 ee
The revocation function was unable to check revocation
for the certificate. 0x80
092012 (-2146885614)
————————————
Revocation check skipped — no revocation information
available
Cert is an End Entity certificate
Cannot check leaf certificate revocation status
CertUtil: -verify command completed successfully.

——————————————

>——Original Message——
>Mark,
>
>The error message says «The user’s cert does not have
correct usage.» which
>could mean the right contents (Client authentication EKU
et al).
>
>Does the client cert meet ALL the requirements of
mentioned in W2k3 IAS
>online help for certificate requirements? Does it have
any extra EKUs like
>Smartcard Logon EKUs?
>
>
>Regards,
>
>Ashwin
>
>
>
>
>—
>—

>.
>

Thomas Kuborn

unread,

Dec 22, 2003, 11:13:06 AM12/22/03

Hey Ashwin

Are you sure about the part that says that IAS verifies if the client
certificate is published in AD ? I thought IAS verified if the user account
existed in AD
Seems weird to me because :
— only some certificate templates are published in AD (user template)
automatically, the authenticated session user template does publish certs in
AD
— this would hinder scalability if you use a certificate template that does
not publish certs in AD

— Thomas —

«Ashwin Palekar(MS)» <ash…@online.microsoft.com> wrote in message
news:eQVx$d%23xDH…@TK2MSFTNGP12.phx.gbl…

Mark Ciccarello

unread,

Dec 22, 2003, 4:28:59 PM12/22/03

Thomas —

I think the statement was that the certificate needs to
be mapped to an account. Whether the certificate is
published in AD is another matter, no ?

Mark

==========================================================
=

>> This posting is provided «AS IS» with no warranties
and confers no rights
>>

==========================================================
=
>>
>> «Mark Ciccarello»

>.
>

Thomas Kuborn

unread,

Dec 22, 2003, 5:12:48 PM12/22/03

Hi Mark,

Well, I would have thought the 2 would have come together no ?
I mean, if a user account is mapped to a certificate that must mean the
certificate has been published in AD under that user’s account right ?
I don’t see any other place than AD where the mapping could be done … or
am I wrong ? Please explain !

— Thomas —

news:039301c3c88f$8edd4450$a001…@phx.gbl…

Mark Ciccarello

unread,

Dec 22, 2003, 6:15:30 PM12/22/03

Thomas —

The issue here was that I have in the lab a third party
CA that was not connected to AD. I am having a problem
getting an EAP-TLS based VPN to work. The problem
revolves around policy checking of the client cert by IAS.

Ashwin suggested I make sure that the client cert was
mapped to an account in the domain. It was not; I did the
mapping by means of the Name Mapping action on the user
account in question.

But publishing a cert for the same user account involved
another different action. In other words, even after I
had mapped the cert, the user account did not reflect any
published certs.

Mark

>.
>

Thomas Kuborn

unread,

Dec 23, 2003, 2:50:06 AM12/23/03

I should have read the post more carefully

sorry !!

news:07dc01c3c89e$6fb1ff30$a401…@phx.gbl…

Mark Ciccarello

unread,

Dec 28, 2003, 9:11:26 PM12/28/03

Ashwin —

I finally discovered that the problem did not center on
CRL’s. IAS CRL checking can be turned off by means of
registry settings.

Instead, the problem was that the certificate of the
3rd party root was not in the Enterprise certificate
store NTAuth. This is a requirement for smart card login.
[It can be conveniently addess with certutil -addstore —
enterprise NTauth <cert>

I can’t find a proper reference in IAS documentation;
but, it is clearly a requirement.

Mark C.

>.
>

Источник

You should be aware of RFC3280 section 6.1 and RFC5280 section 6.1. Both describe algorithms for validating certificate paths. Even though Win32 API takes care of some things for you, it could still be valuable to know about the process in general.

Also, here’s a (in my opinion) pretty trustworthy reference: Chromium certificate verification code.

Overall, I think your code isn’t incorrect. But here’s a few things I’d look into/change, if I were you:

1. Separate Common Name Validation

Chromium validates certificate common name separately from the chain. Apparently they’ve noticed some problems with it. See the comments for their rationale:

cert_verify_proc.win.cc:731 // Certificate name validation happens separately, later, using an internal
cert_verify_proc.win.cc:732 // routine that has better support for RFC 6125 name matching.

2. Use CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT

Chromium also uses the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag instead of CERT_CHAIN_REVOCATION_CHECK_CHAIN. I actually started to looking into this before I found their code, and it reinforced my belief that you should use CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT.

Even though both aforementioned RFCs specify that a self-signed trust anchor is not considered part of a chain, the documentation for CertGetCertificateChain (http://msdn.microsoft.com/en-us/library/windows/desktop/aa376078(v=vs.85).aspx) says it builds a chain up to, if possible, a trusted root certificate. A trusted root certificate is defined (on the same page) as a trusted self-signed certificate.

This eliminates the possibility that *EXCLUDE_ROOT might skip revocation checking for a non-root trust anchor (Win32 actually requires trust-anchors to be self-signed, even though it is not required by any RFCs. Though this is not officially documented).

Now, since a root CA certificate can not revoke itself (the CRL could not be signed/verified), it seems to me that these two flags are identical.

I did some googling and stumbled across this forum post: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/9f95882a-1a68-477a-80ee-0a7e3c7ae5cf/x509revocationflag-question?forum=windowssecurity. A member of .NET Product Group (supposedly) claims that the flags in practice act the same, if the root is self-signed (in theory, the ENTIRE_CHAIN flag would check the root certificate for revocation if it included a CDP extension, but that can’t happen).

He also recommends to use the *EXCLUDE_ROOT flag, because the other flag could cause an unnecessary network request, if the self-signed root CA includes the CDP extension.

Unfortunately:

I can’t find any officially documented explanation on the differences between the two flags.
Even though it is likely that the linked discussion applies to the same Win32 API flags under the hood of .NET, it is not guaranteed.

To be completely sure that it’s ok to use CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT, I googled a bit more and found the Chromium SSL certificate verification code I linked to at the top of my reply.

As an added bonus, the Chromium cert_verify_proc_win.cc file contains the following hints about IE verification code:

618: // IE passes a non-NULL pTime argument that specifies the current system
619: // time.  IE passes CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT as the
620: // chain_flags argument.

Not sure how they’d know this, but at this point I’d feel comfortable using CERT_CHAIN_REVOCATION_CHECK_EXCLUDE_ROOT.

3. Different Accepted Certificate Usages

I noticed Chromium also specifies 3 certificate usages instead of 1:

szOID_PKIX_KP_SERVER_AUTH,
szOID_SERVER_GATED_CRYPTO,
szOID_SGC_NETSCAPE

From what I can gather through Google, the other usages can be required by older web browsers, otherwise they can fail to establish a secure connection.

If Chromium deems fit to include these usages, I’d follow suit.

Note that if you change your code, you should also set params.RequestedUsage.dwType to USAGE_MATCH_TYPE_OR instead of USAGE_MATCH_TYPE_AND.

—

I can’t think of any other comments at the moment. But if I were you, I’d check out Chromium source myself (and maybe Firefox too) — just to be sure I haven’t missed anything.

Источник

1С и Linux

суббота, 15 декабря 2018 г.

Доступ zakupki.gov.ru Not Secure