I have dozens of domains added to my server, all with Let's encrypt certificates.

Sometimes, I face an issue when I can't add a certificate for a new domain because one of the old ones has got its IP address misconfigured.

Error reporting for these cases, as it is now, is not very descriptive, so I am forced to manually copy-paste all my domains (up to 100 of them) into a DNS lookup tool.

The current error message in such cases look like this:
Server 4: Please make sure that your domains are pointed correctly to your server IP

Desired look
Server 4: Please make sure that your domains are pointed correctly to your server IP. Domain go.example.com is not pointed to your server IP.

If you have a .htaccess in the root of your application, that adds a htpasswd based auth password for the entire site, the Let's Encrypt autorenewal process fails. The process create a subdirectory, .well-known/ and uses it for the renewal process, deleting it at the end of the process.

There are two easy ways to get around this that I can think of:

1. do not delete the .well-known directory at the end of the process. so that us customers can add in the .htaccess file in there if we want to, to leave it readable



2. 
   

   as a part of the process of creating the short-lived .well-known directory, add a .htaccess file in that folder with the content:

   Satisfy Any
   Order Allow,Deny
   Allow from all

   
   

And delete it all at the end of the process, as it does now. This will unlock that directory during the process automatically

In the advanced settings for nginx there is an option to set a WAF. This is needed fo nginx to grab the right headers in order to get the actual visitor's IP address.

Using a WAF one would certainly also want a WAF bypass prevention. For this SUCURI suggests adding the following lines to the nginx vhost:

location / {
allow 192.88.134.0/23;
allow 185.93.228.0/22;
allow 2a02:fe80::/29;
allow 66.248.200.0/22;
allow 208.109.0.0/22;
deny all;
....
}

There should be an option to do that when chosing sucuri as a WAF.

Also, if you contact support to add those rules for you (which they thankfully did), the WAF configuration box will be blank. DO NOT CHOSE SUCURI AGAIN as this will mess with the allow rules. I am not sure why. But if you set it to sucuri WAF again, the page will result in a 403 for all requests made by sucuri.

Also, for this to be a complete package, a meaningful WAF bypass should also prevent SSL information leakage. I created another suggestion for that (https://cloudways.uservoice.com/forums/203824-service-improvement/suggestions/42272272-stop-server-from-leaking-ssl-information)

If the application is served through a WAF, you don't want anyone to bypass the WAF by accessing the server using its IP address.

Cloudways gives us the option to disable access to the application using the IP address only (apache Access Application via IP). However, the web server is still responding to SSL requests, thus leaking the certificate information that would include the common name.

The SSL certificate should only be presented to the WAF/requests using the hostname/URL and not by accessing the IP address.

It seems that cloudways is using nginx as a reverse proxy in front of apache. Nginx ≥ 1.19.4 has an option to reject ssl handshakes (sslrejecthandshake). This could be used to stop infomation leakage.

Please offer an option to properly shield origin servers behind a WAF.