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”.

  16. avra
    August 23rd, 2017 at 19:24 | #16

    cnxsoft :

    Does not work û IE 6.0, IE 8.0

    Opera and Maxthon also don’t work.

    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.

    I do have Opera 36.0.2130.65, the last available.

    Maxthon (webkit based) is the last browser still receiving updates on WinXP. Unfortunately even after today’s updates it does not differ much:
    “Invalid certificate
    This site’s certificate has expired or has been issued for a different website’s address.
    This problem may indicate an attempt to intercept the data between you and a remote server.
    Please check whether the URL in the address bar is correct.
    Error code 113 (net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH)”

    I do not have “net nanny”.

    🙁

  17. August 23rd, 2017 at 19:37 | #17

    @avra
    Supporting older browsers / OS? would require me to either disable Cloudflare, or pay $20 per month for the Pro plan.
    Do you have any specific reasons to still use Windows XP?
    If you do, why not using Firefox or Chrome browsers?
    I’m pretty sure I’m not the only website to use Cloudflare SSL (free), so you must frequently have this kind of issues.

  18. JotaMG
    August 23rd, 2017 at 21:26 | #18

    This is SOoo STUPID !!

    ” for example IE8 on XP and Win7 … which is OK for me ”
    ” Do you have any specific reasons to still use Windows XP? ”

    Well, it maybe ok for you, but what about those millions of people in Africa and other poor regions that have to use the garbage (old computers) we – so called civilized world – dispose to them???
    Grow up !

  19. avra
    August 24th, 2017 at 16:05 | #19

    @cnxsoft
    I fully understand your position, but that means that I will check your blog much less frequent. I do not think that company will upgrade WinXP machines any time soon. With other browsers I have bigger problems on more important sites, so Opera is my choice. Your site is the only one which has Opera (and Maxthon) problems. There are possibly others but they didn’t show yet. It would be nice if you could be able to alternatively allow access without SSL.

  20. JotaMG
    August 24th, 2017 at 18:08 | #20

    I wonder if this all madness is nothing more than a push from the main industry players for people to buy new devices.

    I can understand that gmail, a bank, a business or a government website have the strongest encryption available, but does a news website or even a blog website really needs that?
    Will the information be more honest and truthful with that security?
    And, who will have the motivation and the computational power to spare on messing with a blog, even if it uses weak security?

    This is funny, some of the most visited websites in this planet (example: http://www.bbc.com) are still on plain http and don’t have plans to change that, but my neighbour was sleepless until she moved her cuisine blog to the latest and strongest https !

  21. bluepuma
    August 24th, 2017 at 22:03 | #21

    Talking about your website: your theme has an issue with iOS mobile. I see articles, press “more”, select one of the “more” articles. When going “back” the homepage is automatically reloaded, starts at the beginning. So I have to click more again to be where I was in the list before.

    This is especially cumbersome if I haven’t visited your site for some time and have to do multiple “more”s every time after reading an article.

  22. August 25th, 2017 at 09:54 | #22

    @bluepuma
    I can reproduce that on Android too. I guess that’s an issue with WPTouch + Banhaus 2.0 theme.

  23. Sander
    August 25th, 2017 at 12:40 | #23

    avra :
    @cnxsoft
    I fully understand your position, but that means that I will check your blog much less frequent. I do not think that company will upgrade WinXP machines any time soon.

    Your company is still on WinXP?! And you’re allowed to visit Internet with that? Interesting …
    I can imagine that WinXP is running on some autonomous system somewhere deep down in a bunker or a factory. I did not know about situations like yours. Can you give more context: big/small company? What kind? Government? Which part of the world? Reasons for not moving? Is your company paying Microsoft the XP-support-money, or is it without support and updates?

  24. JotaMG
    August 25th, 2017 at 17:23 | #24

    @Sander

    Hi Sander!
    How much STUPID can you get ??

  25. avra
    August 25th, 2017 at 18:52 | #25

    Sander :
    Can you give more context

    Eastern Europe, 5000 workers, heavy industry, no payed xp support. Internet is behind firewall. Some software we use works only on WinXP.

  26. August 27th, 2017 at 10:22 | #26

    As expected, there’s a “time cost” of enabling https, but I did not know what to expect.
    I have some stats now, and while Googlebot used to crawl webpages in around 350ms on average, it now takes around 450ms.

  27. JotaMG
    August 27th, 2017 at 18:41 | #27

    cnxsoft:
    using http or https should not be about “speed”, but about being rational.
    unless there is a very strong case – and a blog, any blog, does not fit in that – http is the way to go, because of… KISS!
    (keep it simple, stupid)
    after all, almost we all came here because we are fascinated what can be achieve with these little boards and chips, and all this is about simplicity!!
    am I wrong??

  28. alfon
    September 3rd, 2017 at 05:52 | #28

    @JotaMG :
    There are some serious reasons for switching to HTTPS over HTTP, even if your site does not serve critical information. These reasons include SEO, preventing content injection, preventing cookie stealing and becoming a PITA for spy agencies.

  29. September 16th, 2017 at 09:09 | #29

    Finally, HTTPS does not increase page load time, at least Googlebot download time. It’s just when the site first moved to https Googlebot re-crawled all pages, and within a week or so, it went all back to normal -> https://www.cnx-software.com/wp-content/uploads/2017/09/https-vs-http-crawl-stats.png

  30. October 29th, 2017 at 14:29 | #30

    Received Let’s encrypt renew message today, despite settings auto renew with cron job. That’s because of a version mismatch:

    Content of logfile:

    I had to manually update certbot cloudflare plugin:

    And the renew command could run (but telling me not up for renewal yet).

  31. November 14th, 2017 at 09:47 | #31

    One more https issue when linking to http websites: Referral traffic is not shown in Google Analytics.

    According to https://vickeryhill.com/blog/google-analytics-referral-data-loss/ that’s because “It turns out that secure websites (https://domain.com) will not send referral data to non-secure websites (http://anotherdomain.com). Traffic will show up in the Referral Traffic report as Direct.”.

  1. No trackbacks yet.