Import the cert from my unifi controller in the cacerts keystore
Try to make a connection using the rule provide by you: > FAILS
Disabled the part which I feared to cause all of this: > still FAILS
My stacktrace is the following:
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at org.eclipse.jetty.client.util.FutureResponseListener.getResult(FutureResponseListener.java:118)
at org.eclipse.jetty.client.util.FutureResponseListener.get(FutureResponseListener.java:101)
at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:684)
at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrlAndGetReponse(HttpUtil.java:250)
at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrl(HttpUtil.java:156)
at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrl(HttpUtil.java:131)
at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrl(HttpUtil.java:109)
at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrl(HttpUtil.java:90)
at org.eclipse.smarthome.model.script.actions.HTTP.sendHttpGetRequest(HTTP.java:57)
at org.eclipse.smarthome.model.script.actions.HTTP.sendHttpGetRequest(HTTP.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1521)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:528)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:802)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:681)
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:128)
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:73)
at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:133)
at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:155)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1709)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:318)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:970)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:967)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1459)
Caused by: java.security.cert.CertificateException: No subject alternative names present
at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:145)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:94)
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:436)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:252)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1626)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:970)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:967)
Edit: even if I configure the truststore and use the code from this fragment it reports an error:
Would it be possible to update things in such a manner that they follow the standards, maybe changes in the underlying Jetty made it such that you now get the warning, but reading more and more I think that it ever working is more likely to be wrong than it failing. Some search queries for more background: https://www.google.com/search?q=SSL+Cerficate+-+No+subject+alternative+names+present
Even with a certificate in your truststore the certificate should have a matching CN or subject alternative name.
Iām afraid I have to admit that I donāt fully understand it. I am a lawyer, not a computer scientist, and usually stick to step-by-step instructions ;D
I have understood that it is due to the certificate and that in my case the CN should not be called CN=Peter Bauer but CN=192.168.178.28.
What I didnāt understand is why the certificate is accepted when I retrieve it with the HTTP binding (String Judotoken "Token of the judo system" { http="<[https://192.168.178.28:8124/?group=register&command=login&msgnumber=1&name=login&user=xx&password=xx&role=customer:600000:JSONPATH($.token)]" } }
but not if Iām use.
var tokenjson = sendHttpGetRequest("https://192.168.178.28:8124?group=register&command=login&msgnumber=2&name=login&user=xx&password=xx&role=customer")
Both a using the same certificate.
Canāt I somehow force sendHttpGetRequest to accept the certificate? Just like here
Or is it perhaps because the SSL connection is established here via port 8124?
The problem is that I canāt change the certificate that is stored on my decalcifying machine, nor the port that is set here.
The main difference between the http binding and the rule action, is that first one uses the org.apache.commons.httpclient.HttpClient and the other uses the Jetty client org.eclipse.jetty.client.HttpClient, so itās likely that its somewhere in there.
Currently Iām a little bit feverish so I will go to bed very early, but Iāll try to look into later. I case I did not reply before the new year, feel free to remind me
If the rule still works with 2.4.0.M3 but doesnāt with 2.4.0.M4, the issue is most likely due to the upgrade to Jetty 9.4.11.v20180605 (which was part of the upgrade to Karaf 4.2.1 (#396)). See also 2.4.0.M4 changes.
If the rule still works in 2.4.0.M5 but doesnāt in 2.4.0.M6 it may be due to the ExtensibleTrustManager changes (#6281). See also 2.4.0.M6 changes.
Does it work for you @martinvw with 2.3.0 when you import the unifi controller in the cacerts keystore?
In the latest openHAB 2.5.0-SNAPSHOT Build (# 1482) Karaf got upgraded to 4.2.2 which uses Jetty 9.4.12.v20180830. Maybe one of the bugfixes also helps with this issue?
Happy new Year, i tried it with the openHAB 2.5.0-SNAPSHOT Build (# 1482) but getting still an error:
2019-01-01 11:34:19.391 [ERROR] [.smarthome.model.script.actions.HTTP] - Fatal transport error: java.util.concurrent.ExecutionException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
I think the most sensible approach would be to allow forcing to ignore certifcate errors, but that should/will never be the default because its unsafe. You could file an issue at https://github.com/openhab/openhab-core and if you manage to convince the people in charge in that repo I can try to make some time to implement it
But as you might have noticed my availability is not that high currently, sorry for keeping you hanging