Статус: Участник
Группы: Участники
Зарегистрирован: 26.05.2022(UTC) Сообщений: 18  Сказал(а) «Спасибо»: 3 раз
|
Добрый день. В процессе проверки подписи XAdES_X_Long_Type_1 возникает ошибка "Digest oid not found for" Цитата:2022-06-28 20:45:06.851 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Normalizing single certificate reference...
2022-06-28 20:45:06.990 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Looking for certificate by certificate reference, max priority
2022-06-28 20:45:07.153 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Find a provider that implements the digest algorithm 1.2.643.7.1.1.2.2 (null)
2022-06-28 20:45:07.321 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Valid provider (digest algorithm: 1.2.643.7.1.1.2.2): JCP is found instead of null
2022-06-28 20:45:07.725 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Analysing basic ocsp response...
2022-06-28 20:45:07.814 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Analysing single ocsp response # 0
2022-06-28 20:45:07.843 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Finding issuer certificate...
2022-06-28 20:45:07.914 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Looking for certificate by certificate identifier, max priority
2022-06-28 20:45:08.652 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Find a provider that implements the digest algorithm 1.2.643.7.1.1.2.2 (JCP)
2022-06-28 20:45:09.349 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Find a provider that implements the digest algorithm 1.2.643.7.1.1.2.2 (JCP)
2022-06-28 20:45:09.433 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Checking certificate signature...
2022-06-28 20:45:09.556 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Checking certificate identifier...
2022-06-28 20:45:09.692 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Creating certificate identifier...
2022-06-28 20:45:10.267 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Find a provider that implements the digest algorithm 1.2.643.7.1.1.2.2 (JCP)
2022-06-28 20:45:10.473 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Find a provider that implements the digest algorithm 1.2.643.7.1.1.2.2 (JCP)
2022-06-28 20:45:10.591 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : OCSP evidence accepted.
2022-06-28 20:45:17.552 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : Producing OCSP responder identifier...
2022-06-28 20:45:17.766 DEBUG 18284 --- [nio-8888-exec-7] r.C.J.t.JCPLogger : IGNORE THROWN
java.text.ParseException: Unparseable date: "2022-06-28T11:31:00.40:0Z"
at java.text.DateFormat.parse(DateFormat.java:399) ~[?:?]
at ru.CryptoPro.XAdES.util.SystemUtils.parseDate(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.cl_26.d(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.pc_0.cl_1.a(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.pc_0.cl_1.a(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.pc_0.cl_1.a(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.pc_1.pc_0.cl_6.decode(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
2022-06-28 21:14:47.697 WARN 18284 --- [nio-8888-exec-7] b.r.c.c.h.CustomRestExceptionHandler : Digest oid not found for
ru.CryptoPro.XAdES.exception.XAdESException: Digest oid not found for
at ru.CryptoPro.XAdES.XAdESSignature.a(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.XAdESSignature.<init>(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
Caused by: ru.CryptoPro.XAdES.exception.XAdESException: Digest oid not found for
at ru.CryptoPro.XAdES.pc_0.cl_1.a(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.pc_1.pc_0.cl_6.decode(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.XAdESSignerBinaryImpl.e(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
... 90 more
Caused by: ru.CryptoPro.XAdES.exception.XAdESException: Digest oid not found for
at ru.CryptoPro.XAdES.util.XAdESUtility.findDigestOidByDigestName(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.pc_0.cl_1.a(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.pc_0.cl_1.a(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.pc_0.cl_1.a(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.pc_1.pc_0.cl_6.decode(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
at ru.CryptoPro.XAdES.XAdESSignerBinaryImpl.e(Unknown Source) ~[XAdES-jcp-2.0.41940-A.jar:41940-A]
... 90 more
Используется тестовый сертификат КРИПТО-ПРО, при создании CAdES-X-L1 с тем же сертификатом проверка проходит успешно XAdES-T проверка тоже проходит успешно. В процессе дебага видно, что ошибка происходит в момент Producing OCSP responder identifier... Блок документа с OCSPRefs: Цитата: <xades:OCSPRefs>
<xades:OCSPRef>
<xades:OCSPIdentifier URI="#xmldsig-c8983a8a-7ce3-491a-a11b-d328cceb90da-EncapsulatedOCSPValue-0">
<xades:ResponderID>
<xades:ByName>1.2.643.100.4=7717107991,1.2.643.100.1=1037700085444,O=ООО \"КРИПТО-ПРО\",STREET=ул. Сущевский Вал\, д. 18,L=Москва,ST=77 Москва,C=RU,CN=Тестовый оператор OCSP</xades:ByName>
</xades:ResponderID>
<xades:ProducedAt>2022-06-28T11:31:00.40:0Z</xades:ProducedAt>
</xades:OCSPIdentifier>
<xades:DigestAlgAndValue>
<ds:DigestMethod xmlns:ns0="ds" ns0:Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/>
<ds:DigestValue>XWkgay9EYmdlPtwm95RIVpoVnuwRn+CS8NwbUw0CFPw=</ds:DigestValue>
</xades:DigestAlgAndValue>
</xades:OCSPRef>
</xades:OCSPRefs> При получении OID в ru.CryptoPro.XAdES используется следующий код Цитата:Element var1 = this.b("DigestMethod", "http://www.w3.org/2000/09/xmldsig#");
return var1 == null ? null : var1.getAttribute("Algorithm"); В котором элемент var1 заполняется успешно, а вот атрибут "Algorithm" не возвращается. Подпись создавалась при помощи ru.CryptoPro.XAdES Есть предположение, что это связано с тем, что в xml-документе указано пространство имён xmlns:ns0="ds", так как в других блоках документа OID определяется нормально Например: Цитата: <ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#xmldsig-c8983a8a-7ce3-491a-a11b-d328cceb90da-signedprops">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/>
<ds:DigestValue>ro2YrlUthJVmaJHVE6MzNBGXd6QAoM2CmhF1zVgoPkU=</ds:DigestValue>
</ds:Reference> По идее, эта ошибка должна быть у всех, кто реализует проверку Xades-X-L1, возможно есть решение ?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
1. Приложите, пожалуйста, подпись для воспроизведения ошибки.
2. Используйте пространство имен ds по возможности для узлов подписи и их атрибутов. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 26.05.2022(UTC) Сообщений: 18 Сказал(а) «Спасибо»: 3 раз
|
1.  sign.txt (47kb) загружен 2 раз(а).2. Подпись была усовершенствована из BES используя метод ru.CryptoPro.XAdES.XAdESSigner.enhance(), как можно указать использовать пространство имен ds ?
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Цитата:<ds:DigestMethod xmlns:ns0="ds" ns0:Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/> Добрый день. Что-то это сильно смахивает на неправильный вызов добавления атрибута через DOM. Вроде того, что метод DOM ожидал указание атрибута в форме "http://www.w3.org/2000/09/xmldsig#", "Algorithm" (то есть адрес (точнее имя, но понятнее сказать адрес) пространства имен и имя атрибута), а ему передали "ds", "Algorithm" (то есть префикс пространства имен и имя атрибута). Другими словами префикс пространства имен "ds" передали в параметр где должен быть адрес пространства имен "http://www.w3.org/2000/09/xmldsig#". В этом случае как раз метод добавления DOM не найдет пространства имен с адресом "ds", возьмет с потолка префикс "ns0", объявит для префикса "ns0" адрес "ds" и добавит префикс "ns0" к имени атрибута. Все сделано по стандарту DOM. По этой же причине при поиске пространства имен "http://www.w3.org/2000/09/xmldsig#" не будет выбран атрибут "Algorithm", так как нет "http://www.w3.org/2000/09/xmldsig#":"Algorithm", но есть "ds":"Algorithm". Если было бы несколько атрибутов, то был бы еще и неправильный их порядок, так как сортируются атрибуты по адресу пространства имен. Проверьте, если ли где-то код добавления атрибута. Отредактировано пользователем 29 июня 2022 г. 13:09:25(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 26.05.2022(UTC) Сообщений: 18 Сказал(а) «Спасибо»: 3 раз
|
Вот почти вся реализация: Цитата:
// Получаем на вход строку документа Xades-BES и формируем DOM
var dbFactory = DocumentBuilderFactory.newInstance();
dbFactory.setNamespaceAware(true);
var document = dbFactory.newDocumentBuilder().parse(new ByteArrayInputStream(xmlString.getBytes(StandardCharsets.UTF_8)));
var signature = new XAdESSignature(document.getDocumentElement(), xadesTypeFrom.getCadesCode());
var signer = signature.getXAdESSignerInfo(signaturePosition);
var chain = signer.getSignatureCertificates().stream().toList();
var signatureAlgorithm = signer.getSignerCertificate().getPublicKey().getAlgorithm();
var digestAlgorithm = JCPUtils.key2DigestUrn(signatureAlgorithm);
// усовершенствование подписи
signer.enhance(JCP.PROVIDER_NAME, digestAlgorithm, chain, context.getTspServiceAddress(), xadesTypeTo.getCadesCode());
// получаем строку
TransformerFactory tf = TransformerFactory.newInstance();
Transformer transformer = tf.newTransformer();
StringWriter writer = new StringWriter();
transformer.transform(new DOMSource(node), new StreamResult(writer));
String xml = writer.getBuffer().toString();
Самостоятельно атрибуты не добавляем, почти всё делает ваша библиотека
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
|
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 26.05.2022(UTC) Сообщений: 18 Сказал(а) «Спасибо»: 3 раз
|
xades-bes.txt (8kb) загружен 5 раз(а).на выходе: xades-x-l1.txt (47kb) загружен 5 раз(а).Отредактировано пользователем 29 июня 2022 г. 15:29:50(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
Спасибо, будем проверять, с такой проблемой не сталкивались. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 26.05.2022(UTC) Сообщений: 18 Сказал(а) «Спасибо»: 3 раз
|
Добрый день. Пока смотрите текущую проблему, я решил попробовать xades4j для проверки Xades-X-L1 и возникла ошибка: xades4j.xml.unmarshalling.PropertyUnmarshalException: Only CRL references are supported
По коду видно, что если в документе есть тег OCSPRefs то бросается исключение.
if (xmlCompleteRevocRefs.getOCSPRefs() != null || xmlCompleteRevocRefs.getOtherRefs() != null)
throw new PropertyUnmarshalException("Only CRL references are supported", CompleteRevocationRefsProperty.PROP_NAME);
Может знаете, что можно сделать в с этой ошибкой ?
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
