Errore: il parametro trustAnchors deve essere non vuoto

Sto cercando di configurare la mia e-mail su Jenkins / Hudson e ricevo costantemente l'errore:

java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be
    non-empty

Ho visto una buona quantità di informazioni online sull'errore, ma non sono riuscito a farlo funzionare. Sto usando Sun JDK su Fedora Linux (non OpenJDK).

Ecco alcune cose che ho provato. Ho provato a seguire i consigli di questo post , ma copiare i dessert da Windows sul mio box Fedora che ospita Jenkins non ha funzionato. Ho provato a seguire questa guida mentre sto cercando di configurare Gmail come mio server SMTP, ma non ha funzionato neanche. Ho anche provato a scaricare e spostare manualmente i file Cacert e spostarli nella mia cartella Java usando una variazione dei comandi in questa guida .

Sono aperto a qualsiasi suggerimento, poiché attualmente sono bloccato. Ho ottenuto che funzioni da un server Windows Hudson, ma sto lottando su Linux.

Questo bizzarro messaggio indica che il truststore che hai specificato era:

• vuoto,
• non trovato, o
• impossibile aprire (ad esempio a causa delle autorizzazioni di accesso).

Vedi anche la risposta di @ AdamPlumb di seguito .

Per eseguire il debug di questo problema (l'ho scritto qui ) e capire quale truststore viene utilizzato, è possibile aggiungere la proprietà javax.net.debug = all e quindi filtrare i registri su truststore. Puoi anche giocare con la proprietà javax.net.ssl.trustStore per specificare un truststore specifico. Per esempio :

    java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=/Another/path/to/cacerts -jar test_get_https-0.0.1-SNAPSHOT-jar-with-dependencies.jar https://www.calca.com.py 2>&1| grep -i truststore

In Ubuntu 18.04 , questo errore ha una causa diversa (JEP 229, passa dal jksformato predefinito del keystore al pkcs12formato e la generazione di file Debian cacerts usando l'impostazione predefinita per i nuovi file) e soluzioni alternative :

# Ubuntu 18.04 and various Docker images such as openjdk:9-jdk throw exceptions when
# Java applications use SSL and HTTPS, because Java 9 changed a file format, if you
# create that file from scratch, like Debian / Ubuntu do.
#
# Before applying, run your application with the Java command line parameter
#  java -Djavax.net.ssl.trustStorePassword=changeit ...
# to verify that this workaround is relevant to your particular issue.
#
# The parameter by itself can be used as a workaround, as well.

# 0. First make yourself root with 'sudo bash'.

# 1. Save an empty JKS file with the default 'changeit' password for Java cacerts.
#    Use 'printf' instead of 'echo' for Dockerfile RUN compatibility.
/usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/java/cacerts

# 2. Re-add all the CA certs into the previously empty file.
/var/lib/dpkg/info/ca-certificates-java.postinst configure

Stato (07-08-2018) , il bug è stato corretto in Ubuntu Bionic LTS 18.04.1 e Ubuntu Cosmic 18.10.

🗹 Ubuntu 1770553: [SRU] backport ca-certificati-java da cosmic (20180413ubuntu1)

🗹 Ubuntu 1769013: Unire ca-certificati-java 20180413 (principale) da Debian unstable (principale)

🗹 Ubuntu 1739631: una nuova installazione con JDK 9 non può utilizzare il file di archivio chiavi cKert PKCS12 generato

🗹 docker -library 145: l'immagine 9-jdk presenta problemi SSL

🗹 Debian 894979: ca-certificati-java: non funziona con OpenJDK 9, le applicazioni non funzionano con InvalidAlgorithmParameterException: il parametro trustAnchors deve essere non vuoto

🗹 JDK-8044445: JEP 229: creazione di keystore PKCS12 per impostazione predefinita

🖺 JEP 229: creazione di PKCS12 per impostazione predefinita

Se il problema persiste dopo questa soluzione alternativa, è possibile assicurarsi di eseguire effettivamente la distribuzione Java appena risolta.

$ which java
/usr/bin/java

È possibile impostare le alternative Java su "auto" con:

$ sudo update-java-alternatives -a
update-alternatives: error: no alternatives for mozilla-javaplugin.so

Puoi ricontrollare la versione Java che stai eseguendo:

$ java --version
openjdk 10.0.1 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)

Esistono anche soluzioni alternative, ma quelle hanno i loro effetti collaterali che richiedono una manutenzione futura extra, senza alcun vantaggio.

La soluzione migliore successiva è aggiungere la riga

javax.net.ssl.trustStorePassword=changeit

ai file

/etc/java-9-openjdk/management/management.properties
/etc/java-11-openjdk/management/management.properties

qualunque esista.

La terza soluzione meno problematica consiste nel modificare il valore di

keystore.type=pkcs12

per

keystore.type=jks

nei file

/etc/java-9-openjdk/security/java.security
/etc/java-11-openjdk/security/java.security

a seconda di quale esiste, quindi rimuovere il cacertsfile e rigenerarlo nel modo descritto nell'ultima riga dello script di soluzione alternativa nella parte superiore del post.

Questo risolto il problema per me su Ubuntu:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

(trovato qui: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1396760 )

ca-certificates-java non è una dipendenza in Oracle JDK / JRE, quindi deve essere esplicitamente installato.

Su Ubuntu 18.04 la causa principale è un conflitto tra openjdk-11-jdk (che è predefinito) e altri pacchetti a seconda di esso. È già stato risolto in Debian e verrà presto incluso in Ubuntu. Nel frattempo, la soluzione più semplice è ridurre il tuo java alla versione 8. Altre soluzioni impiegate ca-certificates-javasono molto più complicate.

Per prima cosa rimuovi i pacchetti in conflitto:

sudo apt-get remove --purge openjdk* java-common default-jdk
sudo apt-get autoremove --purge

Verifica se tutti i pacchetti correlati sono stati rimossi correttamente:

sudo update-alternatives --config java

Il sistema ti chiederà che non è disponibile alcuna configurazione Java per la configurazione , altrimenti questa soluzione alternativa non riesce .

Quindi reinstallare i pacchetti richiesti:

sudo apt-get install openjdk-8-jdk

Fondamentalmente EJP ha risposto alla domanda (e mi rendo conto che questa ha una risposta accettata), ma ho appena affrontato questo problema e ho voluto immortalare la mia soluzione.

Ho riscontrato l' InvalidAlgorithmParameterExceptionerrore su un server Jira ospitato che avevo precedentemente impostato per l'accesso solo SSL. Il problema era che avevo impostato il mio keystore nel formato PKCS # 12, ma il mio truststore era nel formato JKS.

Nel mio caso, avevo modificato il mio server.xmlfile per specificare il keystoreType su PKCS, ma non ho specificato il truststoreType, quindi per impostazione predefinita è qualunque sia il keystoreType. Specificare il truststoreType esplicitamente come JKS lo ha risolto per me.

Ho incontrato questa soluzione dal post del blog Risolvere il problema trustAnchors durante l'esecuzione di OpenJDK 7 su OS X :

Risolvere il problema trustAnchors quando si esegue OpenJDK 7 su OS X. Se si esegue OpenJDK 7 su OS X e si è verificata questa eccezione:

Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors
    parameter must be non-empty

C'è una soluzione semplice. Basta collegare lo stesso file cacerts che utilizza JDK 1.6 di Apple:

cd $(/usr/libexec/java_home -v 1.7)/jre/lib/security
ln -fsh /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts

Devi farlo per ogni versione OpenJDK che hai installato. Passa -v 1.7alla versione che desideri correggere. Esegui /usr/libexec/java_home -Vper vedere tutti i JRE e i JDK che hai installato.

Forse i ragazzi di OpenJDK potrebbero aggiungere questo ai loro script di installazione.

In Ubuntu 12.10 (Quantal Quetzal) o versioni successive, i certificati sono conservati nel pacchetto ca-certificati-java . L'utilizzo -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacertsli prenderà indipendentemente da quale JDK stai usando.

Ho riscontrato questo esatto problema su OS X, utilizzando JDK 1.7, dopo l'aggiornamento a OS X v10.9 (Mavericks). La soluzione che ha funzionato per me è stata semplicemente reinstallare la versione Apple di Java, disponibile su http://support.apple.com/kb/DL1572 .

Ho corso

sudo update-ca-certificates -f

per creare un file di certificato, quindi:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Ero di nuovo in affari, grazie ragazzi. È un peccato che non sia incluso nell'installazione, ma alla fine ci sono arrivato.

L'errore indica che il sistema non è in grado di trovare il truststore nel percorso fornito con il parametro javax.net.ssl.trustStore .

In Windows ho copiato il cacertsfile dalla jre/lib/securitydirectory di installazione di Eclipse (nella stessa posizione del eclipse.inifile) e ho aggiunto le seguenti impostazioni in eclipse.ini:

-Djavax.net.ssl.trustStore=cacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.ssl.trustStoreType=JKS

Ho avuto qualche problema con il percorso dei cacerts (la variabile di ambiente% java_home% è in qualche modo sovrascritta), quindi ho usato questa banale soluzione.

L'idea è di fornire un percorso valido al file truststore - idealmente sarebbe usarne uno relativo. Puoi anche usare un percorso assoluto.

Per assicurarsi che il tipo di negozio sia JKS, eseguire il comando seguente:

keytool -list -keystore cacerts

Keystore type: JKS
Keystore provider: SUN

Rimuovere il pacchetto ca-certificati-java e installarlo di nuovo ha funzionato per me ( Ubuntu MATE 17.10 (Artful Aardvark)).

sudo dpkg --purge --force-depends ca-certificates-java

sudo apt-get install ca-certificates-java

Grazie, jdstrand: Commento 1 per il bug 983302, Re: ca-certificati-java non riesce a installare Java Cacerts su Oneiric Ocelot .

Ho avuto molti problemi di sicurezza dopo l'aggiornamento a OS X v10.9 (Mavericks):

• Problema SSL con Amazon AWS
• Peer non autenticato con Maven ed Eclipse
• trustAnchors il parametro deve essere non vuoto

Ho applicato questo aggiornamento Java e risolto tutti i miei problemi: http://support.apple.com/kb/DL1572?viewlocale=en_US

Mi aspettavo cose del genere, dato che utilizzo una JVM alternativa nel mio Talend Open Studio (il supporto al momento esiste solo fino a JDK 1.7). Uso 8 per motivi di sicurezza ... comunque

• Aggiorna il tuo archivio certificati:

  sudo update-ca-certificates -f

poi

• aggiungere un nuovo valore nei parametri di inizializzazione

  sudo gedit $(path to your architecture specific ini i.e. TOS_DI...ini)
  
  Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts

Per me, la seconda voce ha funzionato. Penso che, a seconda della versione di Talend Open Studio / TEnt + JVM, abbia un nome di parametro diverso, ma cerca lo stesso file di archivio chiavi.

Per me è stato causato dalla mancanza di un TrustedCertEntry nel truststore.

Per testare, utilizzare:

keytool -list -keystore keystore.jks

Mi dà:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

cert-alias, 31-Jul-2017, PrivateKeyEntry

Anche se il mio PrivateKeyEntry contiene una CA, è necessario importarlo separatamente :

keytool -import -alias root-ca1 -file rootca.crt -keystore keystore.jks

Importa il certificato e quindi la riesecuzione keytool -list -keystore keystore.jksora fornisce:

Your keystore contains 2 entries

cert-alias, 31-Jul-2017, PrivateKeyEntry,
Certificate fingerprint (SHA1):
<fingerprint>
root-ca1, 04-Aug-2017, trustedCertEntry,
Certificate fingerprint (SHA1):
<fingerprint>

Ora ha un TrustedCertEntry e Tomcat si avvierà correttamente.

Alcuni rilasci di venditori OpenJDK hanno causato ciò avendo un cacertsfile vuoto distribuito con il binario. Il bug è spiegato qui: https://github.com/AdoptOpenJDK/openjdk-build/issues/555

È possibile copiare adoptOpenJdk8\jre\lib\security\cacertssul file da una vecchia installazione come c:\Program Files\Java\jdk1.8.0_192\jre\lib\security\cacerts.

La versione buggy di AdoptOpenJDK è https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.zip

Se lo riscontri su Ubuntu con JDK9 e Maven, puoi aggiungere questa opzione JVM: controlla prima che esista il percorso:

-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts

Se il file è mancante, prova a installare ca-certificati-java come qualcuno ha notato:

sudo apt install ca-certificates-java

Ho avuto questo messaggio di errore su Java 9.0.1 su Linux. Era dovuto a un bug noto di JDK, in cui il file cacerts è vuoto nel pacchetto binario .tar.gz (scaricato da http://jdk.java.net/9/ ).

Vedere il paragrafo "Problemi noti" delle Note di rilascio di JDK 9.0.1 , che dice "TLS non funziona per impostazione predefinita su OpenJDK 9".

Su Debian / Ubuntu (e probabilmente altri derivati), una semplice soluzione alternativa è quella di sostituire il file cacerts con quello del pacchetto "ca-certificati-java":

sudo apt install ca-certificates-java
cp /etc/ssl/certs/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

Su Red Hat Linux / CentOS, puoi fare lo stesso dal pacchetto "ca-certificati":

sudo yum install ca-certificates
cp /etc/pki/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

Ho avuto questo problema durante il tentativo di utilizzare Maven 3, dopo l'aggiornamento da Ubuntu 16.04 LTS (Xenial Xerus) a Ubuntu 18.04 LTS (Bionic Beaver).

Il controllo di / usr / lib / jvm / java-8-oracle / jre / lib / security ha mostrato che il mio file cacerts era un collegamento simbolico che puntava a /etc/ssl/certs/java/cacerts .

Ho anche avuto un file con il nome sospetto cacerts.original.

Ho rinominato cacerts.originala cacerts, e che risolto il problema.

L'ho riscontrato anche su OS X dopo aver aggiornato OS X v10.9 (Mavericks), quando si utilizzava il vecchio Java 6 e si tentava di accedere a un URL HTTPS. La correzione era l'inverso di Peter Kriens; Ho dovuto copiare lo cacertsspazio da 1.7 nella posizione collegata dalla versione 1.6:

(as root)
umask 022
mkdir -p /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security
cp $(/usr/libexec/java_home -v 1.7)/jre/lib/security/cacerts \
    /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security

Nel mio caso il file JKS utilizzato nell'applicazione client è stato danneggiato. Ne ho creato uno nuovo e in esso ho importato i certificati SSL del server di destinazione. Quindi ho usato il nuovo file JKS nell'applicazione client come un truststore, come:

System.setProperty("javax.net.ssl.trustStore",path_to_your_cacerts_file);

Fonte: SSL SSL e keystore dei certificati

Uso lo strumento (KeyStore Explorer) per creare il nuovo JKS. Puoi scaricarlo da questo link, KeyStore Explorer .

Potresti anche riscontrare questo errore dopo l'aggiornamento a Spring Boot 1.4.1 (o più recente) perché porta Tomcat 8.5.5 come parte delle sue dipendenze.

Il problema è dovuto al modo in cui Tomcat gestisce il truststore. Se ti capita di aver specificato la posizione del tuo negozio di fiducia come la stessa del keystore nella configurazione di Spring Boot, probabilmente riceverai il trustAnchors parameter must be non-emptymessaggio quando avvii l'applicazione.

server.ssl.key-store=classpath:server.jks
server.ssl.trust-store=classpath:server.jks

Rimuovi semplicemente la server.ssl.trust-storeconfigurazione se non sai di averne bisogno, nel qual caso consulta i link sottostanti.

I seguenti problemi contengono ulteriori dettagli sul problema:

• Il connettore HTTPS Tomcat non si avvia con 1.4.1 # 7069
• SSL-client-auth con certificato autofirmato ha smesso di funzionare # 7406
• Esegui l'upgrade a Tomcat 8.5.5 # 6703

Ho riscontrato questo problema con Android SDK sdkmanager. Per me questa soluzione ha funzionato:

1. Vai a /usr/lib/jvm/java-8-oracle/jre/lib/security/
2. Sostituisci cacertconcacert.original

Il cacertfile era minuscolo (22B). Ho installato oracle-java8-installerda ppa:webupd8team/java(secondo questo manuale: https://docs.nativescript.org/start/ns-setup-linux ).

Per la cronaca, nessuna delle risposte qui ha funzionato per me. La mia build Gradle ha iniziato a fallire misteriosamente con questo errore, incapace di recuperare HEAD dalla centrale di Maven per un particolare file POM .

Si è scoperto che avevo impostato JAVA_HOME sulla mia build personale di OpenJDK, che avevo creato per il debug di un problema javac. Risolto il problema con il ripristino del JDK installato sul mio sistema.

Su Red Hat Linux ho risolto questo problema importando i certificati in /etc/pki/java/cacerts.

System.setProperty("javax.net.ssl.trustStore", "C:\\Users\\user-id\\Desktop\\tomcat\\cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "passwd");

Devi aggiungere le due righe precedenti al tuo codice. Non è in grado di trovare il truststore.

Ho riscontrato questo problema durante l'esecuzione di una particolare suite di Android per i test su Ubuntu 14.04 (Trusty Tahr). Due cose hanno funzionato per me come suggerito da Shaheen:

sudo update-ca-certificates -f

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Nessuna delle soluzioni che ho trovato su Internet ha funzionato, ma una versione modificata della risposta di Peter Kriens sembra fare il lavoro.

Per prima cosa trova la tua cartella Java eseguendo /usr/libexec/java_home. Per me era la 1.6.0.jdkversione. Quindi vai alla sua lib/securitysottocartella (per me/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security ).

Quindi eliminare il cacertsfile se ne esiste già uno e cercarne uno sul sistema con sudo find / -name "cacerts". Ha trovato più elementi per me, nelle versioni di Xcode o altre applicazioni che avevo installato, ma anche a /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacertscui ho scelto.

Utilizzare quel file e creare un collegamento simbolico ad esso (all'interno della cartella Java da prima) sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts", e dovrebbe funzionare.

Ho entrambi - Java dal download 2017-001 di Apple ( https://support.apple.com/kb/dl1572 - Suppongo che sia da dove provengono i certificati corretti) e quello di Oracle installato su Mac OS X v10.12 (Sierra) .

su Ubuntu 14.04 con openjdk 11 da ppa: openjdk-r / ppa questo ha funzionato per me:

in java.security modificare il tipo di archivio chiavi in

keystore.type=jks

poi:

sudo dpkg --purge --force-depends ca-certificates-java
sudo apt-get install ca-certificates-java

quando controlli se ha funzionato, assicurati di non usare alcun demone con java precedente ancora in esecuzione (es. --no-daemonopzione per gradle)

questo bug descrive tutto bene e ti aiuterà a capire cosa sta succedendo https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1739631

Su Ubuntu 18.04 dovevo usare OpenJDK 1.7 per il mantenimento di un vecchio progetto. Ho scaricato il pacchetto binario. Ma quando ho eseguito il mio script su di esso ho avuto lo stesso errore.

La soluzione era rimuovere il cacertsfile del JDK scaricato nella jre/lib/securitycartella e quindi crearlo come link simbolico al cacertsfile di sistema in /etc/ssl/certs/java/:

sudo ln -s /etc/ssl/certs/java/cacerts /path/to/downloaded/java/jre/lib/security/cacerts

Una piccola possibilità che questo possa aiutare chiunque ma .... per chiunque esegua Java 8 da un'immagine Docker su un Raspberry Pi (usando la CPU AMD) ho ottenuto il seguente Dockerfile da compilare ed eseguire con successo per me

FROM hypriot/rpi-java
USER root

WORKDIR /usr/build/

RUN /usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/java/cacerts
RUN update-ca-certificates -f
RUN /var/lib/dpkg/info/ca-certificates-java.postinst configure

EXPOSE 8080

ARG JAR_FILE=target/app-0.0.1-SNAPSHOT.jar

ADD ${JAR_FILE} app.jar

ENTRYPOINT ["java", "-Djavax.net.ssl.trustStorePassword=changeit", "-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts", "-jar", "app.jar"]