Icloud binding - General SSLEngine problem

Same issue here

same here….

And me…

Did you tried this?

Hello. I just went through those Openhabian Steps. Sadly, they did not fix the issue.
Anything else one could try?

Same here, running binding 2.4 - tried to apply new certificates already last week - following this:
https://community.openhab.org/t/icloud-binding-general-sslengine-problem/48314/27

no improvement, visible in log files.
One difference to the issue from last year is that after applying the new certs, both:

pi@openhab : ~/testscripts $ java SSLPoke fmipmobile.icloud.com 443
Successfully connected
pi@openhab : ~/testscripts $ java SSLPoke www.icloud.com 443
Successfully connected
pi@openhab : ~/testscripts $

are working fine now.

from logs:

2019-08-05 07:36:45.146 [WARN ] [l.handler.ICloudAccountBridgeHandler] - Unable to refresh device data
java.io.IOException: java.util.concurrent.ExecutionException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrlAndGetReponse(HttpUtil.java:259) ~[?:?]
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.HttpRequestBuilder.getContentAsString(HttpRequestBuilder.java:135) ~[?:?]
at org.openhab.binding.icloud.internal.ICloudConnection.callApi(ICloudConnection.java:84) ~[?:?]
at org.openhab.binding.icloud.internal.ICloudConnection.requestDeviceStatusJSON(ICloudConnection.java:65) ~[?:?]
at org.openhab.binding.icloud.internal.handler.ICloudAccountBridgeHandler.lambda$0(ICloudAccountBridgeHandler.java:84) ~[?:?]
at org.eclipse.smarthome.core.cache.ExpiringCache.refreshValue(ExpiringCache.java:97) ~[?:?]
at org.eclipse.smarthome.core.cache.ExpiringCache.getValue(ExpiringCache.java:68) ~[?:?]
at org.openhab.binding.icloud.internal.handler.ICloudAccountBridgeHandler.refreshData(ICloudAccountBridgeHandler.java:141) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.util.concurrent.ExecutionException: 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) ~[?:?]
… 16 more
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) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:291) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:151) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) ~[?:?]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) ~[?:?]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680) ~[?:?]
… 1 more
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) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:775) ~[?:?]
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) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:291) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:151) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) ~[?:?]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) ~[?:?]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680) ~[?:?]
… 1 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:397) ~[?:?]
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302) ~[?:?]
at sun.security.validator.Validator.validate(Validator.java:262) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136) ~[?:?]
at org.eclipse.smarthome.io.net.http.internal.ExtensibleTrustManager.checkServerTrusted(ExtensibleTrustManager.java:120) ~[?:?]
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) ~[?:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1459) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:775) ~[?:?]
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) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:291) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:151) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) ~[?:?]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) ~[?:?]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680) ~[?:?]
… 1 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:141) ~[?:?]
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126) ~[?:?]
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280) ~[?:?]
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392) ~[?:?]
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302) ~[?:?]
at sun.security.validator.Validator.validate(Validator.java:262) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136) ~[?:?]
at org.eclipse.smarthome.io.net.http.internal.ExtensibleTrustManager.checkServerTrusted(ExtensibleTrustManager.java:120) ~[?:?]
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) ~[?:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1459) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:775) ~[?:?]
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) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:291) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:151) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) ~[?:?]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) ~[?:?]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680) ~[?:?]
… 1 more

not really an expert on certificate handling and all, but I did spot an obvious difference between www.icloud.com and fmipmobile.icloud.com.

openssl s_client -connect www.icloud.com:443 -servername www.icloud.com -showcerts
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA
verify return:1
depth=0 businessCategory = Private Organization, jurisdictionC = US, jurisdictionST = California, serialNumber = C0806592, C = US, ST = California, L = Cupertino, O = Apple Inc., OU = Internet Services for Akamai, CN = www.icloud.com
verify return:1
Certificate chain
0 s:/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=California/serialNumber=C0806592/C=US/ST=California/L=Cupertino/O=Apple Inc./OU=Internet Services for Akamai/CN=www.icloud.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA

openssl s_client -connect fmipmobile.icloud.com:443 -servername fmipmobile.icloud.com -showcerts
CONNECTED(00000003)
depth=1 CN = Apple Server Authentication CA, OU = Certification Authority, O = Apple Inc., C = US
verify error:num=20:unable to get local issuer certificate
Certificate chain
0 s:/CN=fmipmobile.icloud.com/O=Apple Inc./ST=California/C=US
i:/CN=Apple Server Authentication CA/OU=Certification Authority/O=Apple Inc./C=US

It seems that TLSv1.2 handshake is failing - maybe due to an issue in certificate chain?

I have the same issue :frowning:

Me too :disappointed_relieved:

Me Too.

Regards Markus

Additional observation:

