Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

2 Страницы12>
Опции
К последнему сообщению К первому непрочитанному
Offline auglov  
#1 Оставлено : 5 апреля 2018 г. 21:25:13(UTC)
auglov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 25.12.2014(UTC)
Сообщений: 76

Сказал(а) «Спасибо»: 3 раз
Здравствуйте.

Есть приложение, которое является клиентом для двух других сервисов, подключение HTTPS по ГОСТ c двухсторонней аутентификацией, и там, и там.

К одному из них подключение проходит нормально и клиентский сертификат успешно передается:

Код:

FINE: Certificate request is received.
апр 05, 2018 11:06:00 PM ru.CryptoPro.ssl.f a
FINE: Add certificate algorithm: GOST3410EL [priority: 2]
апр 05, 2018 11:06:00 PM ru.CryptoPro.ssl.ao a
FINE: Find client container with type: GOST3410EL
апр 05, 2018 11:06:00 PM ru.CryptoPro.ssl.r a
FINE: %% getting aliases for Client
апр 05, 2018 11:06:00 PM ru.CryptoPro.ssl.r a
FINER: %% check public key algorithm
апр 05, 2018 11:06:00 PM ru.CryptoPro.ssl.r a
FINER: %% check extended key usage (size: 2)
апр 05, 2018 11:06:00 PM ru.CryptoPro.ssl.r a
FINER: %% check extended key usage of Client
апр 05, 2018 11:06:00 PM ru.CryptoPro.ssl.r a
FINER: %% check credential issuers
апр 05, 2018 11:06:00 PM ru.CryptoPro.ssl.r a
FINE: %% matching alias: aiskjp2018
апр 05, 2018 11:06:00 PM ru.CryptoPro.ssl.ao a
FINE: Found containers: 1
апр 05, 2018 11:06:00 PM ru.CryptoPro.ssl.ao a
FINE: Certificate 'aiskjp2018' matches...
апр 05, 2018 11:06:00 PM ru.CryptoPro.ssl.a.a c
FINER: Signature algorithm: GOST3411withGOST3410EL by key algorithm : GOST3410DHEL
апр 05, 2018 11:06:00 PM ru.CryptoPro.JCP.tools.Gost2001Warning warn


К другому нет, и не понятно, почему сертификат не подходит:

Код:

апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.ao a
FINE: Certificate request is received.
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.f a
FINE: Add certificate algorithm: GOST3410EL [priority: 2]
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.ao a
FINE: Find client container with type: GOST3410EL
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
FINE: %% getting aliases for Client
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
FINER: %% check public key algorithm
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
FINER: %% check extended key usage (size: 2)
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
FINER: %% check extended key usage of Client
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
FINER: %% check credential issuers
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
WARNING: %% No alias is match
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.ao a
FINE: Found containers: 0
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.ao a
FINE: Find any client container with type: GOST3410EL
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
FINE: %% getting aliases for Client
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
FINER: %% check public key algorithm
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
FINER: %% check extended key usage (size: 2)
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
FINER: %% check extended key usage of Client
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
FINER: %% check credential issuers
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.r a
WARNING: %% No alias is match
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.ao a
FINE: Select any private key for signature. Found containers: 0
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.ao a
FINE: %% Certificate message:
------
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.a.a b
FINER: Ephemeral algorithm: GOST3410DHELEPH by public key parameters: 1.2.643.2.2.19
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.a.a c
FINER: Ephemeral provider: Crypto by public key parameters: 1.2.643.2.2.19
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.at d
FINE: Ephemeral key generator: GOST3410DHELEPH, Crypto
апр 05, 2018 10:36:28 PM ru.CryptoPro.ssl.a.a a
FINER: Secret key provider: Crypto by public key algorithm : GOST3410EL


В чем разница - не понятно. Логи в остальном практически совпадают.
Известно, что корневой сертификат для сервиса, с которым все работает, совпадает с корневым для нашего клиентского сертификата. Где не работает - там совсем другая цепочка.

JCP-2.0.38830. Пробовали 2.0.39442 - стало хуже - рвется соединение даже там, где раньше работало.

Совет из этой темы http://www.cryptopro.ru/...aspx?g=posts&m=53399 поменять местами провайдеры пробовали. Не помогает, даже если JCP ставить первыми, и у нас нет BC.
Offline Андрей Писарев  
#2 Оставлено : 5 апреля 2018 г. 21:44:58(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 12,691
Мужчина
Российская Федерация

Сказал «Спасибо»: 500 раз
Поблагодарили: 2044 раз в 1585 постах
Здравствуйте.

