КриптоПро JCP 2: ошибка ru.CryptoPro.JCP.tools.SelfTester.run SelfTester's test №16 failed

Проблема

Есть приложение, использующее КриптоПро JCP 2 для подписания XML. После развертывания на новом сервере при попытке подписания падает ошибка:

04-Dec-2018 18:21:54.093 WARNING [SelfTester] ru.CryptoPro.JCP.tools.SelfTester.run SelfTester's test №16 failed
 ru.CryptoPro.JCP.tools.SelfTesterException: Error during store working
at ru.CryptoPro.JCP.tools.SelfTests$TestDigestStore.run(Unknown Source)
at ru.CryptoPro.JCP.tools.SelfTester.b(Unknown Source)
at ru.CryptoPro.JCP.tools.SelfTester.a(Unknown Source)
at ru.CryptoPro.JCP.tools.SelfTester.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Caused by: ru.CryptoPro.JCP.tools.SelfTesterException: Error during store working
at ru.CryptoPro.JCP.tools.SelfTests.testDigestStore(Unknown Source)
... 5 more
Caused by: ru.CryptoPro.JCP.tools.CPVerify.CPVerifyException: Error during store working
at ru.CryptoPro.JCP.tools.CPVerify.DigestStoreDefault.<init>(Unknown Source)
... 6 more  

При последующих попытках падает:

SelfTester Error: some test crashed twice in a row, usage of JCP is no longer available
ru.CryptoPro.JCP.tools.SelfTesterException: SelfTester Error: some test crashed twice in a row, usage of JCP is no longer available

Причина

У пользователя, от имени которого работает приложение, не было прав на запись в директорию /var/opt/cprocsp/tmp. После выдачи прав стала падать ошибка "Permission denied" при попытке работы с какими-то файлами в этой папке, имена файлов начинаются с ".". У этих файлов владельцем был root, поэтому ошибка закономерна. После удаления этих файлов все заработало.

Бесследное удаление КриптоПРО JCP 2.x

Под Windows:

• Сносим JDK
• Удаляем из реестра HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs\ru\/Crypto/Pro

Под Linux:

• Сносим JDK
• Удаляем /root/.java/
• Удаляем /var/opt/cprocsp/
• Если /usr/java/default не совпадает с только что снесенной JDK, то нужно удалить из нее .java/.systemPrefs/.ru (т.к. эта папка создается JCP почему-то именно в этой JDK, а не в той, куда ставится JCP)

Директория HDImageStore КриптоПРО JCP

Windows

Контейнеры, хранящиеся в HDImagesStore КриптоПРО JCP физически лежат на диске в подпапке \AppData\Local\Crypto Pro домашней папки пользователя (путь можно изменить через ControlPane).

Linux

/var/opt/cprocsp/keys/<username>

Актуально для КриптоПРО JCP 2.0.38481

JCP + ruToken: ошибка "java.io.IOException: Can't connect to Aktiv Co. ruToken 0"

Проблема

Используется JCP + ruToken для вычисления ЭЦП. При попытке получить ключ с токена падает ошибка:

