I’ve been trying to migrate from VestaCP to HestiaCP all day today. I’ve created a few droplets at this point to start over as I figured things out. The one thing I am still stuck on is getting access to the main control panel via Chrome.
Attackers might be trying to steal your information from srv01.mydomain.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_INVALID
ReloadHide advanced
srv01.mydomain.com normally uses encryption to protect your information. When Google Chrome tried to connect to srv01.mydomain.com this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be srv01.mydomain.com, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.
You cannot visit srv01.mydomain.com right now because the website sent scrambled credentials that Google Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later.
In the past, I could just bypass this, but it seems Chrome no longer gives me the option. So the only solution I found was to use Safari. I was able to hit a button to bypass this warning and proceed to the site, which is when I am prompted with HestiaCP login and I can gain access. So this is great, I was able to then confirm that my imports from my VestaCP tar backups were able to successfully import. In fact, those websites work just fine with their imported Let’s Encrypt files. But I still continue to get the issue with the IPAddress:8083 page not working.
It’s very bizarre, the issue I’m having. And btw, just for others that find this post, there is a very stupid and silly way to get around this in Chrome. Basically, Chrome’s latest releases, removed the old WARNING, click this link to proceed link. But, if you click anywhere in the page (i.e. basically bring focus to the page), and then type in your keyboard “thisisunsafe”, without the quotes, the page will magically refresh and proceed.
I didn’t believe it when I saw it on another website, when the person said that’s how you get around it, but yeah, it works.
okay, back to the issue. So, what’s weird is that the let’s encrypt certificate is properly loading if I just go to the website URL of my new hestiaCP server. It loads the “We’re working on it” page. And if I check the certificate, it’s signed by R3 and Lets Encrypt. So it’s working from that perspective.
But when I try to connect to the same URL but with port 8083, it then tells me the certificate is not trusted and gives the message I put in my first post. When I check the certificate, it says its signed by HestiaCP control panel and that it’s invalid. Why is it serving up two different certificates for the same domain under the admin user. I don’t get this.
And now it’s loading properly. But why did this even give me an issue. The hostname was already set when I created the digitalOcean droplet. When I ran the installer script, it also showed me that same hostname and I hit enter to use the default (which displayed my hostname). I used the same hostname in that v-change-sys-hostname command.
In the control panel itself, under the admin user, it already had that same hostname. So I don’t understand why I would have had to do this anyway.
I have to be brutally honest. I love the new interface and I’m hoping this platform has a long and successful future unlike VestaCP (i was originally on Sentora prior to that, and this is now the 3rd migration I have had to do, because they were abandoned). But I have to say, this was the most painful experience to install and set this up. I’m no server expert, but i have been managing my server for more than 15 years and prior to using Sentora I would build the LAMP stack from scratch and configure it.
And just moving from VestaCP to HestaCP consumed my entire day with all the research and trying to figure out what wasn’t working and how to get it working. You can definitely tell this platform is created by server admins for server admins. VestaCP was probably the easiest install I ever did. Even if I am not trying to migrate stuff from VestaCP, getting this server up and running with a fresh install of Ubuntu, was still challenging.
For the rest don’t know what to tell you, since Hestia at it’s core is basically a fork from Vesta, the steps for preparing a new server are almost if not completely identical.
As for the panel (port 8083) ssl certificate I’m pretty sure it doesn’t get installed automatically in Vesta either, although it is something we have discussed internally to improve.
Btw, just to mention, I did edit the web domain under the admin user, where the domain for the HestiaCP main control panel hostname sits. I checked the box to enable SSL and I also checked the box to use the Let’s Encrypt SSL.
That’s why I assumed by doing that and saving the Edit Web Domain page, would have generated the SSL and overwritten whatever had been established on the server. But this did not seem to have any effect.
It was only when I issued those two commands you pointed me to, which then changed the SSL cert on that domain. I would have assumed enabling the SSL in the Hestia CP interface should have resolved the issue without requiring the terminal command.
Should it have? If so, then there appears to be something broken there. Either way, I documented this extra step so that I have it in my notes for when I need to rebuild or create a new server in the future. Thanks!
no it shouldn’t. so far there is no automatic setting for the host certificate away from the self-signed to any other domain or the hostname.
the issue here is that you MUST HAVE that hostname or domain properly connected/dns configured to be able to aquite an LE certificate during install. if that fails or someone just wants to go by IP or a local domain via hosts entry etc. the install could eventually fail or at least need another decision on what to do next and might even leave you with a broken panel.
I haven’t installed Vesta in a long time, but as far as I remember you did not even any script to choose and copy one of the ssl certs over to the host itself at all but also needed to work your way around it. (but my memories could be wrong here as well)
just want to say that maybe you also manually adjusted things for your Vesta install from time to time but now do not recall completely anymore through which hoops you might have jumped there during all the times you used it
you honestly would be very welcome to have a look at the documentation and help making a better so other starters could have less bumps on their way in… it is on github as well, so working on it means just fork it and submit oull requests for your changes and additions. We be happy to have more people helping there.
Hi Falzo! Thanks for the detailed response. Would love to help this project. Once I get everything up and running and operational I would be happy to dive into some of the documentation to improve for others.
It’s one area I like to be very detailed about, so that others dont have to deal with the same headaches already experienced by others.
