Cloudflare Cache and SSL
Last updated: May 11th 2020
Free SSL (https) certificates with Let's Encrypt
Webdock offers full Let's Encrypt support on all our stacks, and we enable and force HTTPS on your server as soon as it is created. This page details some of the caveats you might run into while working with Let's Encrypt and Certbot.
Cloudflare Caching and Certbot
Cloudflare caching is great for all sorts of things, but it has the side-effect that when a user hits a URL on your site, they are effectively communicating directly with Cloudflare servers, and not your Webdock server.
We have chosen to configure Certbot in such a way that it will issue a certificate using the webroot method. This essentially means that you can leave Cloudflare cache turned on for the domain you are generating certificates for, but this then requires you do not change the default web root from /var/www/html manually - if you use the Update Web Root functionality in Webdock, you will be fine.
You need to make sure all relevant DNS records have caching enabled.
You should make sure that you have configured SSL certificates properly in Cloudflare under Crypto, i.e. they should be set to Full. Otherwise you may run into issues with infinite redirects.You should also allow enough time to elapse for Cloudflare to generate their own SSL certificate, as what happens is essentially that Cloudflare secures the connection from Cloudflare to the client, while your Certbot certificate secures the connection from Cloudflare to your Webdock server.
Webdock workflow and Certbot Issues
Certbot is an automated tool which interacts with your webserver vhost configuration and tries to authenticate your server before issuing certificates. This is a complicated workflow, which may result in a variety of errors:
- Certbot can have a tough time verifying your domain if it is proxied through Cloudflare, that's why we use the Webroot method
- The webroot method can fail if for some reason your server denies access to /.well-known/ due to BasicAuth, Redirects or misconfiguration
- Certbot gets easily confused by more complex vhost configuration, especially if you want it to try and write redirects to your vhost config which has existing redirect directives.
That's why we have chosen to - untill we find better solutions - to issue a Rollback command to Certbot before executing the Certbot workflow. In this fashion we are sure that the vhost config is clean and is in a state where Certbot can complete without errors usually.
So, when you execute Certbot through the Webdock web interface, this is what happens:
- We back up your current vhost configuration to /tmp - look for filenames starting with backup_vhost_webdock
- We issue a Certbot Rollback command. This gives us a clean, default vhost config (as it was when your server was first provisioned)
- We set your server hostnames as defined in Server Identity
- We now run Certbot with the webroot auth method
If you have customized your vhost configuration to any extent we recommend that you run Certbot manually so that you can be hands-on in solving any issues which may crop up. We are actively working with the Certbot community in optimizing Certbot in order to solve these issues.