Errore: il parametro trustAnchors deve essere non vuoto


492

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.

Risposte:


513

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

1
Grazie EJP, ho visto il tuo post qui ma non ero sicuro di come verificare che il truststore sia lì. Inoltre ho visualizzato il mio file server.xml ma non ero sicuro di come verificare che il truststore sia a posto. Devo solo controllare il pref keystoreFile = "conf / .keystore" (keystoreFile non era presente in quel file)?
David Gill,

2
La risposta è stata su come la stavo importando. Mi sembrava di aver perso un passaggio cruciale. Vedi [Errore Java InvalidAlgorithmParameterException] [1] [1]: jyotirbhandari.blogspot.com/2011/09/…
David Gill

2
Confermata che questa risposta è corretta. Stavo ottenendo l'errore sotto Tomcat. Avevo il mio truststore ${CATALINA_HOME}\confma CATALINA_HOMEnon mi stavo preparando, quindi Tomcat stava cercando \confil truststore.
SingleShot

4
@BubblewareTechnology No, l'errore era nel nome del file, non nel modo in cui hai importato il certificato nel file. Il tuo blog non è corretto. Inoltre, non dovresti consigliare di modificare il file JRE $ / cacerts. Cambierà il prossimo aggiornamento di Java. È necessario un processo che lo copia, aggiunge il proprio certificato alla copia e la utilizza come truststore. Ripeti ogni aggiornamento Java. E non devi assolutamente dire a Java del proprio truststore, solo del tuo, se è diverso.
Marchese di Lorne,

3
Aggiungerò una svolta: anche quando il truststore esiste, è accessibile, è nel formato giusto, se è COMPLETAMENTE VUOTO, questo è l'errore che puoi ottenere con varie librerie (incluso Apache HttpClient).
Alan Franzoni,

265

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.


50
Utenti Ubuntu 18, leggi questo! questo salverà molte ore della tua vita! Grazie!
Vak,

5
Questa risposta mi ha aiutato a correggere lo stesso errore con Maven su Ubuntu 18.04. Ho dovuto cambiare il proprietario del file / etc / ssl / certs / java / cacerts da root a me stesso per poterlo scrivere. Poi l'ho ripristinato.
Yuri Gor

77
Ho eseguito sudo rm / etc / ssl / certs / java / cacerts e poi sudo update-ca-certificati -f e questo ha risolto il mio problema in Kubuntu 18.04.
gennaio

2
@jsn, grazie per le soluzioni, funziona anche su Linux mint 19, basato su Ubuntu 18.04
Samrat,

2
La soluzione di @ jsn ha funzionato anche per Debian Stretch + openjdk8
HRJ il

105

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.


2
Grazie, questo ha risolto il problema quando mi sono imbattuto in Ubuntu 15.04.
Macil,

Ha lavorato su Raspbian su Raspberry Pi
Defozo

1
Risolto questo problema con i backport stabili di Debian jesse con OpenJDK8 e questo ha risolto il problema. Lo usavo mentre costruivo immagini Docker. :)
Tuxdude,

9
Purtroppo non funziona su Ubuntu MATE 18.04. Proverò a reinstallare Java.
Pranav A.

1
@codefx - Ho fatto ciò che mi hai suggerito e non funziona - su Ubuntu 18.x con Java 10 (impostazione predefinita).
mzedeler,

69

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

Questa descrizione è di fatto errata e risolve il problema solo nello stesso modo in cui la reinstallazione di Windows potrebbe risolvere un problema. Non è necessario rimuovere tutti i pacchetti Java. Se vuoi procedere in questo modo, devi solo installare il openjdk-8-jdkpacchetto, rimuovere il /etc/ssl/certs/java/cacertsfile ed eseguire, sudo update-ca-certificates -fche è il modo rotatorio di passare da un pkcs12file cacerts formattato a uno jksformattato, come descritto altrove in questo thread.
Mikael Gueck,

1
@MikaelGueck Mentre la logica sembra essere dalla tua parte, sono qui per assicurarti che in precedenza ho fatto esattamente quello che è stato descritto nel tuo commento e nelle risposte più votate, e nel 18.04 questa è l'unica risposta che ha funzionato . Penso che il tuo downvote dovrebbe trasformarsi in un voto, o almeno svanire, dal momento che è altamente immeritato.
Andrea Ligios,

@AndreaLigios, puoi leggere tu stesso gli script, sono piuttosto brevi. Hanno un set hardcoded di percorsi JAVA_HOME dalle 8 alle 10, li provano uno alla volta, chiamano il generatore di file CA Debian che puoi anche leggere, che usa il formato di file esistente, perché il codice del gestore di file key JDK, che puoi leggere, ha una modalità di fallback di compatibilità. Se il tuo computer esegue questo semplice software in modo diverso, potresti avere altri problemi con esso. Hai modificato le tue alternative Java e chiamato alcune altre JVM, perché la rimozione potrebbe aver ripristinato le alternative?
Mikael Gueck,