pi@openhab : ~ $ echo -n | openssl s_client -host fmipmobile.icloud.com -port 443 -prexit -showcerts
CONNECTED(00000003)
depth=1 CN = Apple Corporate Server CA 1, OU = Certification Authority, O = Apple Inc., C = US
verify error:num=2:unable to get issuer certificate
issuer= CN = Apple Corporate Root CA, OU = Certification Authority, O = Apple Inc., C = US
Certificate chain
0 s:/CN=api-edge.icloud.com/OU=management:idms.group.788838/O=Apple Inc./ST=California/C=US
i:/CN=Apple Corporate Server CA 1/OU=Certification Authority/O=Apple Inc./C=US

is failing, while:

pi@openhab : ~ $ echo -n | openssl s_client -servername fmipmobile.icloud.com -host fmipmobile.icloud.com -port 443 -prexit -showcerts
CONNECTED(00000003)
depth=2 C = US, O = Apple Inc., OU = Apple Certification Authority, CN = Apple Root CA
verify return:1
depth=1 CN = Apple Server Authentication CA, OU = Certification Authority, O = Apple Inc., C = US
verify return:1
depth=0 CN = fmipmobile.icloud.com, O = Apple Inc., ST = California, C = US
verify return:1
Certificate chain
0 s:/CN=fmipmobile.icloud.com/O=Apple Inc./ST=California/C=US
i:/CN=Apple Server Authentication CA/OU=Certification Authority/O=Apple Inc./C=US

I managed to get openssl s_client working after installing Apple Root CA on my raspberry.

Unfortunately no improvement when iCloud binding is trying to connect…
TLSv1.2 handshake is still failing.

@martinvw, @patrik_gfeller - is iCloud binding using a different pem/crt to establish SSL connection? Different to both the java keystore and installed ca-certificates (“dpkg-reconfigure ca-certificate”)
If so please update binding accordingly and release a fix (on 2.4 as well).

I tryed this solutions:

Option 1:

echo -n | openssl s_client -servername fmipmobile.icloud.com -host fmipmobile.icloud.com -port 443 -prexit -showcerts 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/icloud2.crt

cd /tmp

csplit -f cert /tmp/icloud2.crt '/^-----BEGIN CERTIFICATE-----/' {*}

sudo su

cd /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/

bin/keytool -delete -alias icloudfmi1 -trustcacerts -keystore ./jre/lib/security/cacerts -storepass changeit

bin/keytool -delete -alias icloudfmi2 -trustcacerts -keystore ./jre/lib/security/cacerts -storepass changeit

bin/keytool -importcert -file /tmp/cert01 -alias icloudfmi1 -trustcacerts -keystore ./jre/lib/security/cacerts -storepass changeit

bin/keytool -importcert -file /tmp/cert02 -alias icloudfmi2 -trustcacerts -keystore ./jre/lib/security/cacerts -storepass changeit

systemctl stop openhab2

reboot

Option 2:

echo -n | openssl s_client -connect fmipmobile.icloud.com:443 -prexit 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/icloud2.crt

sudo keytool -delete -alias icloudfmi -keystore /var/lib/openhab2/etc/keystore -storepass openhab

sudo keytool -importcert -file /tmp/icloud2.crt -alias icloudfmi -keystore /var/lib/openhab2/etc/keystore -storepass openhab

sudo reboot

but not work for me.

Any option works fine for you? Any idea???

Thanxs!!

Hi!

I’tried the same command procedure as you did but also without any success.

There is another thread with a potential repair for Icloud. I have not implemented the fix but I am grateful for the folks that can figure this stuff out! Thank you Maury Q!

here is the link:

Have a great day!

Mike

Look here: Back to Online

This is a quick and dirty solution for windows (perhaps another systems too)

It worked perfectly for me on linux. Congratulations and thanks.

After running this command - I get following message:

CONNECTED(00000003)
depth=1 CN = Apple Server Authentication CA, OU = Certification Authority, O = Apple Inc., C = US
verify error:num=20:unable to get local issuer certificate

how can I fix the

verify error:num=20:unable to get local issuer certificate

This seems to be the problem why icloud binding is not connecting in my case
Thanks for any hint
Georg

Any solutions now ?

Hi Dominik,

for openHAB 2.4 you could try the following:

with kind regards,
Patrik

2 Likes

May not be the right place to post this, but I received the inspiration for the solution that worked for me was on this thread, so I’m posting it here.

Using the 3.1.0 iCloud Binding, the account Thing was constantly initializing. There was nothing more in the log.

On my Pi 4B running openHABian, I stopped openHAB (systemctl stop openhab), cleared the cache (sudo openhab-cli clean-cache) and restarted openHAB (systemctl start openhab). After that, the account Thing went Online and after a few minutes, the device Things were online and their channels providing current data.