sorry for the delay, here is how I go about it…
I only use debian, so my starting point would be a regular vesta-install which includes apache on stretch, I didn’t check with jessie yet, but there shouldn’t be any differences though.
first step, I’m using the main hostname/domain which should be already existant in the admin account.
(you probably can adapt all steps to another (sub)domain or even another account)
however lets call this domain my.host.name - of course that domain needs to be connected to your server properly 
-
log into vesta and activate ssl for that domain and let letsencrypt create the cert.
-
change to /home/admin/conf/web and open/create a file called sapache2.my.host.name.conf
-
put in the following content:
SSLProxyEngine On
ProxyPass /.well-known !
ProxyPass /webmail !
ProxyPass /roundcube !
ProxyPass /phpmyadmin !
ProxyPass / https://my.host.name:8083/
ProxyPassReverse / https://my.host.name:8083/
<Location /api>
Authtype Basic
AuthName "restricted"
AuthUserFile /home/admin/conf/web/.htpasswd
Require valid-user
</Location>
-
save file and create .htpasswd with user and password to your likings
htpasswd -c .htpasswd <user>
-
make sure mods proxy and proxy_http are enabled for apache
a2enmod proxy proxy_http
-
restart apache
service apache2 restart
if everything went well you now should be able to access vesta directly via https://my.host.name without port number and also see a nice green padlock 
-
inside vesta go to the firewall-settings and change the IP for the Vesta port to 127.0.0.1 which should cut off external access to that port (verify!)
-
check api access&restriction via https://my.host.name/api - you should be greeted with a basic auth prompt and after putting your credentials get to a blank page without any errors.
that’s it for the proxy-thing, as there are no changes to any vesta-files this config should survive vesta updates easily.
if you want to block potential offenders early you can now use the blocked port 8083 as trap with this rules:
iptables -I INPUT -m recent --name vestablock --reap --update --seconds 36000 -j DROP
iptables -I INPUT -i ens18 -p tcp --dport 8083 -m recent --name vestablock --set -j LOG
careful! read first: what does this do?
the second rule listens on the ethernet interface (!!change ens18 accordingly!!), port 8083 and if there is any packet incoming it adds the IP to an internal recent-list named vestablock and logs it (default /var/log/messages, adjust to your needs).
because of the default DROP for the INPUT chain, the packet then will be dropped. also there simply is no service listening on 8083 anyway (see above)
now for the first rule, all requests coming from an IP that’s been put on that recent list will also be DROPed regardless of the port! entries are pruned only after 10 hours (adjustable) as long as they haven’t hit the first rule again, which instead would reset that counter.
again please be CAREFUL with iptables, you can easily block yourself out of your server with this, so try to understand how this works and have a fallback ready from were you can login via SSH to remove the rules if mistyped or wrong or you need to reboot.
to make the rules permanent, get some admin-basics
on a sidenote: apart from that I use elmo’s GitHub - ifaist0s/vesta-server-ssl-cert: A Linux shell script for VESTA Control Panel to assign and update SSL certificate to all services (vesta, exim, etc). script to copy the letsencrypt cert automatically over to vesta itself, so this and the mail-service have a valid one when using the hosts domain
as usual without warranties, use at your own risk and adopt to your likings. feel free to ask questions or point out mistakes.
Unfortunately, updating VestaCP does indeed overwrite this fix.