sendHttpGetRequest not working under OH 2.4 M7 after Update from 2.3

Okay what I tried now is:

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.

The most interesting is that it works with the scripts from Atlassian

But fails using other code like ā€¦.

Unless you have an idea why it used to work I cannot help you any further.

Maybe a binding which you had in your 2.3 instance did override some global https configurations like the ones shown in https://stackoverflow.com/questions/19540289/how-to-fix-the-java-security-cert-certificateexception-no-subject-alternative

Edit: this for example fixes it:

HttpsURLConnection.setDefaultHostnameVerifier((hostname, sslSession) -> true);

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.

I think that this is not part of the problem.

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 :slight_smile:

To help with finding what may have caused this:

  • 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?

Its not working with M3, also not M1 and M2. Its not working anymore since the change from 2.3 to 2.4.M1

Thatā€™s very odd indeed. But I wouldnā€™t test with M1 and M2 because of hiccups:

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

Hi,
hope you get well again. Did you have another opportunity to think about the problem?

@martinvw Iā€™m getting the same error when im calling that:

val String rawString = sendHttpPutRequest( "https://www.lebensmittelwarnung.de/bvl-lmw-de/opensaga/feed/alle/baden_wuerttemberg.rss" )

1 Like

That is interesting, the url looks fine without any SSL errors, are you sure your JDK is recent?

Also it looks suspicious that you do a PUT? a sendHttpGetRequest looks more sensible to me.

1 Like

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 :slight_smile:

But as you might have noticed my availability is not that high currently, sorry for keeping you hanging

  1. Youā€™re right. I did some try and error to find out if I can change the error and forgot to rename the call from put to get.
  2. Itā€™s working now (from 14 oā€™clock today). Maybe they changed anything on their site.

For me this is solved.