NoSuchAlgorithmException: алгоритм HmacSHA1 недоступен

Посмотрите на следующую строку Java:

Mac.getInstance("HmacSHA1");

Если я помещу это в простую тестовую программу, она без проблем запустится на моем сервере. Однако, если я использую эту строку в контейнере, я получаю

java.security.NoSuchAlgorithmException: Algorithm HmacSHA1 not available
  at javax.crypto.Mac.getInstance(DashoA13*..)

В обоих случаях используется одна и та же установка JDK.

Немного погуглив, мне удалось заставить его работать, выполнив две вещи:

  1. копирование sunjce_provider.jar от $JAVA_HOME/jre/lib/ext в каталог lib контейнера.

  2. Добавив следующую строку в мой код:

    java.security.Security.addProvider(new com.sun.crypto.provider.SunJCE());

В частности, это происходит со мной в Apache James Mailet, но я уверен, что это связано с опциями JVM. Вот скрипт запуска, который он использует.

Хотя в конце концов я заставил его работать, решение кажется слишком взломанным, чтобы быть правильным. Буду признателен за объяснение происходящего, а также за более "правильное" решение.

Смежный вопрос: использование криптографии Java приводит к NoSuchAlgorithmException. Однако в этом случае я почти уверен, что алгоритм HmacSHA1 должен поддерживаться сразу после установки. Как доказательство, это работает без проблем в тестовой программе.

Источник

5 ответов

Решение

Скрипт запуска устанавливает java.ext.dirs к собственному набору каталогов (специфичному для приложения), но без "нормального" каталога расширений ($JAVA_HOME/jre/lib/ext/) где sunjce_provider.jar проживает. Это объясняет вашу первую мысль (копирование файла Jar в каталог lib делает его снова видимым). Это легко воспроизвести.

Что касается второго пункта, я думаю, что это связано с файлом политики, который сценарий запуска устанавливает с -Djava.security.policy вариант. Доступны ли некоторые поставщики или нет, зависит от файлов политики. Файл политики по умолчанию делает поставщика SunJCE доступным, но поскольку сценарии запуска требуют использования нестандартного файла политики по умолчанию, то все идет. Я предлагаю вам взглянуть на этот файл политики.

Например, в моей системе (Ubuntu Linux с Sun JVM 1.6.0_20 в комплекте с Ubuntu) файл политики по умолчанию находится в /etc/java-6-sun/security/java.security и содержит (среди прочего) следующие строки:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.6=com.sun.security.sasl.Provider
security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.8=sun.security.smartcardio.SunPCSC

которые определяют, какие провайдеры должны быть доступны по умолчанию. Исходя из ваших симптомов, я думаю, что файл пользовательской политики сделал SunJCE недоступным, если он не был явно зарегистрирован (что понятно, поскольку сценарий запуска также удалил доступ к файлу Jar, содержащему SunJCE...).

Источник

Правильная сокращенная форма как ниже

HmacMD5
HmacSHA1
HmacSHA256
Источник

Он был сокращен до SHA1, MD5 и SHA256

Источник

Попробуйте изменить версию Java

Я получал исключение NoSuchAlgorithmException: "Unable to obtain JCA MAC algorithm 'HmacSHA512'" на следующей версии Java:

Java-версия "1.8.0_131"
Java (TM) SE Runtime Environment (сборка 1.8.0_131-b11)
Java HotSpot (TM) 64-разрядная серверная виртуальная машина (сборка 25.131-b11, смешанный режим)

После изменения версии JDK на следующую, проблема была решена:

Java-версия "1.8.0_45"
Java (TM) SE Runtime Environment (сборка 1.8.0_45-b15)
Java HotSpot (TM) 64-разрядная серверная виртуальная машина (сборка 25.45-b02, смешанный режим)

Необходимая банка для этого вопроса sunjce_provider.jar возможно, что он может быть поврежден.

Источник

Я получал ту же ошибку, и когда пытался перечислить все мои ключи, я не заметил ошибки:

«Хранилище ключей JKS использует собственный формат. Рекомендуется перейти на PKCS12, который является отраслевым стандартом, используя команду« keytool -importkeystore -srckeystore /Users/matua/.keystore -destkeystore /Users/matua/.keystore -deststoretype pkcs12 ».

Я изменил тип трапецеидального искажения на PKCS #12 вместо JKS, и все прошло гладко. Я использовал KeysStore Explorer 5.4.4 для создания хранилища ключей через графический интерфейс.

Источник
Другие вопросы по тегам