Home > Linux, Testing, Ubuntu > Installing Let’s Encrypt Free SSL/TLS Certificate in 2 Minutes with Certbot, Spending Hours Making it Work with Cloudflare

Installing Let’s Encrypt Free SSL/TLS Certificate in 2 Minutes with Certbot, Spending Hours Making it Work with Cloudflare

I’ve been using an SSL certificate to the download subdomain of this blog running ownCloud for about 2 years, but recently my free StartSSL certificate expired, and I had troubles to renew it, and I also received an email from Google telling me that “Starting October 2017, Chrome (version 62) will show a “NOT SECURE” warning when users enter text in a form on an HTTP page, and for all HTTP pages in Incognito mode”.  So I decide to use free LetsEncrypt SSL/TLS certificates to replace the one in the download subdomain, as well as this main blog. Such SSL/TLS certificates are also very useful for the IoT gateways many of use have started using, and I found it’s even simpler than install a self-signed certificate, so there’s no reason to use those anymore.

The easiest way to install Let’s Encrypt certificate is by using Certbot with instructions for various web server or hosting platforms (nginx, apache, pleask, haproxy…) and BSD & Linux based operating systems. I’m using Ubuntu 14.04 trusty with nginx, so the instructions below are for this combination, and it took me around 2 to 3 minutes in my VPS to have the SSL/TLS certificate installed, and up and running.

Cerbot installation:


Certificate installation for nginx on download.cnx-software.com subdomain:


Done! I could now go to https://download.cnx-software.com with my freshly installed certificate. That’s it for the 2-minute installation procedure, but as with such quick and easy procedure, you can always add “wasting countless hours” steps to it, and that’s what I did, by first checking out the Qualys SSL Report as recommended in the output of the terminal above.

Grade C, not good. The certificate is mostly there to protect my login credentials, as I don’t have any important private data in that server, but let’s still try to improve this. The most critical issue is that the server is vulnerable to the POODLE attack, but luckily Nginx guys have a fix: disable SSLv3.

I just had to change a single line in the server block of the domain configuration file in /etc/nginx/sites-enabled directory to only allow for TLS connections:


I then reload the configuration with:


Ran the SSL report again, and I improved to Grade B. That was easy.

After Disabling SSLv3

The second problem is about “weak Diffle Hellman (DH) key exchange parameters”, but again there are solutions.

First I had to create a dhparams.pen files with the following command line:


then edit the domain configuration file in /etc/nginx/sites-enabled/ directory by adding the following in the server block:


After reloading nginx configuration, I had a grade A with no other problems to solve.

I checked two banking websites, and they got A-, two online shops (GearBest and GeekBuying), and they achieved Grade B, so when you share your credit card info, you are at risk, albeit likely a limited risk. Considering it’s so easy to fix some of the issues, they should do it, and I informed both companies.

Let’s Encrypt certificates expires just after 90 day, so you may want to setup automatic renewal. First check renewal works with a dry run:


If there are no errors, you can setup a cron or systemd job to run the following command regularly:


I then tried with some other domains, and I got a TLS handshake failure:


The reason was Cloudflare intercepting traffic, so I had to pause Cloudflare before running certbot, and installation went just fine, and I could use my website without any problem, until I resumed Cloudflare support, and got “too many redirects”. I started to look for solutions with come fairly complicated instructions for Certbot + Apache + Cloudflare. After a few hours trying to find a solution, I discovered my assumption that if I enable an SSL certificate on my side, I should just disable SSL in Cloudflare… Big mistake! After setting Cloudflare SSL to Full (Strict) it worked again, although I eventually just to set it to Full because Let’s Encrypt wildcard SSL certificate are not yet supported, but will be in January 2018.

So the TLS connection was working, but I tried a dry run to renew the certificate, and every domain managed through Cloudflare would fail… That’s when the “complicated instructions” above came handy… So I first installed Certbot Cloudflare plugin/add-on:


Created /etc/letscrypt/cloudflare.ini file with your email, and API key in Cloudflare (Global API Key)


and generated new certificates using that plugin:


This should overwrite the two files used for the certificates previously created with nginx option: /etc/letsencrypt/live/www.domain.com/fullchain.pem
& /etc/letsencrypt/live/www.domain.com/privkey.pem.  So normally, you don’t even need to change your nginx configuration after that, but if for some reasons the path has changed, you should edit your file in /etc/nginx/sites-enabled/ and updated the paths.

Finally, I tried the dry run to update the certificate and it worked, so I created a cron job to renew the certificates every month:


