Issue of the topic: I configured a Nginx reverse proxy following the documentation (Securing Communication and Access | openHAB) and all seems to work as expected but the ip-camera snapshot urls.
but only when accessing OH from within the local network (url = 192.168.0.53:8080)
When accessing OH from an external address, using the domain configured in the Nginx reverse proxy (home.mydomain.it) the page is loaded but the url of the camera image is wrong: it is mapped by Nginx from http to https, (the request is GET https://192.168.0.53:8080/ipcamera/C1-Lite-02/ipcamera.jpg) and this generates a SSL_ERROR_RX_RECORD_TOO_LONG error
Hi First Welcome to the community!
There are a couple things going on here based on what you show that are likely problematic.
One being you are attempting to route a private IP (192.168.x.x is private ip range) via Public (internet)
Your browser is attempting to connect to your IP cameras private IP address and it will not resolve that
Meaning when you set up your OH-card and give it the url for your ip camera that is being presented to your browser as a new URL endpoint to connect to. obviously the internet can not resolve your private IP
Second your browser is trying to connect to a secure location the https://192.168.0.53 and there is no digital certificate being presented from the ip cameras “internal web server” to negotiate the TLS handshake
thus even if your did resolve it would fail on negotiating a valid cypher to use since no cert or TLS protocol from your IP camera is being offered.
Also you are using the default secondary http port 8080 and attempting to pass encrypted traffic on it
As a FYI the secondary default HTTPS port is 8443.
The error you show
Is likely caused by you attempting to serve insecure content as secure The browser is unable to complete the TLS handshake for the 192.168.0.53 end point. therefore Firefox presents this error
without seeing your nginx.conf file you could try adding an additional proxy_pass statement under your
location /
proxy_pass http://192.168.0.53:8080/
it may help. But very unlikely outside of your internal local network. This is because your external (front of proxy “internet side” incoming traffic will not be able to resolve the private IP and you may also have port conflicts if you are using 8080 for both openHAB and your camera end point.
If that does not work and you cannot alter the port then you might need to set up a new server block in your nginx.conf and configure it to handle reverse proxying your camera URL but that will require a cert for it as well and all the same domain and DNS setup you did for your original FQDN unless your FQDN supports subdomains and you have a wild card cert securing the site.
As a final thought have you considered using the openHAB cloud connector instead of nginx reverse proxy solution?
It can help simplify your setup and does not require you to punch holes (open ports) in your routers network firewall.
I hope my explanation is helpful and clear as to what you kind of issues are dealing with.
Hi Sebastian, Hi justaoldman
First of all, many thanks to you for your help.
My post wasn’t clear enough and I would like to clarify it adding some detail.
I am a OH beginner, so I followed the configuration instructions with no or few modifications
I decided to secure my OH site setting up a Nginx reverse proxy, following the OH site instructions here
The resulting Nginx configuration file is almost identical to the example shown in the OH configuration guide here
Following the justaoldman suggestion, I changed the proxy_pass directive from
proxy_pass http://localhost:8080/;
to
proxy_pass https://localhost:8443/;
and this didn’t change the reverse proxy behaviour, and it seems to work fine.
I agree with the justaoldman’s considerations and warnings about mixing secure and insecure content. The problem is that the offending URL is not under my control. It is generated by the IpCamera Binding and I don’t know how to change the binding behaviour. I hope the following details will help:
I created the ipcamera:foscam:C1-Lite-02 Thing, configuring it with all data required by the binding.
The Foscam C1 Lite camera is connected to my local network at 192.168.0.77:88 address
I linked the ImageURL Channel of the camera Thing to a new Item (Foscam_C1Lite_Snapshot_URL) and in the Item setting page the following URL is generated by the binding and I do not have any control on it: http://192.168.0.53:8080/ipcamera/C1-Lite-02/ipcamera.jpg, note that the binding generates a URL accessing OH vith HTTP on port 8080.
If I call this URL in the browser it shows a snapshot from the camera, the transferred file is ipcamera.jpg and is internally generated by the binding.
In my overview page I created a simple Image Card widget pointing to the Item Foscam_C1Lite_Snapshot_URL. If I do not specify the Item in the widget, using directly the URL generated by the binding, the result is identical
I can access the overview page in three modes:
https://home.my_domain.it/overview : the page is loaded correctly but the request for GET https://192.168.0.53:8080/ipcamera/C1-Lite-02/ipcamera.jpg generates the error I showed in my post. And I agree with justaoldman, the cause is that plain, not SSL encoded data, are sent as reply to a https request
https://rasp5:8443/overview : (rasp5 is the hostname of the OH server) same result, the page is loaded but the identical GET jpg request generates the same error
http://rasp5:8080/overview : it works perfectly. All the page loading request are now http GET and also the snapshot image is loaded correctly
I hope the problem is more clear now. I have no idea how to solve it. It looks more like a IpCamera Binding problem than a Nginx configuration error.
Hi @lucabur
I am not so sure this is a “bug” but more of a undocumented configuration option.
The channel that provides the snapshot URL is populated with a complete and valid URL. It is of course a private internal IP to allow you to use a browser on your internal network to view your image file.
Obviously if you only put
into the browser it would not give you an image.
The configuration that @Baschtlwaschtl offered allows your image card to look at the openHAB internal web folder where that stored file the binding is generating is being saved. It is kind of like if you had static files in the conf html folder.
or any other webservers folder that are embedded as part of a page.
The ipcamera binding offers multiple ways to configure and even using ffmpeg to create your own snapshot images from a live stream.
The binding is very flexible and offers many different ways to do the same solution.
Your specific configuration of setting in behind a reverse proxy is not utilized as much as using the free OpenHAB cloud connector that provides ability to present your OpenHAB on the internet without opening ports on your home fire wall and is also provides a secured ACL solution.
as well as not having to any of expose any part your internal network and all the additional considerations that brings.
But glad you have it working how you want it to.
Again, welcome to the community and hope you enjoy openHAB as much as all the other folks do.
Spend some time reviewing all the documentation you will find the options for openHAB are pretty much limitless.
Best Regards
Hi @justaoldman,
Many thanks again for your help. My knowledge of OH is very poor at the moment, and there are definitely many aspects I need to explore. As for the “bug” or lack of documentation, if you prefer, I think:
Both the Reverse Proxy and OH Cloud Connector are described in the OH Installation Guide as valid methods to protect your site, each of them with pros and cons, I suppose.
The Image Card widget “item” parameter can be used to link the widget to the Item providing the image to show, the IP Camera snapshot Item in this case.
This works perfectly, and the widget shows the image as expected, but only if you are accessing your OH site locally or if you choosed the Cloud Connector to protect your site when accessing from internet. This sounds a little bit strange IMHO.
If your choice was the Reverse Proxy, linking the widget to the Item simply doesnt’ work, and you have to leave the field blank, filling the URL field instead, but with a modified version of the Binding generated URL, as suggested by @sebastian .
May be that calling this a “bug” is not correct, but I think that the Binding should provide a way to configure the way the URL is generated, a configuration parameter to generate internal or external URLs
Moreover, I have not enough experience in OH, not yet, but I think that this could be a more general problem, not restricted to the Image Card widget and the Camera Binding: every time a URL is generated as a pointer to a Item, we could get the same problem.
Again thank you, I appreciate the help and your explanations about OH architecture.
Have a good day.
