Hi,
wanted to reconfigure my InfluxDB-server to httpS (what worked fine with my certs), but recognised that OH can’t connect anymore. YES, I changed the influxdb-url, but I couldn’t find any params (http://docs.openhab.org/addons/persistence/influxdb/readme.html) that would allow me to specify the .CRT and .KEY files.
Has someone of you any tips?
Thank you very much in advance & BR!
OH does not appear to support connecting to InfluxDB over https if you are using self-signed certs.
Well, that’s bad :(… but many thanks anyway for your reply, @rlkoshak!
Do you think that’s a reasonable design?
I do think it would be reasonable to add support for HTTPS to the InfluxDB. I’m sure it is just not something a developer wanted or needed enough to contribute in a PR yet. If you are willing the community would welcome the addition.
And I’m not 100% certain that https by itself isn’t supported. Remote access to my system is messed up right now so I can’t check (I somehow messed up my ssh certs to my OH machine). There just isn’t a way to supply your own self-signed certs and if the cert is not issued by a CA already trusted the connection may not go through.
There are other approaches you can take to make the connection more secure. You can configure the firewalls so that only connections from OH and presumably the Grafana server are accepted. If they are on the same host so much the easier and only allow connections from localhost using the firewall. If you are using Docker or one of the other container based management systems you can set them up so only those clients that their networks only connect to each other and are not exposed.
Hi @rlkoshak, thanks for your reply. Unfortunately I don’t have the logs anymore, but if I remember correct it was an JAVA exception that looked like this (just google-d it up, thinking that was the exact log-entry);
Exception in thread “main” 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
Honestly, I didn’t have the time yet to analyse this issue properly, so I restored a VM snapshot. In fact, there’s a (HW) firewall in my network, but I’d prefer to go with the SSL approach.
At this point (talking about security) - is there any approach to secure OH’s front-end by a user/pass combination (preferably Basic UI / Paper UI). I’m utilizing an NGINX reverse proxy, but before adding .htaccess restrictions I wanted to know if there’s something that’s user/role based (and though manage-able via an admin UI).
Enjoy your day!
If that was indeed the exception then yes, the problem is OH can’t handle self-signed certs. It might work if you imported your self-created CA into the Java keystore.
https://blogs.oracle.com/jtc/installing-trusted-certificates-into-a-java-keystore
Essential problem is marking certificate as trusted. If you would have certificate which is provided from one of well known authorities there would be no issue.
This is because each vendor who is recognised is marked as trusted. You can add your own certificates to trust store as well. Sadly this is necessary for connection which ends up with self signed cert.
Keystore which is referenced in most of cases is meant to launch java component with given cert or sign things with such certificate (public key encryption and so on). What you need to look for is “import certificate into java truststore”.
Once your own certificate ends in jvm trust store you will be able to connect to all services which use it for encrypting communication.
hi there, gave it again a try with oh3 and influxdb2.0.
no success.
i’ve configured influxdb2.0 to work with ssl - works.
next, i’ve changed my telegraf configs to use ssl instead - everything fine, influxdb2.0 receiving data.
next, i’ve set up a new keystore for the active jvm (zulu-11) and imported both the (self-signed) ca.cert and the (self-signed) influxdb.crt into it.
next, i’ve additionally imported the (self-signed) ca.cert to the already existing “cacerts” keystore (just in case).
next, i’ve set EXTRA_JAVA_OPTS for openhab to use the new keystore.
with that, it seems that openhab “accepts” the ssl connection to influxdb, but doesn’t write any data. instead, there’s a log-entry…;
The exception occurs during check instance readiness
com.influxdb.exceptions.BadRequestException: null
…but that’s not the case, because telegraf writes successfully to it.
additionally - and here comes the funny part; some of my rules don’t work anymore;
Script execution of rule with UID 'abc' failed: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target in xyz
the thing is that this rule is just watching for an item to change (if a door is opened, to be precise - so there’s no ip / https-service behind, etc.).
my question is if there’s really no option to skip tls verification for self-signed certificates?
thanks in advance!
Hi,
has there been any update on this?
I’m running InfluxDB in a Kubernetes cluster which uses it’s own certmanager to generate certificates for ssl services. None of the cluster services are exposed without SSL…
I added the CA certificate in the OH3 docker image under /etc/ssl/certs and ran update-ca-certificates --fresh.
Running curl https://influxdb.server works fine in the docker shell after a restart of the container, but unfortunately, OH3 or at least the influxdb addon doesn’t seem to recognize the system truststore…
As OH3 is primarily target at the self-hosting community, I wonder if there aren’t others who have experienced the same issues with the influx or maybe other addons. Or are others running these services without SSL at home?
I’d be happy, if I could help, but I guess, as with many other users, I’m probably not the best to contribute 
Any suggestion/help would be very much appreciated, as I would love to persist into influxdb and use the data on my global grafana dashboards.
Happy Habbing! 
John…
I had the same problem that I was not able to connect to InfluxDB with self-signed TLS certs (all my internal used TLS certs are signed by my own Certificate Authority).
I solved the problem by importing my CA into the Java keystore:
# go to the lib/security directory of your JVM, example for openHABian (with Zulu):
cd /opt/jdk/zulu11.48.21-ca-jdk11.0.11-linux_aarch32hf/lib/security
# add the certificate to the JAVA keystore
sudo keytool -importcert -file <path-to-certfile> -cacerts -keypass changeit -storepass changeit -alias <alias-for-cert>
@JohnSinclair Please tell me if that works for, it might be possible that your JVM‘s keystore is in another path if you use another JVM.
Hi,
sorry for the late response.
It was a bit tricky, to get this running in the container.
Adding the certificate to the truststore with keytool is not enough / does not work, as OH will only recognize the change after a restart.
Unfortunately, the truststore for adoptium is updated during the container start…
This behaviour can be changed in /etc/default/adoptium-ca-certificates, but I decided to add my ca certificate to /etc/ssl/certs/ AND append it to /etc/ssl/certs/ca-certificates.crt. I’m not sure anymore, which did the trick, but this way the ca cert get’s imported during the update of the cacerts truststore.
The only downside with this approach is that it needs to be done after each update (which aren’t too often for OH, I must admit) or if the container get’s recreated.
For my Kubernetes setup I needed to pin the container to a specific node, to avoid it being moved around, which would lead to the recreation and thus breaking my setup.
I would love to see some sort of configuration option for the startup of OH3 to include a ca cert that is present in the userdata folder.
Hope this helps.
Hmm okay, I was not aware of the behaviour in Docker.
This is different on openHABian / generally with openHAB installed on a Linux system.
We could try out, if we’d like to know. Anyway, seems like the the Adoptium Truststore is updates from those.
I am not sure what if this is possible, depends on openHAB core.
If it’s not possible, it would also be a solution to add an option to the Docker Container to include own (CA) certificates.
In the mean time, you can put a script in a folder mounted to /etc/cont-init.d inside the container. Any script found there will be executed prior to the start of openHAB inside the container. You could create a script to add the cert that way.
That’s a great idea!
I didn’t know about that.
I’ll give it a try, when I touch my setup next for the update to 3.4.0
Great @florian-h05 ! That worked for me. I had a similar problem after enforcing https on my grafana server using a pfsense self signed certificate. Importing my CA into the Java Keystore made things work again. (I’m using grafana to render images for some sitemaps)
Thank you!
one thing to mention here - if you upgrade zulu JVM, it might happen that its keystore gets overwritten. in that case you’d need to re-import your selfsigned certs again.
after that, i always reboot the VM.
I‘ve created a PR to add the how-to self-signed certificates with InfluxDB/openHAB to the addon docs, see [influxdb] Add docs for usage of self-signed certs by florian-h05 · Pull Request #14228 · openhab/openhab-addons · GitHub.