After installing the panel on a clean Ubuntu 18.04 (hetzner), I can’t access the panel either by IP address or by domain.
Chrome Error: ERR_SSL_SERVER_CERT_BAD_FORMAT
Chrome does not offer any alternatives to open the site.
(I dont see any errors in hestia or nginx logs)
I do not know if it is a correct fix, but it works:
v-add-letsencrypt-domain admin srv.freedome.pro
make a link of generated certificates (.key & .crt) to /usr/local/hestia/ssl/
systemctl restart hestia
Now it can be open
Just run v-add-letsencrypt-host, it will generate you the cert for hestia backend.
This error have also to be fixed. While default Hestia installation where is no way to open Hestia web interface in morden browsers getting ERR_SSL_SERVER_CERT_BAD_FORMAT error.
Every time I install Hestia, I can not login at all and get this error:
[email protected]:/usr/local/hestia/bin# v-add-letsencrypt-host
Error: Let's Encrypt validation status 400. Details:
Error: Let's Encrypt SSL creation failed
The provided solution does not help either.
Is it possible by default to allow access to the panel even with a missing certificate?
Looks like yuo’ve got a validation issue for your ssl certificate with an 400 error code - mostly ipv6 records on the hostname, wrong dns setup or connection issue (probaly firewall), there are already a few threads handling this:
Yes, all this happens when you install a new server from scratch.
I know how to fix this error. Perhaps the first time you install the panel, it is better to allow http access if https is not configured properly or disable HTTP Strict Transport Security.
I believe it is NOT a good idea to allow unencrypted (non-https) admin access to the server, as this will be a serious security issue.
HSTS is also disabled by default. The user needs to enable that, if they want to. At least this has been the case in all the servers I’ve installed until now.
I have installed quite a few servers, but never had this error with SSL.
I’d recommend you check for any strange aliases on the web domain that fails SSL validation.
It will be only enabled automatically for the server hostname (using v-add-letsencrypt-host), otherwise you’re completly right with your post.
I always have this error on many hosts and providers (DO, Hetzner, Vilur and many others) that makes it completely impossible to access Hestia Panel from the first time. To get this error is very simple: create new instance, install Hestia.
P.s. I use ubuntu 18.04, nginx+php-fpm.
This is the problem. Since Chrome 80 there is no way to open urls with self signed certificates getting Subj error. See here:
Yes, I can with error NET::ERR_CERT_AUTHORITY_INVALID. But this error still allow to open url, Subj error is not. I think it depends on nginx ssl configuration.
OK. Here is your video:
Here is the link: https://220.127.116.11:8083/
Fresh install on DO. No commands except Hestia install script. Let me know when I can destroy DO droplet.
bash hst-install.sh -a no -n yes -w yes -o no -v yes -j no -k no -m yes -g no -x yes -z yes -c no -t yes -i yes -b no -q no -d no -f no -y yes -s no -l no -r 8083
Result: Not possible to login Panel, ERR_SSL_SERVER_CERT_BAD_FORMAT
Seems to be a client side issue, no problem here with opening the site (chrome mobile):
That strange. I can access from mobile too. Then the only reason may be NOD32 Antivirus, that block self signed certificate. I do not have any other special software installed.
For OSX Chrome I have the issue as the TS
Your connection is not private
Attackers might be trying to steal your information from
(for example, passwords, messages or credit cards). Learn more test.example.com
Maybe a version difference…
But I can open this link:
Microsoft Edge gives this error on Hestia Panel, also not possible to login:
Right solution is to attach domain name with correct DNS records and run v-add-letsencrypt-host. But still I do not know, why for so long time I am not possible to login Panel right after installation. Thanks everyone for the attention.
Also working here properly, Chrome v81.0.4044.129 on WIndows 10 x64:
So this is a local issue without any relation to hestia.
always the best option.