Обычно принимающая данные сторона (в данном случае - сервер) - должна строить\проверять цепочку сертификатов.
Очевидно, необходимо на стороне сервера - установить корневой\промежуточные сертификаты, чтобы клиентский стал приниматься.
Техническую поддержку оказываем тут
Наша база знаний
Offline auglov  
#3 Оставлено : 5 апреля 2018 г. 22:12:55(UTC)
auglov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 25.12.2014(UTC)
Сообщений: 76

Сказал(а) «Спасибо»: 3 раз
Коллеги со стороны сервера говорят, что у них все прописано - наш клиентский сертификат и его корневой. Попросил их перепроверить еще раз.
Что еще может быть не так?
Offline Евгений Афанасьев  
#4 Оставлено : 6 апреля 2018 г. 9:42:32(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,921
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 688 раз в 649 постах
Здравствуйте. Включите более детальный лог (ALL).
thanks 1 пользователь поблагодарил Евгений Афанасьев за этот пост.
auglov оставлено 09.04.2018(UTC)
Offline auglov  
#5 Оставлено : 6 апреля 2018 г. 17:54:06(UTC)
auglov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 25.12.2014(UTC)
Сообщений: 76

Сказал(а) «Спасибо»: 3 раз
Выслал в почту. Там good - это от старта приложения до успешного запроса на "хороший" сервис. bad - тоже от старта приложения до неудачного запроса на "плохой" сервис.
Offline auglov  
#6 Оставлено : 9 апреля 2018 г. 17:38:36(UTC)
auglov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 25.12.2014(UTC)
Сообщений: 76

Сказал(а) «Спасибо»: 3 раз
Выяснили.
Со стороны сервера сертификат нашего УЦ зарегистрирован как сертификат промежуточного УЦ, но не как доверенный корневой. При запросе клиентского сертификата сервер отправляет только список корневых в качестве приемлимых issuers для клиентского, и JCP проверяет свой сертификат закрытого ключа только по этому списку, соответственно, не находит в нем сертификата нужного УЦ.

Итого, есть два решения:
1. Добавить сертификат промежуточного УЦ в доверенные корневые на стороне сервера. (Это работает, но это не очень-то по фен-шую).
2. В хранилище закрытого ключа в JCP нужно импортировать всю цепочку сертификатов до корня, а не только сам клиентский сертификат. Это получилось сделать только на JCP 2.0.39442. (на 2.0.38830 с панели это не работает, но если подсунуть потом контейнер ключа уже с цепочкой, то все нормально работает дальше).

Спасибо, afev.

Отредактировано пользователем 9 апреля 2018 г. 17:50:56(UTC)  | Причина: Не указана

Offline what_is_it@inbox.ru  
#7 Оставлено : 11 марта 2019 г. 15:58:01(UTC)
what_is_it@inbox.ru

Статус: Активный участник

Группы: Участники
Зарегистрирован: 27.02.2013(UTC)
Сообщений: 38
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 14 раз
Поблагодарили: 11 раз в 9 постах
Добрый день! Мы столкнулись с очень похожей проблемой. Подскажите, пожалуйста, не совсем поняла:
проблема решается только путем изменений на стороне сервера или возможно что-то предпринять на стороне клиента?

br.so-ups.log (49kb) загружен 2 раз(а).

У наших коллег что-то изменилось на сервере и наш сертификат перестал отправляться (в клиентском приложении используем JCP jcp-2.0.39442)
Насколько я понимаю, сертификат все-таки находится и начинает проверяться:

Код:

2019-03-11 15:01:19 r.C.JCP.tools.logger.BasicLogger.trace - Search for client containers with type: GOST3410_2012_256
2019-03-11 15:01:19 r.C.JCP.tools.logger.BasicLogger.trace - %% getting aliases for Client
2019-03-11 15:01:19 r.C.JCP.tools.logger.BasicLogger.trace - %% check public key algorithm
2019-03-11 15:01:19 r.C.JCP.tools.logger.BasicLogger.trace - %% check extended key usage (size: 14)
2019-03-11 15:01:19 r.C.JCP.tools.logger.BasicLogger.trace - %% check extended key usage of Client
2019-03-11 15:01:19 r.C.JCP.tools.logger.BasicLogger.error - %% No alias is match
2019-03-11 15:01:19 r.C.JCP.tools.logger.BasicLogger.trace - Containers not found.

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

Отредактировано пользователем 11 марта 2019 г. 16:03:03(UTC)  | Причина: Не указана

