I've put my foot in it again. Ever since I installed my C8 I've been plagued with https errors trying to connect to the hub. Every time I must bypass the error and use the connect anyhow button. I did a little research, two little, apparently, and found the semi hidden page to install a security certificate and key. So, I generated a self-signed certificate, pasted the certificate and key appropriately, turned on the SSL option (under the impression that this was required) and, now, I can't access the hub via a browser or the Android app.
No matter what the options on whatever browser, and I have tried many, it will not let me connect. Even if I have the force HTTPS option turned off in whatever browser, all of them these days switch to HTTPS only. If I type http://... Hub address ..., All the browsers change it to https and then fail to connect, with no option to override.
Having done my too little research, I simply tried http://10.10.10.200/hub/advanced/disablessl which, naturally, had no effect as I can't connect to the hub. As far as I can tell, that's a Catch 22. The C8 is still working, recycling power didn't help, and I'm about to unplug it and plug in my old C5.
Is it possible you're dealing with a different, easier problem? Like maybe your hub's IP address changed? See if http://findmyhub.hubitat.com helps. Alternatively, see if you can verify in your router's settings that the hub is connected at the IP address you expect.
This is a feature of most modern browsers where they'll try HTTPS if no HTTP response is found at the given address. Some might even aggressively try HTTPS first regardless of what you type, but for (at least?) local IP addresses, most I've seen respect your protocol if manually typed, so it's probably the former.
My router shows that the address is still as it was. I tried to access the diagnostic tool from my phone trying four different browsers, and each gave different errors. But I was able to connect from Edge under Windows, but I can't find an option that will solve this. Any ideas? Thanks!
Does the /hub/advanced/disablessl endpoint work under Edge then too, by chance? (Just wondering if the automatic HTTPS thing might actually be getting in the way with another browser.) My thought with the Diagnostic Tool was just to make sure something was actually at that IP address, which is good if you found it (I assume that screenshot is from your router, as it's not the Diagnostic Tool). I'm not aware of anything there that can help unless a soft reset happens to clear this, though I don't know that it does, and you'd still need a backup to restore, so I wouldn't recommend starting there.
Nope. The only thing I could get to was the diagnostic tool. If I tried to go directly to hub/advanced/disablessl, I got the same error as when I try to access the hub normally through a browser. The only thing I've been able to get to respond to is the diagnostic tool on any browser, and I couldn't get to the diagnostic tool from Firefox. I found that when all else fails, Edge is the go-to, as much as I dislike the interface. As for the soft reset, I think perhaps I will try that as I do have a good cloud backup. I'll just let it sit this way for a time before I do anything, especially as the hub is working normally at its primary function. I find myself wondering how others are dealing with this since experience with SSL is kind of rare and it remains an arcane subject. Is everyone with a C8 having to use the proceed at your own risk button do you think? Jeff
If you installed a self-signed cert, you need to also add the CA as a trusted cert on any machine needing access. This can get hairy.
The easiest option (though not cheapest) would be a publicly trusted cert.
One thing I noted is that once I flipped from using the IP to an internal DNS name for my hub, I stopped getting the prompt every time from Chrome. I couldn't explain why though.
Assuming the use of the SSL cert is a database variable, from the diagnostics menu it may be possible to restore to a point before you installed the cert.
I did install the CA certificate on my phone, to no avail as the behavior didn't change.
A few minutes ago it occurred to me I had a reasonable circumvention. I already subscribe to cloud backups, so I added remote administration. My credit card was posted, the subscription said that it was active and had been for so many minutes, but I find that I get 502 gateway errors if I try to actually go into remote admin. Oddly, if I hit the view hub details button and then hit the remote desktops link, I get my desktops and everything works, but I can't get to settings from there. I only get the 502 gateway error when I try to actually go into the remote administration dialogue. I think I'll just wait an hour or two and see if everything settles down. I did reboot using the diagnostic option on port 8081, but that didn't change anything. Jeff
What is the exact error being returned by the browser? I don’t see you mentioning what the browser is complaining about and that might help point to what the issue is.
I get several different errors, but the most common is "502 bad gateway." Sometimes, even immediately after logging in to my account at hubitat.com, I get "session timed out." There are others, such as error 500, but it's mostly 502.
Yes, I understand. And that is my plan if all else fails. Meanwhile, access via the cloud, at least as it pertains to the actual function of the hub, is working. In other words, the Google Assistant access works, Alexa works, and best of all, I can use the Hubitat Android app to access my dashboards.
And that's the real question, here. I can get to the hub through the cloud, but I can't use remote administration. I didn't think I needed remote administration as I'm partially disabled and rarely leave the house. My automations all involve lighting, so my temporary inability to write new rules or change options isn't affecting much.
In other words, why do some cloud access points work just fine and others not at all? And here's another thing: I am getting various errors at times even when trying to access remote administration generally.
So, the reason I'm pursuing this, even though I have a circumvention, is to figure out what is going on. Specifically, to figure out why I now need a self-signed certificate for the C8 but I didn't need one for the C5, and how to set up SSL on the hub so that my browsers and the Android app don't complain and force me to go through extra steps every time I want to access the hub. I used to be a computer professional, but I don't know all the ins and outs of SSL. Part of the reason I started researching the HTTPS problem with the C8 was to learn how to deal with certificates and keys. I remember, decades ago, reading about this scheme when it was new. I figured it out, I thought it was a clever and elegant solution to encryption and access, and that was enough for me at the time. Dealing with this in the HE milieu really should be easier, I think.
Well restoring to a couple of days ago will allow you to start from scratch to reimplement it. (BTW when you do that, download that current backup to your pc). This will allow you to diagnose your install by restoring to a clean slate when needed.
As to why it's working with the cloud access is it uses a different scheme than web to control your devices (think similar to maker API) and the remote server uses it's own certificates that don't apply to your hub.
That said, why do you think it's needed to have SSL on a local network as the device isn't exposed by any sort of port redirection (nor can it be due to the platform blocking that) that exposes it to the outside world? From the outside Hubitat's cloud servers handle that security.
Between the time you purchased the Remote Admin subscription and now, have you rebooted the HE hub? The hub needs to check in with the Hubitat Cloud to enable the subscription features, IIRC. Rebooting the hub basically forces this to happen.
I understand that access through the cloud isn't via HTTPS. I realized this shortly after my access was blocked yesterday when I discovered that I could access the C8's functionality via Google Assistant. And that is why I spent the 30 bucks to sign up for remote administration. As I say, I can get to my cloud dashboards via the hub and the link on the hub info page, and I can control individual devices via the lights button in the Android app. I really do understand how this works. What I don't understand is that since I can access the hub through the cloud, why am I getting various errors when attempting to use remote administration? This is a problem that others have faced and may face in future. I would like to solve all of these conundrums and Catch 22s for my future self and for others. Doing a soft reset and restoring a backup will circumvent my immediate problems, but won't solve these issues.
You asked me why SSL should be needed for LAN access. My answer is that it should not be needed. That's where this whole thing started. Every time I wanted to access the hub via either the Android app or any browser, I was told that the hub did not have a valid certificate and, after fussing about and scrolling down, I could access the hub only by clicking on the "are you really sure?" Button.
Yes, I have rebooted it several times. I've also shut it down via the stub on port 8081, unplugged. It, waited for all the capacitors to drain and the thing to really shut down hard, and plugged it back in. This does not help in the slightest as I'm getting exactly the same set of errors after all of these reboots.
I use firefox, and use http: instead of https in my shortcuts. That usually solves that. In the rare cases it doesn't, i simply turn off https redirect in the browser. It will still go to https (443 ssl) if it's available but if non ssl http is available and I specified that it will go to that first.
I wonder if this is the problem that is preventing the disablessl endpoint from working (I believe it only works over HTTP; certainly can't do HTTPS if's not working, in either case). Turning off this setting in your browser, using a different one that doesn't have this feature, or using en entirely different approach like a curl command from the command line would work around this issue — if that is indeed the problem.
