I'm trying to use the Windows Certificate Store from Jetty for HTTPS communication.
After setting up a web-application on client site, it should be easier for the client to update an expired certificate in the Windows Certificate Store than having to create or update a keyStore file.
This is what I've done:
Download the latest version 9.4.26 from https://www.eclipse.org/jetty/download.html
Added the following lines in start.ini:
jetty.ssl.port=443
jetty.sslContext.keyStoreType=Windows-MY
Run as:
"jre\bin\java" -jar start.jar --module=https,deploy
And this is the error I get:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:218)
at org.eclipse.jetty.start.Main.start(Main.java:491)
at org.eclipse.jetty.start.Main.main(Main.java:77)
Caused by: java.lang.IllegalStateException: no valid keystore
at org.eclipse.jetty.util.security.CertificateUtils.getKeyStore(CertificateUtils.java:50)
at org.eclipse.jetty.util.ssl.SslContextFactory.loadKeyStore(SslContextFactory.java:1188)
at org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:323)
at org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
at org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:92)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:320)
at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at org.eclipse.jetty.server.Server.doStart(Server.java:385)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at org.eclipse.jetty.xml.XmlConfiguration.lambda$main$0(XmlConfiguration.java:1888)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1837)
... 7 more
I also tried to add or change lines, same result:
jetty.sslContext.keyStoreType=Windows-MY
jetty.sslContext.trustStoreType=Windows-ROOT
-
jetty.sslContext.keyStoreType=Windows-ROOT
-
jetty.sslContext.keyStoreType=Windows-MY
jetty.sslContext.trustStoreType=Windows-ROOT
jetty.sslContext.keyStorePath=NONE
jetty.sslContext.trustStorePath=NONE
If you see the source code of Jetty, they expect some file system resource to be passed as keystore and truststore path. The following exception would come when keystore or truststore patch does not exist:
Caused by: java.lang.IllegalStateException: no valid keystore
at rg.eclipse.jetty.util.security.CertificateUtils.getKeyStore(CertificateUtils.java:50)
However there is a trick to load Windows store. You can specify:
jetty.sslContext.keyStoreType=Windows-MY (or Windows-ROOT)
and for jetty.sslContext.keyStorePath, you can specify any dummy file path which exists on the file system (you can even create an empty txt file and give its path!). In this case, Windows Store would be loaded and the jetty side resource validation would also pass.
FYI, when you provide keystore type as Windows-MY or Windows-ROOT, it would simply ignore any file input stream (if passed) while loading the keystore. Ultimately only one keystore is loaded, i.e. Windows Store.
Related
I am trying to run Kafka producer client to publish some message to kafka broker. I have given the path to Keystore/Trust store along with Password. I was able to send the message to the broker when i deployed this on Apache tomcat. However when i tried to deploy the same application on websphere, i get error "Failed to load SSL keystore". I have given those directories read/write/execute permission. Is there something with websphere that needs different configuration / settings ?
Caused by: org.apache.kafka.common.KafkaException: org.apache.kafka.common.KafkaException: Failed to load SSL keystore /home/avaya/tcr/uc-ivr-nar-dev.dbplatform.portal.com.jks of type JKS
at org.apache.kafka.common.security.ssl.SslEngineBuilder.createSSLContext(SslEngineBuilder.java:160)
at org.apache.kafka.common.security.ssl.SslEngineBuilder.<init>(SslEngineBuilder.java:102)
at org.apache.kafka.common.security.ssl.SslFactory.configure(SslFactory.java:93)
at org.apache.kafka.common.network.SslChannelBuilder.configure(SslChannelBuilder.java:71)
... 37 more
Caused by: org.apache.kafka.common.KafkaException: Failed to load SSL keystore /home/avaya/tcr/uc-ivr-nar-dev.dbplatform.portal.com.jks of type JKS
at org.apache.kafka.common.security.ssl.SslEngineBuilder$SecurityStore.load(SslEngineBuilder.java:289)
at org.apache.kafka.common.security.ssl.SslEngineBuilder.createSSLContext(SslEngineBuilder.java:142)
... 40 more
Caused by: java.nio.file.AccessDeniedException: /home/avaya/tcr/uc-ivr-nar-dev.dbplatform.portal.com.jks
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:96)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:114)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:119)
at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:226)
at java.nio.file.Files.newByteChannel(Files.java:372)
at java.nio.file.Files.newByteChannel(Files.java:418)
at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:395)
at java.nio.file.Files.newInputStream(Files.java:163)
at org.apache.kafka.common.security.ssl.SslEngineBuilder$SecurityStore.load(SslEngineBuilder.java:282)
... 41 more
Open JDK for some reason does not like JKS keystore files. Converted to PCKS12 format and it worked. Nothing to do with websphere container.
sorry for the delay.
to update to the question:
weblogic version is 12c. our installs are a bit different as we do not manually create a domain. we used a piece of software called maintenix that gets installed on top of the weblogic base install and it creates a domain the app runs under admin server
thank you
Hi everybody I am trying to decrypt the login and password for my WebLogic console
So I researched and seems this should work but i get the error below:
here are more details:
[webmstr#Ready4Use Oracle_Home]$ cd oracle_common/common/bin/
[webmstr#Ready4Use bin]$ ./wlst.sh
Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands
wls:/offline> domain = "/webapps/maint/maint35_install/domain/"
wls:/offline> service = weblogic.security.internal.SerializedSystemIni.getEncryptionService(domain)
wls:/offline> encryption = weblogic.security.internal.encryption.ClearOrEncryptedService(service)
wls:/offline> print encryption.decrypt("{AES}WDhZb5/IP95P4eM8jwYITiZs01kawSeliV59aFog1jE=")
Traceback (innermost last):
File "<console>", line 1, in ?
at weblogic.security.internal.encryption.JSafeEncryptionServiceImpl.decryptBytes(JSafeEncryptionServiceImpl.java:144)
at weblogic.security.internal.encryption.JSafeEncryptionServiceImpl.decryptString(JSafeEncryptionServiceImpl.java:192)
at weblogic.security.internal.encryption.ClearOrEncryptedService.decrypt(ClearOrEncryptedService.java:99)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
weblogic.security.internal.encryption.EncryptionServiceException: weblogic.security.internal.encryption.EncryptionServiceException: com.rsa.jsafe.JSAFE_PaddingException: Invalid padding.
I am suspecting some env item is not set properly but for the life of me I cannot see it (I did run setDomainEnv.sh before hand.
I have a problem when loading a client-side certificate using Jmeter. I tried everything including editing system.properties file, with these lines:
javax.net.ssl.keyStoreType=pkcs12 or jks
javax.net.ssl.keyStore=/path/to/your/jsk keystore or .p12 certificate
javax.net.ssl.keyStorePassword=your certificate or keystore password
Then importing certificate manually through SSL manager and manually typing password, nothing works.
I always have this error:
javax.net.ssl.SSLException: java.lang.IllegalArgumentException: No certificate found for alias:'mykey'
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.SSLSocketImpl.handleException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:404)
at .....
Alias is there, as print from certificate is showing:
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: mykey
Creation date: Sep 27, 2019
Entry type: trustedCertEntry
What could be causing Jmeter to fail reading the certificate? Has anyone done something like this before?
The approach with system.properties file works fine, just make sure to restart JMeter to pick the changes up.
Another option is passing the properties via -D command line arguments like:
jmeter -Djavax.net.ssl.keyStoreType=PKCS12 -Djavax.net.ssl.keyStore=your.keystore.p12 -Djavax.net.ssl.keyStorePassword=secret
Replace your.keystore.p12 and secret with the full or relative path to your .p12 keystore and the actual password accordingly.
More information:
Overriding Properties Via The Command Line
How to Set Your JMeter Load Test to Use Client Side Certificates
Suppose we need to trust a self-signed SSL certificate. As an example, let's use https://self-signed.badssl.com/.
Since the signer is not a "proper" authority, Java doesn't trust it and refuses to connect to that server. However, after
$ cd $JAVA_HOME/jre/lib/security
$ keytool -import -trustcacerts -alias ... -file ... -keystore cacerts
and restart of the application, the following code works:
new URL ("https://self-signed.badssl.com/").openConnection ().getResponseCode ()
and returns 200 (OK), without throwing an exception. I.e. basic Java way of opening an HTTPS connection now works, since the certificate is now trusted.
However, this doesn't have any visible effect on javax.ws.rs Client (as implemented in Resteasy, at least) and I still get an exception:
javax.ws.rs.ProcessingException: Unable to invoke request
at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:407)
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.method(ClientInvocationBuilder.java:273)
[...]
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1506)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:535)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:403)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:283)
... 90 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
at sun.security.validator.Validator.validate(Validator.java:260)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1488)
... 107 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:146)
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
... 113 more
It seems as Resteasy doesn't take "standard" keystore into account. But I would rather like to have a central (machine-specific) place for additional trusted keys and not bother how exactly application uses them, with URL.openConnection or javax.ws.rs.
Question
Is it possible to make javax.ws.rs Client use the same keystore as "normal" Java HTTPS connection mechanism?
Setting the SSL context when creating the Client instance
In the ClientBuilder API there's a method that allows you to set the SSLContext:
public abstract ClientBuilder sslContext(SSLContext sslContext)
Set the SSL context that will be used when creating secured transport connections to server endpoints from web targets created by the client instance that is using this SSL context. The SSL context is expected to have all the security infrastructure initialized, including the key and trust managers.
Setting a SSL context instance resets any key store or trust store values previously specified.
Parameters:
sslContext - secure socket protocol implementation which acts as a factory for secure socket factories or SSL engines. Must not be null.
Returns:
an updated client builder instance.
Throws:
NullPointerException - in case the sslContext parameter is null.
Assuming you have added the certificate to cacerts trust store, you could use the default SSLContext when creating your Client instance.
Client client = ClientBuilder.newBuilder().sslContext(SSLContext.getDefault()).build();
It should be enough. However, for some reason, the above piece of code does not work with RESTEasy, but does work with Jersey. It's very likely it's a RESTEasy bug.
The standard solution does not work with RESTEasy. What should I do?
The RESTEasy documentation states the following:
Network communication between the client and server is handled in RESTEasy, by default, by HttpClient (4.x) from the Apache HttpComponents project. [...]
RESTEasy and HttpClient make reasonable default decisions so that it is possible to use the client framework without ever referencing HttpClient, but for some applications it may be necessary to drill down into the HttpClient details. [...]
To customize the HttpClient used by RESTEeasy, do the following:
HttpClient httpClient = HttpClientBuilder.create()
.setSslcontext(SSLContext.getDefault())
.build();
ApacheHttpClient4Engine engine = new ApacheHttpClient4Engine(httpClient);
Client client = new ResteasyClientBuilder().httpEngine(engine).build();
Then you can perform the request:
Response response = client.target("https://self-signed.badssl.com/").request().get();
System.out.println(response.getStatus());
Are there any alternatives to the SSL context?
Instead of using the SSLContext when creating your Client, you could load a KeyStore. To load cacerts trust store, you can do the following:
String filename = System.getProperty("java.home") +
"/lib/security/cacerts".replace('/', File.separatorChar);
FileInputStream is = new FileInputStream(filename);
KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
String password = "changeit";
keystore.load(is, password.toCharArray());
The cacerts' default password is changeit.
Then create your Client instance using one of the following approaches:
Client client = ClientBuilder.newBuilder().trustStore(keystore).build();
Client client = ClientBuilder.newBuilder().keyStore(keystore, password).build();
The issue is that it doesn't work with RESTEasy, but does work with Jersey.
The solutions mentioned above were tested against the following JAX-RS Client API implementations:
jersey-client (version 2.23.1)
resteasy-client (version 3.0.18.Final)
Again, I have some problems with Solr. I'm trying to set up a SolrCloud cluster with three ZooKeeper instances and two Solr instances. Communication should be secured with SSL. I used the official Solr wiki as manual: https://cwiki.apache.org/confluence/display/solr/Enabling+SSL
When I start the first Solr node everything works fine. I can access the Web UI via HTTPS and communication between Solr and ZooKeeper also works. But when I start the second Solr node in my cluster I get the following exception:
Error while trying to recover. core=core1_shard2_replica2:java.util.concurrent.ExecutionException: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://ec2-xx-xx-xxx-xx.eu-central-1.compute.amazonaws.com:8983/solr
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at org.apache.solr.cloud.RecoveryStrategy.sendPrepRecoveryCmd(RecoveryStrategy.java:593)
at org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:350)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:221)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$22(ExecutorUtil.java:229)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://ec2-xx-xx-xxx-xx.eu-central-1.compute.amazonaws.com:8983/solr
at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:604)
at org.apache.solr.client.solrj.impl.HttpSolrClient.lambda$httpUriRequest$13(HttpSolrClient.java:299)
... 5 more
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:495)
... 6 more
Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:352)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:260)
at sun.security.validator.Validator.validate(Validator.java:260)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491)
... 24 more
Caused by: java.security.cert.CertPathValidatorException: signature check failed
at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135)
at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:219)
at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140)
at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79)
at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:347)
... 30 more
Caused by: java.security.SignatureException: Signature does not match.
at sun.security.x509.X509CertImpl.verify(X509CertImpl.java:424)
at sun.security.provider.certpath.BasicChecker.verifySignature(BasicChecker.java:166)
at sun.security.provider.certpath.BasicChecker.check(BasicChecker.java:147)
at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
So it seems that Solr does not accept the self-signed certificate. The option -Dsolr.ssl.checkPeerName=false as stated in the Solr Wiki has no effect (I put this parameter in the solr.in.sh script). I have to admit I'm pretty clueless right now :(
Does anyone have any idea what I could do to make the inter-Solr-node communication work?
BTW: I'm on Solr 6.1.0, and before I activated SSL everything worked like a charm.
Thanks a lot!
You can also add second node's certificate to the first node's keystore and also add first node's certificate to the second node's keystore via following command:
keytool -import -alias ca -file other_node_cert -keystore solr-ssl.keystore.jks
Then you can use self-signed certificate.
Looking at exception details it appears to be a handshake issue between java client code and the ssl enabled server. The JRE involved here probably doesn't trust the certificate. You can try to mark the cert as a trusted one (include in JRE truststore). Check JRE version specific documentation for steps to update truststore.