Offline Евгений Афанасьев  
#8 Оставлено : 11 марта 2019 г. 16:18:55(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,921
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 688 раз в 649 постах
Здравствуйте.
Издатель вашего клиентского сертификата есть в этом списке, присылаемом сервером?
Код:

Cert Authorities:
<CN=УЦ ОАО АТС, OU=УЦ, O=ОАО АТС, L=Москва, C=RU, T=Уполномоченное лицо, EMAILADDRESS=atsca@atsenergo.ru>
<CN=System Operator GOST Root CA, O=System Operator of the Unified Energy System, C=RU>
<CN=System Operator RSA Root CA, O=System Operator of the Unified Energy System, C=RU>
<CN=System Operator GOST CP CA, O=System Operator of the Unified Energy System, C=RU>
<CN=Microsoft Root Certificate Authority, DC=microsoft, DC=com>
<CN=УЦ ОАО АТС, OU=УЦ, O=ОАО АТС, L=Москва, ST=77 г.Москва, C=RU, EMAILADDRESS=atsca@rosenergo.com, STREET=Краснопресненская наб.12 подъезд 7 этаж 8, T=Уполномоченное Лицо, OID.1.2.643.3.131.1.1=#120C303037373033363531373932, OID.1.2.643.100.1=#120D31303737373633383138343530>
<CN=Microsoft Root Authority, OU=Microsoft Corporation, OU=Copyright (c) 1997 Microsoft Corp.>
<CN=System Operator RSA CP CA, O=System Operator of the Unified Energy System, C=RU>
<CN=Microsoft Root Certificate Authority 2011, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US>
<CN=Головной удостоверяющий центр, OID.1.2.643.3.131.1.1=#120C303037373130343734333735, OID.1.2.643.100.1=#120D31303437373032303236373031, O=Минкомсвязь России, STREET="125375 г. Москва, ул. Тверская, д. 7", L=Москва, ST=77 г. Москва, C=RU, EMAILADDRESS=dit@minsvyaz.ru>
<CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US>
<CN=Минкомсвязь России, OID.1.2.643.3.131.1.1=#120C303037373130343734333735, OID.1.2.643.100.1=#120D31303437373032303236373031, O=Минкомсвязь России, STREET="улица Тверская, дом 7", L=г. Москва, ST=77 Москва, C=RU, EMAILADDRESS=dit@minsvyaz.ru>
<CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US>
<CN=CryptoPro GOST Root CA, O="LLC \"Crypto-Pro\"", L=Moscow, ST=Moscow, C=RU, OID.1.2.643.3.131.1.1=#120C303037373137313037393931, OID.1.2.643.100.1=#120D31303337373030303835343434>
<CN=Тестовый УЦ20 АО АТС, O=АО АТС, OU=ДПОИТ, STREET=Краснопресненская наб. 12, L=Москва, ST=77 г.Москва, C=RU, OID.1.2.643.3.131.1.1=#120C303030303030303030303030, OID.1.2.643.100.1=#120D30303030303030303030303030>
<CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE>
<OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>
<CN=DigiCert High Assurance EV Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US>
<CN=DigiCert Assured ID Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US>
<CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE>
thanks 1 пользователь поблагодарил Евгений Афанасьев за этот пост.
what_is_it@inbox.ru оставлено 11.03.2019(UTC)
Offline what_is_it@inbox.ru  
#9 Оставлено : 11 марта 2019 г. 17:00:32(UTC)
what_is_it@inbox.ru

Статус: Активный участник

Группы: Участники
Зарегистрирован: 27.02.2013(UTC)
Сообщений: 38
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 14 раз
Поблагодарили: 11 раз в 9 постах
Похоже, его в этом списке нет
сертификат

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

Отредактировано пользователем 11 марта 2019 г. 17:16:30(UTC)  | Причина: Не указана

Offline Евгений Афанасьев  
#10 Оставлено : 11 марта 2019 г. 20:52:04(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,921
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 688 раз в 649 постах
У вас, судя по картинкам, корневой сертификат Минкомсвязи, он есть в списке, присылаемом сервером (вроде он):
<CN=Минкомсвязь России, OID.1.2.643.3.131.1.1=#120C303037373130343734333735, OID.1.2.643.100.1=#120D31303437373032303236373031, O=Минкомсвязь России, STREET="улица Тверская, дом 7", L=г. Москва, ST=77 Москва, C=RU, EMAILADDRESS=dit@minsvyaz.ru>
Установите в контейнер всю цепочку вплоть до корневого (p7b), тогда ваш сертификат будет выбираться.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы12>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.