For those of you using cPanel and WHM as a system, you’ll be as glad as I am to hear about the latest release of AutoSSL which enables SSL certificates to be set up across accounts much easier than ever before. In summary, it’s possible to generate and install SSL certificates for individual cPanel accounts all via the WHM interface which is super useful when managing web servers with multiple accounts and domains hosted. All of which is powered by Let’s Encrypt which traditionally would have required quite a bit of command line set up via SSH.
To get this up and running is actually relatively straight forward.
Set up Let’s Encrypt for AutoSSL via SSH
This is the only part that you need to do via SSH and it is only required once. Simply login to SSH and run the following command;
/scripts/install_lets_encrypt_autossl_provider
Let everything install and configure, all automatically.
Configure AutoSSL in WHM to Use Let’s Encrypt
Navigate to the following page within WHM, Home > SSL/TSL > Manage AutoSSL. Now update the settings to use Let’s Encrypt instead of any other providers that you may have installed as can be seen below.
Once this is set up, when you use the AutoSSL feature Let’s Encrypt will be the certificate authority which manages this.
Run AutoSSL for cPanel Accounts
Now everything is set up to run AutoSSL, it’s time to start running it. While you can simply run this for all domains, it is recommended to take a more structured approach so you can be sure that you are updating everything correctly. Particularly when migrating WordPress websites from HTTP to HTTPS, there are a lot of additional tweaks to make to ensure everything works correctly.
To run AutoSSL on a specific cPanel account, simply click on the “Check” button next to the account you want to run this for. This will run AutoSSL for all Addon Domains associated within this cPanel account. There are a few restrictions currently for what will work here, so be sure to check the official cPanel documentation.
SSH Now Setup
Now access the HTTPS version of your website and everything should be set up and working. As mentioned previously, there will likely be other items to clean up to ensure the green padlock shows in your browser bar. From an AutoSSL standpoint, everything is complete. Simple.
Check within the individual cPanel account you have just updated and you should see that the certificate has been installed on the domains that are listed. This is super useful and saves a lot of time manually generating and implementing SSL certificates.
Caveats
If this doesn’t work for some reason then check the error logs for AutoSSL within WHM. This will provide you a lot of information about what has gone wrong. Particularly if you are using cloud based CDNs or firewalls such as Sucuri, then you’ll need to disable this to get AutoSSL working correctly. Be sure to check your .htaccess files too as sometimes you may have restrictions in here which only allows traffic to the website from the cloud based CDNs or firewalls such as Sucuri.
As with everything, make sure you know what you are doing before playing around with these types of things and make sure you fully understand your technical stack and setup. Just because this works for us, does not mean that this will be as seamless for you. Get in touch should you have any support requirements for getting this set up on your websites and web servers.
Michael Cropper
Michael,
> Particularly if you are using cloud based CDNs or firewalls such as Sucuri, then you’ll need to disable this to get AutoSSL working correctly. Be sure to check your .htaccess files too as sometimes you may have restrictions in here which only allows traffic to the website from the cloud based CDNs or firewalls such as Sucuri.
After doing the above, did the AutoSSL cert work properly when you re-enabled Sucuri and added the Sucuri whitelisted IPs back to .htaccess? If so, did you have to repeat this process (disabling Sucuri and the whitelisted IPs in .htaccess, then re-enabling) each time the AutoSSL cert renewed? Thanks.
Hi Don,
Yes it did. Decided to not re-enable Sucuri as it was causing too many problems. I seem to remember that Sucuri now do have their own SSL certificates for free (I think) within their paid plans, so worth taking a look at those if you’re using Sucuri. For the time I was using this, it was more effort to integrate all this than it was worth, so shelved the idea of getting the two integrated until a later date. This was before Sucuri announced their free SSL certificates. As with most early tech adoptions, if something doesn’t quite work, if you leave it a few months, there is generally a patch or some new tech available to solve the problems 🙂 In this case, Sucuri announced their free SSL certificates which is likely the best approach to take, https://blog.sucuri.net/2016/04/sucuri-firewall-free-letsencrypt-ssl-certs-for-everyone.html – I’ve not personally tested this so not sure how easy / challenging this is to set up. If you do have a go with this approach, leave another comment as I’m sure others would also be interested to hear how easy this was to do.
Regards,
Michael
It’s simple to set up the SSL cert at Sucuri. When you add a site to their Cloudproxy firewall, you get a Let’s Encrypt SSL cert by default. There’s nothing to enter. That gives you http://www.domain and domain.com.
However, the issue I’m having is that on the *origin* server side for the same domain with AutoSSL turned on… Eg. AutoSSL on the origin server issues a cert for autodiscover. , cpanel. , mail. , webdisk. , and webmail. But, if you need/want any of those subdomains loading under SSL, AND you have the site behind the Sucuri WAF, then AutoSSL cert does not work for autodiscover. , cpanel. , mail. , webdisk. , and webmail because the domain cannot be validated by AutoSSL if it’s not pointing to the origin server. I’m trying to figure out a way to at least get webmail. secured.
I see. This rings a bell with what I was experiencing. Sucuri requries a licence per sub-domain, which has always seemed a bit overkill to me, hence why the sub-domains you mentioned aren’t working correctly. See here, https://sucuri.net/faq/, which states;
“A license is required for every subdomain (this.site.com) and unique website structure.”
When you get rid of Sucuri, everything works. Hence why we ended up doing this as we use sub-domains quite a lot on various projects.
Something to consider if you’re still using webmail on the server, it may be worth considering migrating to an external hosted mail service for security and usability reasons if they are being used for business purposes, https://www.contradodigital.com/resources/really-simple-guide-business-email-addresses/
So in essence, it looks like you’ll have to buy another Sucuri licence, or, possibly, you may be able to point sub-domains like https://mail.website.com to your server IP at the DNS level, while pointing https://www.website.com to Sucuri’s IP. Depends on the level of configuration options you have over your DNS. Sometimes this is possible, sometimes not depending on various packages you are on with your suppliers.
Hope that helps 🙂
Regards,
Michael
Hi Michael,
I have a question for you that’s along the same line as some of the others here.
You said that Sucuri was giving you problems due to their firewall when it can to installing and renewing the free SSL Certificate by the hosting provider.
I use Sucuri and have run into this same issue. The hosting provider says I’m not even eligible for the free SSL Certificate because my domain is pointing to Sucuri’s firewall. And, when the SSL Certificate renews every 90 days, the domain must be pointed away from Sucuri’s firewall and to the hosting provider’s server in order for the SSL Certificate to properly renew.
So, reading your comment, it sounds like you disabled Sucuri’s firewall entirely to install and renew your SSL Certificate. That makes sense, but, when you did that, what would you use to protect your website?
Because it sounds like I have two options:
1) Use Sucuri’s SSL Certificate, but it will be a partial SSL (from just the Sucuri firewall to the browser) and not a full SSL (from browser to firewall and from firewall to browser). It provides some protection/encryption but not FULL protection/encryption.
2) Or, I can do what you did–just remove the Sucuri firewall entirely, keep my domains pointed to the hosting providers servers, and just…live with it like this.
My only concern here is that, well, my site is far more vulnerable because there’s no firewall.
So, just curious if you had any thoughts or recommendations, since you seem to have run into this issue a little bit yourself.
Thanks for your time.
-Brian
Hi Brian,
That is all correct what you say.
Re. #1: Agreed, partial encryption there. So traffic between Sucuri and your web server is technically not encrypted and could fall foul of a Man-in-the-Middle attack. This is better than no SSL at all, but partial encryption is not something that I’d recommend. Something that may be worth trying, it’s not something I have a play with but it just popped into my head, you could try installing a self-signed SSL certificate on the web server, https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux – Self-signed SSL certificates generally aren’t accepted by web browsers, so I would have thought that adding a self-signed SSL certificate on the web server that is used between the web server and the DNS level at Sucuri, the web browser would ‘see’ the Sucuri SSL certificate and not the self-signed SSL certificate.
Re. #2: That’s what I did. I wouldn’t particularly say that a website is far more vulnerable because it isn’t using a cloud based firewall. There are many levels of security, particularly on a WordPress stack that can be implemented to boost security. For example, physical firewall within your web host’s data center, server level firewall and technologies such as iptables, fail2ban, web server control panel brute force attack prevention software, port blocking technologies, various security plugins at the WordPress level – and above all, managing user rights correctly to ensure only people who really need Admin access on the various systems actually have Admin access. One of the core benefits in my opinion to cloud based firewalls such as Sucuri is the automated system to block Distributed Denial of Service (DDoS) attacks based on the enormous data set from all of their customers. So when not using a service like this, it’s essential to monitor the performance of the server and do as much as possible to protect yourself against these kinds of attacks.
What I would say either way though is that there is no 100% perfect solution when it comes to security. When you’ve got the right hosting solution in place, you generally have the flexibility to do what you need to do to protect yourself adequately at the web server level without the need for a cloud based firewall. If you’re running an enterprise system, cloud based firewalls are essential though.
If you do have a go at using the self-signed SSL on the web server, I’d be interested to hear if you got this working, keep in touch.
Regards,
Michael