If your website is also designed to be compatible with https, then your job is done, if not, then you’ll have some work to do to remove all hardcoded http calls from your websites with the help of the developer console in web browsers such as Chrome or Firefox.

  1. Sander
    August 22nd, 2017 at 12:04 | #1

    Well done!

    A very nice tool to verify your TLS / HTTPS setup in detail: testssl. See https://github.com/drwetter/testssl.sh

  2. Sander
    August 22nd, 2017 at 12:12 | #2

    PS: one step beyond is disabling TLS1; it was defined in 1999, and it is considered unsafe by certain people. So I made my own mini-website TLS1.2-only. That works, although very old clients can’t connect anymore, for example IE8 on XP and Win7 … which is OK for me. 🙂

  3. MrShark
    August 22nd, 2017 at 13:11 | #3

    Can the same certificate be used for same address but different ports? Example apache on 80, nodered on 1880, webmin on 10000,etc
    Thanks

  4. Marcin Juszkiewicz
    August 22nd, 2017 at 14:31 | #4

    You can go to A+ even ;D

  5. August 22nd, 2017 at 14:58 | #5

    @Sander
    Thanks for your help testing it by the way.
    I’ve just checked.. in the last 7 days, I still had 53 visitors with IE 8.0, 23 with IE 7.0 and 1 with IE 6.0.
    So TLS v1 will stay for now 🙂

    I could also see TLS v1.3 is coming soon, but does not seem widely deployed yet (Cloudflare has it, but only in Beta for example).

  6. August 22nd, 2017 at 15:06 | #6

    @MrShark
    Yes, based on the following discussion: https://community.letsencrypt.org/t/letsencrypt-doesnt-work-for-different-ports/17519/
    Make sure you read more than just the first answer.

  7. Sandbender
    August 22nd, 2017 at 18:03 | #7

    Nice writeup @cnxsoft. For those who don’t have a similar setup, the Mozilla wiki has an excellent guide for securing HTTPS as best as possible on different platforms (and for different clients):
    https://wiki.mozilla.org/Security/Server_Side_TLS
    They also have a very useful tool which will auto-generate a secure config based on os, web server and target clients.
    https://mozilla.github.io/server-side-tls/ssl-config-generator/

  8. Sandbender
    August 22nd, 2017 at 18:07 | #8

    @MrShark
    Yes, a certificate is tied to the servers CN – Common Name (hostname), ports don’t factor into it. If you’re hosting multiple hostnames on the same server, you can use Server Name Identification (SNI). This will let you host them all on 443 and the server will figure out which certificate to respond with. Some very old browsers don’t support it but they’ll also have busted SSL/TLS implementations and users should really upgrade anyway.

  9. Peter Steenbergen
    August 22nd, 2017 at 19:15 | #9

    I just read this for my cloudkey the other day!

    https://www.naschenweng.info/2017/01/06/securing-ubiquiti-unifi-cloud-key-encrypt-automatic-dns-01-challenge/

    Might be usefull as alternative for CertBot

  10. blu
    August 23rd, 2017 at 07:04 | #10

    So that was the source of all the 503’s I was getting on one of my browsers while trying to access cnx over the past days.. I had started suspecting the sanity of that one browser : )

  11. avra
    August 23rd, 2017 at 15:24 | #11

    I can no longer access your site from WinXP and last Chrome based Opera that supports it. It works on firefox. Any help for Opera?

    “This site can’t provide a secure connection
    http://www.cnx-software.com uses an unsupported protocol.
    The client and server don’t support a common SSL protocol version or cipher suite. This is likely to be caused when the server needs RC4, which is no longer considered secure.”

  12. Tirguy
    August 23rd, 2017 at 16:11 | #12

    An other tool for Firefox : https://github.com/sibiantony/ssleuth/

  13. August 23rd, 2017 at 16:21 | #13

    @avra
    Based on the SSL report, if you use Windows XP with SP3 update:
    Works – Chrome 49, Firefox 49
    Does not work – IE 6.0, IE 8.0

    I don’t have data for Opera, but make sure you have Opera 36 since it’s the latest version that works with Windows XP.
    It was released in March 2016, it should still work.

  14. August 23rd, 2017 at 16:23 | #14

    It looks like for older browsers support in Cloudflare, you need a paid plan to handle SSL properly: https://support.cloudflare.com/hc/en-us/articles/203041594-What-browsers-work-with-CloudFlare-s-SSL-certificates-

  15. August 23rd, 2017 at 16:43 | #15

    @avra
    If not done already, you may want to check http://forums.opera.com/discussion/1883427/this-site-cant-provide-a-secure-connection/p1
    One guy had the same issue with Opera 36, and disabled a program called “net nanny”.

  1. No trackbacks yet.