developer tip

java.security.InvalidAlgorithmParameterException : Linux에서 trustAnchors 매개 변수가 비어 있지 않아야합니다. 또는 기본 신뢰 저장소가 비어있는 이유

copycodes 2020. 10. 23. 08:02
반응형

java.security.InvalidAlgorithmParameterException : Linux에서 trustAnchors 매개 변수가 비어 있지 않아야합니다. 또는 기본 신뢰 저장소가 비어있는 이유


이 질문에 이미 답변이 있습니다.

이 예외에 대해 Google을 검색하면 java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty, 여러 결과가 나타납니다. 그러나 확실한 해결책은 없으며 추측 만 할 수 있습니다.

SSL을 통해 연결을 열려고 할 때 문제가 발생합니다 (적어도 제 경우에는). 내 Windows 시스템에서 잘 작동하지만 Linux 시스템에 배포하면 (sun의 jre가 설치된) 위의 예외와 함께 실패합니다.

문제는 JRE의 기본 신뢰 저장소가 어떤 이유로 비어 있다는 것입니다 (크기는 32 바이트에 불과하지만 Windows에서는 80KB 임).

jre/lib/security/cacertsWindows에서 Linux로 파일을 복사하면 정상적으로 작동했습니다.

질문은-왜 Linux jre에 빈 신뢰 저장소가 있습니까?

이것은 AMI linux를 사용하는 Amazon EC2 인스턴스에서 발생하므로 일부 아마존 정책 때문일 수 있습니다 (Java가 사전 설치되어 있다고 생각하지만 확실하지 않습니다).


Linux 용 표준 Sun JDK에는 지정된 디렉토리에 절대적으로 괜찮은 cacerts 및 전체적인 모든 파일이 있습니다. 문제는 사용하는 설치입니다.


Ubuntu에서이 오류가 발생했습니다. 나는 / usr / lib / jvm / java-8-openjdk-amd64 / jre / lib / security / cacerts가 / etc / ssl / certs / java / cacerts에 대한 끊어진 링크임을 보았습니다. 이 버그로 이어졌습니다. https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/983302 ca-certificates-java에 대한 README는 결국 실제 수정 사항을 보여주었습니다.

운영

update-ca-certificates -f

apt-get install ca-certificates-java는 나를 위해 작동하지 않았습니다. 수동으로 설치된 것으로 표시했습니다.


이 오류 (OSX 10.5.8의 Java 1.6.0)는 다음과 같이 키 저장소에 더미 인증서를 넣어 피했습니다.

keytool -genkey -alias foo -keystore cacerts -dname cn=test -storepass changeit -keypass changeit

확실히 질문은 "왜 자바가 빈 trustStore를 처리 할 수 ​​없습니까?"여야합니다.


원래 질문에 대한 답은 아니지만 유사한 문제를 해결하려고 할 때 Mac OS X 업데이트가 Maverics에 대한 Java 설치를 망쳐 놓았다는 것을 발견했습니다 (실제로 cacert). http://www.oracle.com/technetwork/java/javase/downloads/index.htmlsudo rm -rf /Library/Java/JavaVirtualMachines/*.jdk 에서 제거 하고 다시 설치 하십시오.


시스템 속성 trustStore를 누락 된 jks 파일로 설정하여이 오류를 생성 할 수 있습니다. 예를 들면

    System.setProperty("javax.net.ssl.keyStore", "C:/keystoreFile.jks");
    System.setProperty("javax.net.ssl.keyStorePassword", "mypassword");
    System.setProperty("javax.net.ssl.trustStore", "C:/missing-keystore.jks");
    System.setProperty("javax.net.ssl.trustStorePassword", "mypassword");

이 코드는 어떤 이유로 FileNotFound 예외를 생성하지 않지만 위에 나열된 InvalidAlgorithmParameter 예외와 정확히 일치합니다.

일종의 멍청한 대답이지만 재현 할 수 있습니다.


Windows에서 내 솔루션은 관리자로 콘솔 창을 실행하거나 '% USERPROFILE %'대신 trust.jks (예 : 'C : \ Users \ oddros')에 대한 하드 코딩 된 경로를 사용하도록 환경 변수 MAVEN_OPTS를 변경하는 것이 었습니다. 내 MAVEN_OPTS는 이제 다음과 같습니다.

-Djavax.net.ssl.trustStore=C:\Users\oddros\trust.jks -Djavax.net.ssl.trustStorePassword=changeit

java-8-oracle이 설치된 Ubuntu 14.10에서 동일한 문제가 발생했습니다.

ca-certificates-java 패키지 설치 해결 :

sudo apt-get install ca-certificates-java

내 cacerts 파일이 완전히 비어 있습니다. 내 Windows 시스템 (Oracle Java 7 사용)에서 cacerts 파일을 복사하여 내 Linux 상자 (OpenJDK)로 scp하여이 문제를 해결했습니다.

cd %JAVA_HOME%/jre/lib/security/
scp cacerts mylinuxmachin:/tmp

