2013-04-12 78 views
61

Dostarczany jest wraz z plikiem kluczy jks o nazwie ABCC_client.store. Kiedy zaimportuję ten plik kluczy do cacerts i spróbuję go połączyć, mówi: Nie ma takiego błędu algorytmu. PFA StackTracePowodowane przez: java.security.UnrecoverableKeyException: Nie można odzyskać klucza

Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: com.sun.net.ssl.internal.ssl.DefaultSSLContextImpl) 
    at java.security.Provider$Service.newInstance(Provider.java:1245) 
    at sun.security.jca.GetInstance.getInstance(GetInstance.java:220) 
    at sun.security.jca.GetInstance.getInstance(GetInstance.java:147) 
    at javax.net.ssl.SSLContext.getInstance(SSLContext.java:125) 
    at javax.net.ssl.SSLContext.getDefault(SSLContext.java:68) 
    at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:102) 
    at org.apache.axis.components.net.JSSESocketFactory.initFactory(JSSESocketFactory.java:61) 
    at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:79) 
    ... 32 more 
Caused by: java.security.UnrecoverableKeyException: Cannot recover key 
    at sun.security.provider.KeyProtector.recover(KeyProtector.java:311) 
    at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:121) 
    at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:38) 
    at java.security.KeyStore.getKey(KeyStore.java:763) 
    at com.sun.net.ssl.internal.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:113) 
    at com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:48) 
    at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:239) 
    at com.sun.net.ssl.internal.ssl.DefaultSSLContextImpl.getDefaultKeyManager(DefaultSSLContextImpl.java:170) 
    at com.sun.net.ssl.internal.ssl.DefaultSSLContextImpl.<init>(DefaultSSLContextImpl.java:40) 
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) 
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) 
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513) 
    at java.lang.Class.newInstance0(Class.java:355) 
    at java.lang.Class.newInstance(Class.java:308) 
    at java.security.Provider$Service.newInstance(Provider.java:1221) 
    ... 39 more 

Ale jeśli mogę użyć tego magazynu kluczy niezależnie tzn bez dodawania go do cacerts to działa.

W wyniku niektórych badań Google prowadzących do mnie było http://joewlarson.com/blog/2009/03/25/java-ssl-use-the-same-password-for-keystore-and-key/, co oznacza, że ​​hasło może być inne dla klucza i magazynu kluczy.

+0

Trochę kodu, aby zobaczyć, co się nazywa, jeśli to możliwe? – Bruno

+0

Próbowałem wywołać metodę usługi sieci Web z poziomu kodu. Kod błędu: Unschemas.xmlsoap.org/soap/envelope/}Server.userException faultSubcode: faultString: java.net.SocketException : java.security.NoSuchAlgorithmException: Błąd podczas konstruowania implementacji (algorytm: domyślny, dostawca: SunJSSE, klasa: com.sun.net.ssl.internal.ssl.DefaultSSLContextImpl) –

+2

