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 SSL/TLS, 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. 

For further troubleshooting information from Cloudflare take a look here, and here

For Troubleshooting information on specific Certbot errors, take a look at our Common Certbot Errors & Solutions page

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:

1. We back up your current vhost configuration to /var/backups/backup_vhost_webdock - look for directories containing the current date
2. We issue a Certbot Rollback command. This gives us a clean, default vhost config (as it was when your server was first provisioned)
3. We set your server hostnames as defined in Server Identity
4. 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.

Common Certbot Errors & Solutions

We have created a dedicated page which list most if not all issues you may run into when running Certbot and what exactly you can do to resolve the issue. 

Please take a look at our Common Certbot Errors & Solutions page for more information.