Caused by: java.security.UnrecoverableKeyException: Can't connect to Aktiv Co. ruToken 0
at ru.CryptoPro.JCP.KeyStore.s.e(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.ContainerStore.engineGetKey(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.JCPKeyStore.engineGetKey(Unknown Source)
at java.security.KeyStore.getKey(KeyStore.java:792)
...
Caused by: java.io.IOException: Can't connect to Aktiv Co. ruToken 0
at rtjlib.JCP.RutokenReader.lock(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.j.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at ru.CryptoPro.JCP.KeyStore.ContainerStore.a(Unknown Source)

Решение

Текст ошибки не особо содержателен, и по нему совершенно неочевидно, в чем именно проблема. Из того же JCP-шного ControlPane я великолепно вижу Aktiv Co. ruToken 0, включая ключ и сертификат на нем.

Декомпилируем rtjlib.JCP.RutokenReader (rtjlib.jar в jre/lib/ext того JDK, который используется для подписывания). Там IOException с таким текстом кидается в 2 местах, и если в одном он кидается просто в коде после неудачного коннекта, то вот во втором применен замечательный подход "проглатывания исключения":

try
    {
      arrayOfByte = nativeWinJavaReader.getAtr(str, "T=0|T=1");
    }
    catch (Exception localException1)
    {
      throw new IOException("Can't connect to " + str);
    }

Добавляем в бросаемое исключение исходный localException1:

    try
    {
      arrayOfByte = nativeWinJavaReader.getAtr(str, "T=0|T=1");
    }
    catch (Exception localException1)
    {
      throw new IOException("Can't connect to " + str, localException1);
    }

Перекомпилируем класс RutokenReader, подкладываем в целевой JDK. Получаем более развернутую ошибку:

Caused by: java.io.IOException: Can't connect to Aktiv Co. ruToken 0
at rtjlib.JCP.RutokenReader.lock(RutokenReader.java:38)
at ru.CryptoPro.JCP.KeyStore.j.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at ru.CryptoPro.JCP.KeyStore.ContainerStore.a(Unknown Source)
... 25 more
Caused by: java.lang.Exception: Establish context failed with 0x8010001d
at rtjlib.nativeAPI.SCardEstablishContext(Native Method)
at rtjlib.readerImpl.nativeWinJavaReader.getAtr(Unknown Source)
at rtjlib.JCP.RutokenReader.lock(RutokenReader.java:34)
... 28 more

Гуглим код 0x8010001d, узнаем, что расшифровывается он как "SCARD_E_NO_SERVICE - "The Smart card resource manager is not running." (http://blogs.msdn.com/b/alejacma/archive/2011/05/19/scardestablishcontext-fails-with-scard-e-no-service-error.aspx). Гугл же подсказывает и возможную причину: ошибка может быть вызвана нехваткой прав к событию "Global\Microsoft Smart Card Resource Manager Started". На это событие есть права только у интерактивных пользователей, SYSTEM и LOCAL SERVICE. В моем же случае ошибка падала в службе, запускающейся из-под обычного пользователя (но т.к. вход не интерактивный - прав не хватало). Запустили целевую программу в интерактивном режиме (из командной строки) вместо запуска в качестве службы - ошибка ушла. Пока такое решение устроило.

КриптоПРО JCP XMLDSig: java.lang.ClassCastException: content[0] is not a valid X509Data type

При попытки подписывания XML-документа с помощью КриптоПРО JCP падает ошибка:

java.lang.ClassCastException: content[0] is not a valid X509Data type
at ru.CryptoPro.JCPxml.dsig.internal.dom.DOMX509Data.<init>(DOMX509Data.java:68)
at ru.CryptoPro.JCPxml.dsig.internal.dom.DOMKeyInfoFactory.newX509Data(DOMKeyInfoFactory.java:88)
...

Причина - в моем случае был неверно указан keyAlias.

Настройки log4j для отладки формирования и валидации XMLDSig средствами КриптоПро JCP

log4j.logger.org.jcp.xml.dsig.internal=DEBUG
log4j.logger.com.sun.org.apache.xml.internal.security=DEBUG
log4j.logger.ru.CryptoPro.JCPxml.dsig.internal=DEBUG
log4j.logger.ru.CryptoPro.JCPxml.dsig.internal.dom=DEBUG
log4j.logger.ru.CryptoPro.JCP=DEBUG

КриптоПРО JCP 1.0.54 и JDK 1.7.0_71: java.util.MissingResourceException: Can't find ru.CryptoPro.JCP.tools.resources.logger bundle

Проблема

Пытаюсь установить КриптоПРО JCP 1.0.54 на JDK 1.7.0_71, получаю ошибку:

...
Executing commands:
java.lang.ExceptionInInitializerError
        at ru.CryptoPro.JCP.Digest.GostDigest.reset(Unknown Source)
        at ru.CryptoPro.JCP.Digest.GostDigest.a(Unknown Source)
        at ru.CryptoPro.JCP.Digest.GostDigest.<init>(Unknown Source)
        at ru.CryptoPro.JCP.tools.AbstractLicense.a(Unknown Source)
        at ru.CryptoPro.JCP.tools.AbstractLicense.a(Unknown Source)
        at ru.CryptoPro.JCP.tools.AbstractLicense.b(Unknown Source)
        at ru.CryptoPro.JCP.tools.AbstractLicense.c(Unknown Source)
        at ru.CryptoPro.JCP.tools.AbstractLicense.<init>(Unknown Source)
        at ru.CryptoPro.JCP.tools.License.<init>(Unknown Source)
        at ru.CryptoPro.JCP.Install.JCPInstaller.a(Unknown Source)
        at ru.CryptoPro.JCP.Install.JCPInstaller.parseArgs(Unknown Source)
        at ru.CryptoPro.Install.f.a(Unknown Source)
        at ru.CryptoPro.Install.ShellInstaller.h(Unknown Source)
        at ru.CryptoPro.Install.ShellInstaller.makeAction(Unknown Source)
        at ru.CryptoPro.Install.ShellInstaller.makeActionNoEx(Unknown Source)
        at ru.CryptoPro.Install.VariantTwo.main(Unknown Source)
Caused by: java.util.MissingResourceException: Can't find ru.CryptoPro.JCP.tools.resources.logger bundle
        at java.util.logging.Logger.setupResourceInfo(Logger.java:1537)
        at java.util.logging.Logger.<init>(Logger.java:267)
        at java.util.logging.Logger.<init>(Logger.java:261)
        at ru.CryptoPro.JCP.tools.JCPLogger.<init>(Unknown Source)
        at ru.CryptoPro.JCP.tools.JCPLogger.<clinit>(Unknown Source)
        ... 16 more
Install failed
---- Script ERROR

Решение

Установка сертифицированных версий JCP (последняя на данный момент - 1.0.54) возможна на версии JDK до 1.7.0_25, о чем и сказано на странице продукта в разделе "Системные требования". Причем, судя по всему, не включительно, т.к. на 25-ой наблюдается та же проблема. Установить удалось только на 1.7.0_21.

Т.е. либо даунгрэйдим JDK, либо отказываемся от сертифицированной версии в пользу несертифицированной.

Относительная производительность проверки ЭЦП ГОСТ 3410 в КриптоПРО JCP и Bouncy Castle

Особенно глубоко эту тему не исследовал, но данные профилировщика Netbeans говорят о примерно одинаковой производительности криптопровайдеров КриптоПРО JCP и Bouncy Castle при проверке ЭЦП, использующей алгоритм ГОСТ 3410.

Использование криптопровайдеров в веб-приложениях на Tomcat и размещение библиотек криптопровайдера

Столкнувшись с необходимостью использовать в веб-приложении криптопровайдеры (КриптоПРО JCP и Bouncy Castle), я пришел к следующему выводу относительно размещения библиотек криптопровайдера: их не стоит размещать в war-файле веб-приложения, т.к. при переразвертывании приложения без перезапуска веб-сервера криптопровайдер работать не будет. В случае с JCP библиотеки вообще нужно размещать в lib/ext JRE, которое используется Томкатом (JCP туда собственно сам устаналивается скриптом установки), а для Bouncy Castle подойдет размещение библиотеки в /lib томката.

Корректное развертывание веб-приложения, использующего КриптоПРО JCP

Методом проб и ошибок была определена следующая конфигурация, позволяющая корректно развернуть на Tomcat 6 веб-приложение, использующее КриптоПРО JCP 1.0.49 (как для разработки, так и для продуктивной среды):

1) JCP устанавливается с указанием в качестве jre папки /jre в директории JDK, используемого томкатом

2) В /lib/ext этого же JRE кладутся следующие jar-ники:

• xmlsec-1.5.1.jar (или 1.2.1, но 1.5.1 предпочтительнее, т.к. в нём в лог не валятся сообщения при каждой проверке подписи, т.к. уровень логирования таких сообщений исправлен с INFO на DEBUG / WARNING)
• commons-logging-1.1.1.jar (или commons-logging-1.1.jar)
• xalan-2.6.0.jar
• serializer-2.7.1.jar
• xercesImpl-2.9.1.jar
• xml-apis-1.3.04.jar
• xsltc.jar

Последний брался из дистрибутива Xalan 2.7.1 (однако с xalan.jar из этого же дистрибутива JCP работать не будет по этой причине). Serializer, xercesImpl и xml-apis взяты из дистрибутива xmlsec-1.5.1.

3) В сам war-файл веб-приложения вышеуказанные библиотеки (как и библиотеки JCP) включать не нужно. 

java.lang.ClassNotFoundException: org.apache.xpath.compiler.FuncLoader при запуске приложения, использующего КриптоПРО JCP, при том, что xalan.jar в Classpath есть

Проблема:

При запуске приложения, использующего КриптоПРО JCP, валится исключение:

java.lang.ClassNotFoundException: org.apache.xpath.compiler.FuncLoader

, при том, что в Classpath xalan.jar и все необходимые ему jar-ники есть.

Причина:

В новых версиях Xalan (по крайней мере, в 2.7.1) действительно нет класса FuncLoader. 

Решение:

Использовать Xalan версии 2.6.