1
@MikaelGueck sì, in uno dei precedenti tentativi ho modificato le mie alternative java, quindi probabilmente è stato quello. Sono il primo a cui piace scavare nel codice sorgente e scoprire come funzionano le cose, ma questo oggi non era il mio obiettivo, era solo uno tra 5-6 diversi ostacoli imprevisti che avevo sulla strada per il mio vero obiettivo. Questa risposta mi ha permesso di risolvere il problema in meno di 2 minuti! Quanto tempo avrei dovuto esaminare gli script e trovare una soluzione migliore? E per cosa, per salvare alcuni megabyte? Questo è drastico, ma funziona (e non importa quale sia il problema), quindi un grande ringraziamento a OP per chi è occupato da morire
Andrea Ligios,

1
Ho cercato una soluzione per 2 giorni e la tua risposta ha risolto il mio problema, grazie. Mi sposto su Kubuntu 18.04, ci ha funzionato.
guepardomar,

55

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.


bene, ti aiuto a immortalare la soluzione per il tuo caso da sballo. ecco dove diventa interessante.
n611x007,

2
Questo era esattamente il mio problema. Stavo usando Spring Boot 1.4.2.RELEASE e avevo un keystore hardware e un truststore software. Ho specificato il provider e il tipo per il keystore, ma non il truststore. Di conseguenza, il truststore ha utilizzato provider e tipo errati. Specificare quelli (SUN e JKS) ha risolto il problema.
Kenco,

12
come hai fatto esattamente? (windows qui)
tatsu

2
Incontralo oggi con il mio Android Grandle, quasi capisco quello che dici ma non dici come risolverlo. Risposta non utile
Lothar,

52

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.


1
Il mio comando "ln" (su OSX 10.6.8) non ha un'opzione "h"; che cosa si intende fare?
Andrew Swan,

1
Ah, avevo due comandi "ln", uno in / usr / bin (impostazione predefinita) e uno in / bin; quest'ultimo aveva un'opzione "h" e funzionava.
Andrew Swan,

Con questa tecnica ln ho risolto il problema con la mia installazione 1.6 rotta che si collegava ai dessert dall'installazione del sistema 1.8. Grazie!
A21z,

1
Per i lettori futuri: sembra che è necessario anche gli altri 3 file che si trovano nella securitycartella di ( blacklisted.certs, local_policy.jar, e US_export_policy.jar) per Java per essere felice.
awksp,

@Peter Kriens, perché collegato a cacertsunder jredirectory?
BAE

45

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.


54
Ho scoperto che dovevo eseguire update-ca-certificates -fmanualmente, per popolare il file cacerts
Portablejim

4
@Portablejim Grazie. Il tuo commento ha risolto il primo problema che ho riscontrato durante la creazione di Apache Spark su Ubuntu 15.04beta.
Paul,

1
Grazie @Portablejim, il tuo commento ha funzionato per me su Ubuntu 15.04.
David Berg,

Grazie. Questo è stato risolto il mio problema con PhpStrom + JDK con patch. Ho scritto questa chiave nel file "phpstorm64.vmoptions".
Vijit,

Non funziona per me in Ubuntu 18.04 e JDK è 1.8.0_62
Devendra Singraul,

34

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 riscontrato questo con Java 6 utilizzato da Grails su OSX. Ho anche installato Java 7 di Oracle e aggiornato a Mavericks. Anche la reinstallazione di Java 6 dal sito Web di Apple ha risolto il problema.
pm_labs

Ci siamo imbattuti in questo durante l'installazione di open jdk 6 su un cloud box di Ubuntu. Bello vedere un volto familiare, BTW
Ben Hutchison,

30

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.


Quando corro sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure**ricevosudo: /var/lib/dpkg/info/ca-certificates-java.postinst: command not found
Magick il

Basta sudo update-ca-certificates -fbasta su Debian Jessie con openjdk-8-jre-headlessda Jessie-backports, fino a quando ca-certificates-javaè installato. Penso che l'ordine di installazione sia importante (JRE dopo ca-certificates-javapotrebbe causare questo, poiché quest'ultimo non ha alcun trigger per il backported Java 8).
mirabilos,

2
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure senza stelle **
Yu Jiaao,

update-ca-certificates -fè la cosa che l'ha risolto. Non avevo bisogno del secondo comando
Mark Jeronimus il

17

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

2
Questa è l'unica risposta che ha funzionato davvero. Grazie @razvanone
Akshar Patel,

