Статус: Участник
Группы: Участники
Зарегистрирован: 11.08.2015(UTC) Сообщений: 19  Откуда: Екатеринбург Сказал(а) «Спасибо»: 4 раз
|
Добрый день! В нашей системе используем для работы с ЭП на стороне сервера библиотеку CAdES из реализации Крипто ПРО JCP (версия 2.0, Java 8). При проверке ЭП произошла следующая ситуация. Для одного из сертификатов в цепочке первая точка распространения CRL в списке медленно обрабатывала запросы. Т.е. физически узел был доступен, но сервер висел. Другие 4 точки распростанения CRL, указанные в сертификате, по утверждению УЦ, обрабатывали запросы в штатном режиме. При этом метод проверки ЭП зависал в ожидании ответа и не пытался использовать другие адреса по списку. В итоге в логе приложения наблюдался следующий стек-трейс: Код:
авг 14, 2017 12:20:08 PM ru.CryptoPro.reprov.certpath.URICertStore engineGetCRLs
WARNING: Exception fetching CRL:
java.security.cert.CRLException: Empty input
at sun.security.provider.X509Factory.engineGenerateCRL(X509Factory.java:395)
at java.security.cert.CertificateFactory.generateCRL(CertificateFactory.java:497)
at ru.CryptoPro.reprov.certpath.URICertStore.engineGetCRLs(Unknown Source)
at java.security.cert.CertStore.getCRLs(CertStore.java:181)
at ru.CryptoPro.reprov.certpath.DistributionPointFetcher.a(Unknown Source)
at ru.CryptoPro.reprov.certpath.DistributionPointFetcher.a(Unknown Source)
at ru.CryptoPro.reprov.certpath.DistributionPointFetcher.a(Unknown Source)
at ru.CryptoPro.reprov.certpath.CrlRevocationChecker.a(Unknown Source)
at ru.CryptoPro.reprov.certpath.CrlRevocationChecker.a(Unknown Source)
at ru.CryptoPro.reprov.certpath.CrlRevocationChecker.check(Unknown Source)
at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:219)
at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140)
at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79)
at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
at ru.CryptoPro.reprov.CPCertPathValidator.engineValidate(Unknown Source)
at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
at ru.CryptoPro.CAdES.b.d.a.a(Unknown Source)
at ru.CryptoPro.CAdES.b.d.a.a(Unknown Source)
at ru.CryptoPro.CAdES.CAdESSigner.a(Unknown Source)
at ru.CryptoPro.CAdES.CAdESSignature.a(Unknown Source)
at ru.CryptoPro.CAdES.CAdESSignature.verify(Unknown Source)
...
Возможно, метод получения CRL в итоге отваливался по таймауту, но оценить его значение по логу не представляется возможным. Далее, по утверждению УЦ, они устранили проблему с зависшим сервером. Но ошибка в нашем приложении осталась до перезапуска JVM. Вопрос 1: Хотелось бы понять, как штатно должен вести себя JCP в описанной ситуации, задается ли какой-то таймаут для соединения с сервером CRL и можно ли им управлять?Вопрос 2: То, что потребовался перезапуск JVM для восстановления работоспособности приложения - это следствие зависания соединения в ожидании ответа или результат кэширования данных предыдущих запросов (если все-таки таймаут есть), и можно ли этого избежать в будущем?
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,113
Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 153 раз в 138 постах
|
Автор: scherepanov  Вопрос 1: Хотелось бы понять, как штатно должен вести себя JCP в описанной ситуации, задается ли какой-то таймаут для соединения с сервером CRL и можно ли им управлять? ЖТЯИ.00091-01 33 01. КриптоПро JCP. Руководство программиста. Общая часть ... Для того, чтобы ограничить время подключения к хосту и чтения данных при скачивании CRL по точкам CRLDP в сертификате, можно указать таймауты подключения и чтения в секундах: -Dcom.sun.security.crl.timeout=xxx // по умолчанию — 15 сек -Dru.CryptoPro.crl.read_timeout=xxx // по умолчанию — 10 сек P.S. Уж сколько раз твердили миру, что дока - рулез ...
|
 1 пользователь поблагодарил basid за этот пост.
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 11.08.2015(UTC) Сообщений: 19 Откуда: Екатеринбург Сказал(а) «Спасибо»: 4 раз
|
Автор: basid
Для того, чтобы ограничить время подключения к хосту и чтения данных при
скачивании CRL по точкам CRLDP в сертификате, можно указать таймауты подключения
и чтения в секундах:
-Dcom.sun.security.crl.timeout=xxx // по умолчанию — 15 сек
-Dru.CryptoPro.crl.read_timeout=xxx // по умолчанию — 10 сек
Спасибо! Но если данные параметры явно не выставлены, то судя по документации применяются по умолчанию 15 сек и 10 сек, а не бесконечные. Значения по умолчанию нас устраивают. НО проблема у нас была в том, что висело не секунды, а несколько дней. Предположили, что таймауты были бесконечными, поэтому решили уточнить.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,003 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 714 раз в 674 постах
|
ru.CryptoPro.crl.read_timeout добавлен относительно недавно. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 11.08.2015(UTC) Сообщений: 19 Откуда: Екатеринбург Сказал(а) «Спасибо»: 4 раз
|
Автор: afev ru.CryptoPro.crl.read_timeout добавлен относительно недавно. А можете подсказать с какой точно версии JCP данный параметр добавлен?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,003 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 714 раз в 674 постах
|
2016-09-28 КриптоПро JCP 2.0.38999
* jcp: добавлена возможность указать таймаут чтения CRL в JCPRevCheck (JCP-688) |
|
1 пользователь поблагодарил Евгений Афанасьев за этот пост.
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 11.08.2015(UTC) Сообщений: 19 Откуда: Екатеринбург Сказал(а) «Спасибо»: 4 раз
|
Автор: scherepanov
Вопрос 2: То, что потребовался перезапуск JVM для восстановления работоспособности приложения - это следствие зависания соединения в ожидании ответа или результат кэширования данных предыдущих запросов (если все-таки таймаут есть), и можно ли этого избежать в будущем?
А можете еще по этому вопросу дать комментарии, пожалуйста?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,003 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 714 раз в 674 постах
|
Сложно сказать, с таким не сталкивались, возможно, "следствие зависания соединения в ожидании ответа". |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,113
Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 153 раз в 138 постах
|
Автор: scherepanov судя по документации применяются по умолчанию 15 сек и 10 сек, а не бесконечные. Значения по умолчанию нас устраивают. НО проблема у нас была в том, что висело не секунды, а несколько дней. Это уже другая проблема. Приложение установило TCP-соединение с сервером и отправило HTTP-запрос. Сервер запрос принял, вероятно, отправил заголовки ответа и начал передавать данные, но завис. Если нет контроля "минимальной скорости передачи", то "висеть в ожидании данных" можно о-о-чень долго. У HTTP-сервера такой контроль должен быть, но "сервер завис". Есть ли такой контроль на стороне клиента - неизвестно. "По-моему так" (ц) Винни-Пух (голосом Евгения Леонова). Отредактировано пользователем 16 августа 2017 г. 10:20:54(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 11.08.2015(UTC) Сообщений: 19 Откуда: Екатеринбург Сказал(а) «Спасибо»: 4 раз
|
Автор: afev Сложно сказать, с таким не сталкивались, возможно, "следствие зависания соединения в ожидании ответа". Версия КриптоПро JCP на сервере у нас 2.0.38674, в которой получается НЕТ второго параметра (таймаута чтения данных -Dru.CryptoPro.crl.read_timeout)...
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
