java.security.cert.CertificateException: i certificati non sono conformi ai vincoli dell’algoritmo

Ho un’applicazione di mapping in grado di aggiungere mappe di base ArcGIS 9.3+ a un URL. Uno degli URL che vorrei aggiungere proviene dall’URL di un cliente ed è protetto. La mia applicazione di mapping utilizzava Java 6 in precedenza ed era in grado di aggiungere l’URL sicuro senza problemi. Ora ho aggiornato a Java 7 e sto ottenendo un

"java.security.cert.CertificateException: Certificates does not conform to algorithm constraints" 

eccezione. Inizialmente, credo che sia così perché in Java 7, per impostazione predefinita, l’algoritmo MD2 per firmare i certificati SSL è disabilitato. Puoi vederlo nel file java.security:

 "jdk.certpath.disabledAlgorithms=MD2" 

Ma quando controllo l’ Certification Signature Algorithm della Certification Signature Algorithm di quell’URL, dice SHA-1 . Ciò che è ancora più strano è che se commento la "jdk.certpath.disabledAlgorithms=MD2" nel file java.security , l’URL funzionerà senza problemi. MD2 è usato da qualche altra parte durante il processo SSL? Mi sto perdendo qualcosa qui?

sfondo

MD2 è stato ampiamente riconosciuto come non sicuro e quindi disabilitato in Java nella versione JDK 6u17 (vedere le note di rilascio http://www.oracle.com/technetwork/java/javase/6u17-141447.html , “Disabilita MD2 nella convalida della catena di certificati”) , così come JDK 7, secondo la configurazione che hai indicato in java.security .

Verisign utilizzava un certificato radice di Classe 3 con l’algoritmo di firma md2WithRSAEncryption (seriale 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf ), ma deprecato e lo ha sostituito con un altro certificato con la stessa chiave e lo stesso nome, ma firmato con l’algoritmo sha1WithRSAEncryption . Tuttavia, alcuni server stanno ancora inviando il vecchio certificato firmato MD2 durante l’handshake SSL (ironicamente, mi sono imbattuto in questo problema con un server gestito da Verisign!).

Puoi verificare che questo è il caso con:

openssl s_client -showcerts -connect :

Le versioni recenti di JDK (ad esempio 6u21 e tutte le versioni rilasciate di 7) dovrebbero risolvere questo problema rimuovendo automaticamente i certificati con lo stesso emittente e la stessa chiave pubblica come un ancoraggio affidabile (nei cacerts per impostazione predefinita).

Se il problema persiste con i JDK più recenti

Verificare se si dispone di un gestore di trust personalizzato che implementa l’interfaccia X509TrustManager precedente. JDK 7+ dovrebbe essere compatibile con questa interfaccia, tuttavia sulla base delle mie indagini quando il gestore di fiducia implementa X509TrustManager anziché il nuovo X509ExtendedTrustManager ( docs ), JDK utilizza il proprio wrapper ( AbstractTrustManagerWrapper ) e in qualche modo ignora la correzione interna per questo problema .

La soluzione è:

  1. utilizzare il gestore sicuro predefinito o

  2. modifica il tuo gestore di fiducia personalizzato per estendere direttamente X509ExtendedTrustManager (una semplice modifica).

Eclipse non è riuscito a connettersi ai repository https SVN (dovrebbe inoltre applicarsi a qualsiasi app che utilizza SSL / TLS).

svn: E175002: La connessione è stata arrestata: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: i certificati non sono conformi ai vincoli dell’algoritmo

Il problema è stato causato dall’ultimo aggiornamento Java 8 OpenJDK che disabilita gli algoritmi relativi a MD5. Come soluzione alternativa fino all’emissione di nuovi certificati (se mai), modificare le seguenti chiavi nel file java.security

AVVERTIMENTO
Tieni presente che questo potrebbe avere implicazioni sulla sicurezza in quanto gli algoritmi disabilitati sono considerati deboli. In alternativa, la soluzione alternativa può essere applicata su base JVM tramite un’opzione della riga di comando per utilizzare un file java.security esterno con queste modifiche, ad esempio:
java -Djava.security.properties=/etc/sysconfig/noMD5.java.security
Per Eclipse , aggiungi una riga su eclipse.ini sotto -vmargs
-Djava.security.properties=/etc/sysconfig/noMD5.java.security

chiavi originali

 jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024 jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768 

cambiare a

 jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024 jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768 

Il file java.security si trova in linux 64 in /usr/lib64/jvm/java/jre/lib/security/java.security

Abbiamo questo problema con un database che non controlliamo e ha ripetuto un’altra soluzione (Quelle elencate qui non funzionavano). Per il mio avevo bisogno di:

 -Djdk.tls.client.protocols="TLSv1,TLSv1.1" 

Penso che nel mio caso abbia a che fare forzando un certo ordine.

Su Fedora 28, basta fare attenzione online

security.useSystemPropertiesFile = true

delle proprietà java.security .

Fedora 28 ha introdotto il file esterno di disabledAlgorithms control at

/etc/crypto-policies/back-ends/java.config

È ansible modificare questo file esterno o escluderlo da java.security.

è più probabile che questo accada perché da qualche parte lungo la catena dei certificati si ha un certificato, più probabilmente una vecchia radice, che è ancora firmata con l’algoritmo MD2RSA.

Devi localizzarlo nel tuo archivio certificati ed eliminarlo.

Quindi torna all’autorità di certificazione e chiedi loro la nuova radice.

Sarà più probabilmente la stessa radice con lo stesso periodo di validità, ma è stata ricertificata con SHA1RSA.

Spero che questo aiuto.

colleghi.

Ho affrontato questo problema durante lo sviluppo di test di automazione per la nostra API REST. JDK 7_80 è stato installato solo sulla mia macchina. Prima di installare JDK 8, tutto funzionava perfettamente e avevo la possibilità di ottenere token OAuth 2.0 con un JMeter . Dopo aver installato JDK 8, l’incubo con i Certificates does not conform to algorithm constraints .

Sia JMeter che Serenity non hanno avuto la possibilità di ottenere un token. JMeter utilizza la libreria JDK per effettuare la richiesta. La libreria solleva un’eccezione quando viene effettuata la chiamata alla libreria per connettersi agli endpoint che la utilizzano, ignorando la richiesta.

La prossima cosa è stata commentare tutte le righe dedicate a disabledAlgorithms in TUTTI i file java.security.

 C:\Java\jre7\lib\security\java.security C:\Java\jre8\lib\security\java.security C:\Java\jdk8\jre\lib\security\java.security C:\Java\jdk7\jre\lib\security\java.security 

Poi ha iniziato a funzionare finalmente. Lo so, è un approccio brutale, ma era il modo più semplice per risolverlo.

 # jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768 # jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024 

Ho questo problema in SOAP-UI e nessuna soluzione sopra non mi ha aiutato.

La soluzione giusta per me era aggiungere

-Dsoapui.sslcontext.algorithm = TLSv1

nel file vmoptions (nel mio caso era … \ SoapUI-5.4.0 \ bin \ SoapUI-5.4.0.vmoptions)

Poiché questo risultato è il primo che Google restituisce per questo errore, aggiungo che se qualcuno cerca il modo di cambiare le impostazioni di sicurezza java senza modificare il file globale java.security (ad esempio è necessario eseguire alcuni test), è ansible è sufficiente fornire un file di sicurezza sovrascritto dal parametro JVM -Djava.security.properties = il proprio / file / percorso in cui è ansible abilitare gli algoritmi necessari sovrascrivendo le disabilitazioni.

Usando openjdk-7 nella finestra mobile Ho montato un file con il contenuto https://gist.github.com/dcanvasroli/7d0831b1d5acc94c80209a5feb4e8f1c#file-jdk-security

 #Location to mount /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/java.security 

Grazie @ luis-muñoz