Install of VestaCP and SSL for itself
Posted: Sat Apr 28, 2018 9:10 pm
I've been puzzled by the fact that the VestaCP installer doesn't setup a Let's Encrypt SSL for its own control panel it installs. Especially since the current installation process, and resulting self-signed certificate, is a very bad security practice.
The self-signed certificate requires users to ignore security warnings (invalid certificate). People already too readily ignore security warnings. Making it a 'normal' part of the install process is bad. If there were a man in the middle attack at some point, people might ignore the certificate warning presented to their browser (because it is normal) and none the wiser provide their username and password to the attacker.
The work-around, which it seems shouldn't be necessary, is to either a) add that self-signed certificate as trusted on the client machine/browser. Or, b) manually change the VestaCP port to 80, enable SSL, and change it back.
Neither of these solutions are very good, and 'a' is awful because it means that certificate has to be added as trusted by every user for every device from which they are accessing VestaCP. Blech!
The reason 'b' is necessary is that Let's Encrypt (LE) challenge/response process used by LE requires the server to respond to a challenge on port 80. Since VestaCP is listening on port 8083, the challenge fails. It is necessary to manually edit configuration to have VestaCP temporarily listen on port 80 to successfully enable Let's Encrypt via VestaCP UI or CLI.
It seems ridiculous to require a manual step as the last part of the installation so the installation is usable and secure.
The installer *should* temporarily setup a vhost on port 80 for the host domain, to serve only the LE challenge page. After successful LE certificate install for the domain, then the installer needs to configure its use for port 8083.
If that were done, the VestaCP URL presented upon successful installation would actually work without a security warning! And save many the tedious process of creating a real certificate for their VestaCP domain.
The self-signed certificate requires users to ignore security warnings (invalid certificate). People already too readily ignore security warnings. Making it a 'normal' part of the install process is bad. If there were a man in the middle attack at some point, people might ignore the certificate warning presented to their browser (because it is normal) and none the wiser provide their username and password to the attacker.
The work-around, which it seems shouldn't be necessary, is to either a) add that self-signed certificate as trusted on the client machine/browser. Or, b) manually change the VestaCP port to 80, enable SSL, and change it back.
Neither of these solutions are very good, and 'a' is awful because it means that certificate has to be added as trusted by every user for every device from which they are accessing VestaCP. Blech!
The reason 'b' is necessary is that Let's Encrypt (LE) challenge/response process used by LE requires the server to respond to a challenge on port 80. Since VestaCP is listening on port 8083, the challenge fails. It is necessary to manually edit configuration to have VestaCP temporarily listen on port 80 to successfully enable Let's Encrypt via VestaCP UI or CLI.
It seems ridiculous to require a manual step as the last part of the installation so the installation is usable and secure.
The installer *should* temporarily setup a vhost on port 80 for the host domain, to serve only the LE challenge page. After successful LE certificate install for the domain, then the installer needs to configure its use for port 8083.
If that were done, the VestaCP URL presented upon successful installation would actually work without a security warning! And save many the tedious process of creating a real certificate for their VestaCP domain.