1
Sono riuscito a colpire un piccolo "gotcha": le tre righe nel file eclipse.ini devono trovarsi su tre linee separate effettive. Inizialmente li ho messi tutti su una riga ed eclissi non l'ha raccolto.
SiKing

16

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 .


11

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


5
Ugh. Java 6 ha superato molti anni la fine del supporto pubblico ed è sicuramente pieno di falle nella sicurezza. Apple lo rende disponibile per il download in modo che il software precedente che non può essere eseguito con Java 7/8 possa continuare a essere eseguito, ma non dovrebbe essere utilizzato per effettuare connessioni SSL a servizi su Internet pubblico, come 1. AWS, 2. Maven Centrale, 3. qualsiasi altra cosa.
Zac Thompson,

10

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.


4
Da dove hai preso la proprietà javax.net.ssl.trustAnchors? Non è menzionato nella documentazione JSSE.
Marchese di Lorne,

10

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.


NB controlla il tutorial di baeldung con un utile Makefile come scorciatoia per la creazione di keystore e truststore (progetto spring-security-x509) baeldung.com/x-509-authentication-in-spring-security
hello_earth

9

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


Penso che sia stato così anche per me. In AdoptOpenJDK 202 questo bug è presente e nel 222 funziona. Quindi aggiorna il tuo jdk se possibile.
Marty,

6

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

Se usi la finestra mobile puoi provare anche l'immagine "maven: 3-jdk-9-slim" invece di "maven: 3-jdk-9"
Konstantin Pavlov,

Grazie, questo ha funzionato per me per openjdk-8-jdk in Ubuntu 18.04
Aftab Naveed

4

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

4

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.


Il cacerts.originalfile era nel jksformato ed è stato generato con Java 8 di Ubuntu 16.04, che lo utilizzava come predefinito. Il cacertsfile era nel pkcs12formato, generato da Java 10 di Ubuntu 18.04, che utilizza questo formato come predefinito. Come spiegato altrove in questo thread, il nuovo formato richiede di passare la password all'eseguibile. Ma fino a quando si genera un nuovo jks cacertsfile vuoto o ne si copia uno vecchio, il successivo processo di generazione dei cacert svuota il file esistente e lo riempie con i certificati CA dal file system.
Mikael Gueck,

3

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

1
Il comando qui tenta di copiare una directory in un file; Non ha alcun senso.
praseodym,

Concordo con la valutazione dell'uso di una soluzione inversa. Ho scoperto che jdk1.6 aveva un softlink non funzionante /Library/Java/JavaVirtualMachines/1.6.0_33-b03-424.jdk/Contents/Home/lib/security/cacerts -> /System/Library/Java/Support/CoreDeploy.bundle / Contents / Home / lib / security / cacerts. Così ho ripreso il link non funzionante, quindi ho copiato i dessert dall'installazione jdk1.7.
James A Wilson,

NOTA: quando hai finito dovresti essere in grado di catalogare il file cacerts che hai copiato per convalidare le autorizzazioni.
Grigio

Inoltre, corretto cp per andare nella giusta direzione e aggiunto l'umask per mkdir e cp.
Grigio

3

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 .


keystore-explorer ha fatto il lavoro per me. Devi solo creare un keystore predefinito, esaminare e salvare il file del certificato per il sito / host.
Shantha Kumara,

3

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:


3

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 ).


2

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.


... che ha impedito di trovare il truststore, come da altre risposte.
Marchese di Lorne,

1
Sì, ma sapere che il truststore non può essere trovato è del tutto inutile se non riesci a capire perché non viene trovato. Ci sono molti modi possibili in cui può andare storto, ed è frustrante quando nessuno di loro è il modo particolare in cui sta fallendo per il tuo sistema.
user3562927

Tutti 'capita' di essere lo stesso errore: il truststore specificato non può essere aperto o era vuoto. Esistono milioni di modi in cui questa situazione potrebbe verificarsi e non c'è abbastanza spazio su SO per elencarli tutti.
Marchese di Lorne,

1

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


1
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.


2
In caso contrario, utilizzerà il truststore JRE e sarà sicuramente in grado di trovarlo. L'errore è causato da valori errati in questi parametri, non dalla loro assenza. Il file indicato nel codice si applica solo alla tua installazione, non in generale.
Marchese di Lorne,

Il modo corretto di impostare tali proprietà è passandole sulla riga di comando: java -Djavax.net.ssl.trustStore=/tmp/cacerts ...o se si desidera impostarle a livello globale per tutti i programmi eseguiti con un JDK, aggiungere la riga al management.propertiesfile del JDK .
Mikael Gueck,

1

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

1

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) .


1

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


1

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


1

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"]
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.