그런 다음 Linux 시스템에서

cp /tmp/cacerts /etc/ssl/certs/java/cacerts

지금까지 훌륭하게 작동했습니다.


Linux가 아닌 Mac OS X에 OpenJDK를 설치하고 소프트웨어 업데이트를 통해 공식 Mac OS X Java (예 : 최신 Java 6)를 설치 한 경우 다음과 같이하면됩니다.

cd $OPENJDK_HOME/Contents/Home/jre/lib/security
ln -s /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts
ln -s /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/blacklist 
ln -s /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/trusted.libraries 

여기서는 $OPENJDK_HOMEOpenJDK 설치의 루트 디렉토리이며 일반적으로 OPENJDK_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk. 이것은 Mac OS X에 공식적인 Java 설치가 이러한 파일을 얻는 방법과 동일합니다. 또한 해당 시스템 번들에서 파일을 심볼릭 링크합니다. Lion에서 작동하지만 이전 버전의 OS에서는 확실하지 않습니다.


JRE / 보안에 유효한 cacert가 있는지 확인하십시오. 그렇지 않으면 유효하지 않은 빈 trustAnchors 오류를 우회하지 않습니다.

Amazon EC2 Opensuse12 설치에서 문제는 JRE 보안 디렉터리의 cacerts가 가리키는 파일이 유효하지 않다는 것입니다.

$ java -version
java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.4) (suse-3.20.1-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

$ ls -l /var/lib/ca-certificates/
-rw-r--r-- 1 root    363 Feb 28 14:17 ca-bundle.pem

$ ls -l /usr/lib64/jvm/jre/lib/security/
lrwxrwxrwx 1 root    37 Mar 21 00:16 cacerts -> /var/lib/ca-certificates/java-cacerts
-rw-r--r-- 1 root  2254 Jan 18 16:50 java.policy
-rw-r--r-- 1 root 15374 Jan 18 16:50 java.security
-rw-r--r-- 1 root    88 Jan 18 17:34 nss.cfg

그래서 이전 Opensuse 11 유효한 인증서 설치를 해결했습니다. (미안합니다!!)

$ ll
total 616
-rw-r--r-- 1 root 220065 Jan 31 15:48 ca-bundle.pem
-rw-r--r-- 1 root    363 Feb 28 14:17 ca-bundle.pem.old
-rw-r--r-- 1 root 161555 Jan 31 15:48 java-cacerts

keytool을 사용하여 새 도구를 생성 할 수 있음을 이해했습니다 ( http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-April/008961.html ). 곧 그렇게해야 할 것 같습니다.

regards lellis


Have the same issue. Resolved it by installing ca-certificate bundle from Mozilla:

$ zypper in ca-certificates-mozilla
The following NEW package is going to be installed:
ca-certificates-mozilla 

1 new package to install.
Retrieving package ca-certificates-mozilla-1.85-8.8.1.noarch
(1/1), 143.7 KiB (239.1 KiB unpacked)
Retrieving: ca-certificates-mozilla-1.85-8.8.1.noarch.rpm.....................[done]
Installing: ca-certificates-mozilla-1.85-8.8.1 ...............................[done]
Additional rpm output:
Updating certificates in /etc/ssl/certs...
144 added, 0 removed.
creating /var/lib/ca-certificates/ca-bundle.pem ...
creating /var/lib/ca-certificates/java-cacerts ...
144 added, 0 removed.

$ ll /var/lib/ca-certificates/
total 392
drwxr-xr-x  2 root root   4096 Apr 26 07:25 ./
drwxr-xr-x 30 root root   4096 Apr 25 15:00 ../
-rw-r--r--  1 root root 220196 Apr 26 07:25 ca-bundle.pem
-rw-r--r--  1 root root 161555 Apr 26 07:25 java-cacerts

P.S.

$ cat /etc/SuSE-release
openSUSE 12.2 (x86_64)
VERSION = 12.2
CODENAME = Mantis
$ java -version
java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.4) (suse-3.20.1-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

This happens because Access Privilege varies from OS to OS. Windows access hierarchy is different from Unix. However, this could be overcome by following these simple steps:

  1. Increase accessibility with AccessController.doPrivileged(java.security.PrivilegedAction subclass)
  2. Set your own java.security.Provider subclass as security property. a. Security.insertProviderAt(new , 2);
  3. Set your Algorythm with Security.setProperty("ssl.TrustManagerFactory.algorithm" , “XTrust509”);

I get this same error on my Windows 7 machine when the permissions on my cacerts file in my C:\Program Files\Java\jdk1.7.0_51\jre\lib\security folder are not set correctly.

To resolve the issue, I allow the SERVICE and INTERACTIVE users to have all modify permissions on cacerts except "change permissions" and "take ownership" (from Advanced Settings, in the Security properties). I assume that allowing these services to both read and write extended attributes may have something to do with the error going away.

참고URL : https://stackoverflow.com/questions/4764611/java-security-invalidalgorithmparameterexception-the-trustanchors-parameter-mus

반응형