Może być powielony tutaj jest podobne [pytanie] (http: // /stackoverflow.com/questions/1321557/can-not-get-key-from-keystore) z asnwer. – icrovett

Odpowiedz

57

Hasło klucza prywatnego zdefiniowane w aplikacji/konfiguracji jest nieprawidłowe. Najpierw spróbuj weryfikacji hasło klucza prywatnego poprzez zmianę na inny, co następuje:

keytool -keypasswd -new changeit -keystore cacerts -storepass changeit -alias someapp -keypass password 

Powyższy przykład zmienia hasło z hasłem changeit. To polecenie zakończy się sukcesem, jeśli hasło do klucza prywatnego było hasłem.

+1

Podczas gdy nie użyłem tej odpowiedzi w odniesieniu do pytania.Było to pomocne przy sprawdzaniu poprawności pliku magazynu kluczy, przechowywaniu hasła, aliasu/klucza i hasła klucza. – Russ

+0

Pamiętaj, że po wykonaniu tego polecenia zmienisz hasło magazynu kluczy. Będziesz musiał ustawić hasło z powrotem na oryginalne. – gersonZaragocin

+0

w rzeczywistości wystarczy podać tylko "-keypasswd -keystore storefile -alias somealias' i wprowadzić wszystko inne w podpowiedzi. –

85

Jeśli używasz Tomcat 6 i wcześniejszych, upewnij się, że hasło magazynu kluczy i hasło klucza są takie same. Jeśli używasz Tomcat 7 i późniejszych, upewnij się, że są takie same lub że hasło klucza jest określone w pliku server.xml.

+9

To prawda. Odnośnik: https://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html#Prepare_the_Certificate_Keystore – Atharva

+1

Istotny cytat: Na koniec zostaniesz poproszony o podanie * klucza hasła *, które jest hasłem specjalnie dla tego certyfikatu (w przeciwieństwie do innych certyfikatów przechowywanych w tym samym pliku magazynu kluczy). Ty ** MUSISZ ** używaj tutaj tego samego hasła, które zostało użyte dla samego hasła magazynu kluczy. Jest to ograniczenie implementacji Tomcat. (Obecnie monit 'keytool' powie Ci, że naciśnięcie klawisza ENTER powoduje to automatycznie.) –

+0

Miałem ten problem w JMeter (https) coz Magazyn kluczy Java i różne hasła były różne. Ref https://stackoverflow.com/questions/2889238/keystore-change-passwords?noredirect=1&lq=1. zmienić hasło kluczowe, aby rozwiązać problem. Świetna pomoc! Dzięki. – Rishi

5

Miałem ten sam błąd, gdy zaimportowaliśmy klucz do magazynu kluczy, który został zbudowany przy użyciu 64-bitowej wersji OpenSSL. Kiedy wykonaliśmy tę samą procedurę, aby zaimportować klucz do magazynu kluczy, który został zbudowany przy użyciu 32-bitowej wersji OpenSSL, wszystko poszło dobrze.

+2

Przyczyną powyższego błędu jest java.security.UnrecoverableKeyException: Can not odzyskać klucz. Powodem tego może być fałszywe hasło, jak wspomniano powyżej, ale także kompilacja magazynu kluczy z 64-bitową implementacją OpenSSL. Dlatego uważam moją odpowiedź za kolejne możliwe rozwiązanie. Pomógł mi w tej samej sytuacji błędu, więc podałem rozwiązanie tutaj. – Heimi

+0

openssl nie tworzy plików kluczy Java. Czy możesz to wyjaśnić? –

+0

Thks za odpowiedź. Ten sam problem napotykam podczas wywoływania usług sieciowych https OpenESB 3.05. Postępuję zgodnie z instrukcjami i ponownie generuję plik jks z 32-bitową implementacją OpenSS i działa dobrze –

5

Aby nie mieć wyjątku Cannot recover key, musiałem zastosować pliki zasad jurysdykcji Java Cryptography Extension (JCE) Unlimited Strength Policy do instalacji Java, na której działała moja aplikacja. Wersję 8 tych plików można znaleźć pod numerem here lub najnowszą wersję należy umieścić pod numerem this page. Pobieranie zawiera plik wyjaśniający, jak zastosować pliki zasad.


Od JDK 8u151 nie jest konieczne dodawanie plików zasad. Zamiast tego pliki zasad jurysdykcji JCE są kontrolowane przez właściwość Security o nazwie crypto.policy. Ustawienie tego na unlimited z możliwością nieograniczonego korzystania z kryptografii przez JDK. Ponieważ informacje o wersji powiązane z powyższym stanem, można je ustawić za pomocą Security.setProperty() lub pliku java.security. Plik java.security można również dołączyć, dodając -Djava.security.properties=my_security.properties do polecenia, aby uruchomić program jako szczegółowy here.


Od JDK 8u161 nielimitowana kryptografia jest domyślnie włączona.

+0

Widzę ten błąd pomimo zainstalowania słoików plików strategii. – Adam

+0

@Adam Moje rozwiązanie dotyczy konkretnego przypadku, który może być inny niż ten, którego doświadczasz. Dodałem jednak aktualizację odzwierciedlającą zmianę, która nastąpiła w JDK 8u151. – WhiteKnight