General SSLEngine problem
{:cognitect.anomalies/category :cognitect.anomalies/fault,
:cognitect.anomalies/message “General SSLEngine problem”,
:cognitect.http-client/throwable #error {
:cause “No name matching localhost found”
:via
[{:type javax.net.ssl.SSLHandshakeException
:message “General SSLEngine problem”
So looks like the SSL handshake between client and peer-server failed due to host name localhost
I assume the Jetty server used by peer-server defines a ssl conext factory, but I could not figure out how it is initialized. Most importantly, how I can pass a keystore setting to it. I tried to add -Djavax.net.ssl.keyStore=.. java options to peer-server command line, but seems they were ignored. I see from peer-server log the Jetty server was started with null keystore/trustStore.
2019-07-07 18:17:59.308 INFO default o.e.jetty.util.ssl.SslContextFactory - x509=X509@402d6012(transactor,h=,w=) for SslContextFactory@395281c2[provider=null,keyStore=null,trustStore=null]
2019-07-07 18:17:59.318 INFO default o.e.jetty.server.AbstractConnector - Started ServerConnector@1573e8a5{SSL,[ssl, http/1.1]}{localhost:8998}
2019-07-07 18:17:59.318 INFO default org.eclipse.jetty.server.Server - Started @6356ms
So the question is how I can bypass this issue? Can i run peer-sever without SSL? can I specify a keystore config to Jetty?
You may need to check your docker configurations to ensure that the correct ports/network routes are configured for communication between the client and peer-server containers.
Hi there! Any update on what might be causing this? We ran into the same problem even after adding :validate-hostnames false to the connection map and it doesn’t seem to be a docker configuration issue.
I’d like to report I’m now seeing this error. I tested against datomic 0.9.5930 et 0.9.5981. There is no docker involved in my datomic setup at this point.
I believe it used to work, at least in July 2019, with version 0.9.5930. I do not know what changed in my setup since then (I suppose that’s an argument for Docker in that context …).
As far as I can tell adding :validate-hostnames false to my client map (as the linked documentation above suggests) or my connection map (as marshall suggests) doesn’t have any effect. The :validate-hostnames keyword doesn’t appear in the documentation found within the datomic.client.api namespace, located at ~/.m2/repository/com/datomic/client-api/0.8.35/client-api-0.8.35.jar!/datomic/client/api.clj on my system.
I managed to connect to localhost using :validate-hostnames false after upgrading com.datomic/client-pro to the latest 0.9.41, that I found out about using some maven browser.