Let’s encrypt – SSL

SSL – Everybody knows the green https:// in the browser bar. It is a seal of trust and security and signifi es a reliable site. So far, SSL certification has been very expensive, but now, the Open- Source project letsencrypt.org offers certificates for anybody – and they’re free!
An SSL certificate is mandatory now – Even more after this new Update from Mozilla Firefox. What’s to fear there? Well, on one hand the bad ranking at google and on the other the deterrence of your users. A little warning pop-up when they insert information in form can keep them from registering – and that’s the nightmare for any webmaster. Thats why we exclusivly deliver you this tutorial to work your magic and get the HTTPS you need!

This article first appeared in the AWMpro #17

We will attempt two things in this article: First of all, we are going to take a general look at this topic without getting too technical. After that, we are going to use NGINX (Ubuntu) to turn a http:// domain into a https:// domain.

Introduction – a safe web

People want to make the internet safer. A great idea in and of itself, but somehow, only a few seem to be joining the cause. Why is that? Well, sometimes, people feel it’s not really necessary, especially in the webmaster segment, after all, SSL certifi cates can quickly eat into your resources. But that changed last year when the “Let’s Encrypt” project started off ering free SSL certificates. And anybody can get them!
Now, that the cost factor is no longer an excuse, it should be easy to switch to SSL (also called TSL or HTTSL nowadays). After all, such an adjustment brings many advantages. SSL stands for security and trust. And Google is particularly adamant about supporting security on the web, which is why they grant small ranking bonuses for SSL sites. Also, Chrome is one of the most widely used browsers, and more and more often, it warns users of unsafe sites. Other popular browsers have been following Google’s lead, and their definition of safe or unsafe sites is strongly influenced by Google’s recommendations. If a site is blocked, that can quickly deter the user from visiting it again, and in the long run, it will probably aff ect the site’s ranking. If a site is SSL certified, on the other hand, the users get the trusty https:// at the top of his screen, and they immediately feel safe on the site, meaning they will also be more likely to enter their personal data or to register.

What webmasters need to bear in mind

When switching to https://, I noticed a few stumbling blocks. Generating a SSL certificate and adjusting the server and the domain was fairly easy, however, there were occasional problems with the representation, and at times, content wouldn’t load because the link structure didn’t work properly. Meaning: You embed your CSS or JS fi les using the path src=“http://…“ . But due to https, these files can no longer be found or they are blocked. So, change everythingto src=“https://…“, or better yet – and also a smart move with regard to future projects – simply use src=”//….”. This way, there’s automatically a path to http:// or https://, whether you use SSL on your site or not. The same goes for a href, img src, and anything else that requires a file path (with local files, you may encounter glitches).
There are also other requirements you have to meet if you want to turn your https:// green – a SSL certifi cate alone won’t do. The content also has to be on your own server, or if you use integrated content, it has to be integrated using https as well. For instance, if you embed a banner image using a http:// path, you’ll notice that the green https:// disappears from the screen. Instead, a sign pops up in the address bar of the Chrome browser, which, upon mouseover, tells you that the site contains content from unsafe third parties. Knowing this is particularly important if you work with affiliate programs. Their content can be http as well as https – every content source has their own way of doing things.

For instance, CamPartner and Dating Partner are already providing all their content in https. That’s a great advantage for webmasters who work a lot with PHP portals and want to switch to https.

But enough with theory – now, let’s go and make our sites “safe.”



Let’s Encrypt with Ubuntu + NGINX


  • SSH connec? on with ROOT authorization
  • Mac/Linux – Terminal
  • Windows – PuTTY ( http://www.putty.org )

If you connect to an account with ROOT authorization, you don’t need to add the following command sudo.

Step 1 – Install Let’s Encrypt Client

There are various ways of generating a Let’s Encrypt certificate. For this example, we will use “certbot” by https://certbot.eff.org. So in step 1, we are going to install it via /usr/local/sbin, using the following commands:

$ cd /usr/local/sbin   

$ sudo wget https://dl.eff.org/certbot-auto

Now, you should have a version of certbot-auto in your directory. You can call it up by entering the command ls.

Next, you need to authorize this script so it can be executed properly. To that end, use this command:

$ sudo chmod a+x /usr/local/sbin/certbot-auto

Now, the certbot- auto script should be ready for use.

Step 2 – Get your certificate

Let’s Encrypt off ers lots of options for getting your SSL certifi cate. For instance, there are various plugins – including NGINX and of course also APACHE. In our example, we will be using the Webroot plugin as it requires no further installation. All this plugin does is create a special /.well-known folder in the root directory of the website that you want SSL certified. To make sure that this folder can be accessed via NGINX, we modify the NGINX config. These, you’ll fi nd under /etc/nginx/sites-available/ default. If you have virtual servers, i.e. if you run several domains, you should also create several .conf files. Basically, you need .conf adjustments for any domain that you want SSL certified.
You can modify a file right at the terminal if you use nano (the integrated text editor), or you pick your preferred text editor and use a SFTP connection. If that doesn’t work for some reason, you can also use $ sudo apt-get install nano. Simply enter the command $ nano /etc/nginx/sites-available/default and you should be able to edit fi les at the terminal.

You also need to add the following in the server section:

server {

     .    .    .

     location ~ /.well-known {

          allow all;


     .    .    .


Tip: In the nano text editor, this symbol ^ stands for the ctrl key.

Now, we can save the file and check for errors, using the command:

$ sudo nginx -t

If everything’s all right, we restart XGINX using:

$ sudo service nginx restart

For the next step, it is important that you know the ROOT directory of the website you want SSL certified, i.e. the directory containing the website. Because now, this path will become our webroot path for the next command. We enter the domain name of our website following the -d options command. It is also possible to enter several domain names, with or without www. But make sure the domains are listed hierarchically in the right order. In our example, these are highlighted in color:

$ certbot-auto certonly -1 webroot --webroot-path=/usr/share/nginx/html -d example.com -d www.example.com

NOTE: The certbot needs super user privileges. Otherwise, you will be prompted to enter the required password every single time you do this. Don’t get scared now. When you launch the certbot for the first time, it will shower you with notifications. This is basically the initial setup, and all the required scripts are being installed. So don’t worry, next time, you can start right way.

Another thing you’ll notice is that, during this first launch, certbot will ask for an e-mail address. This is a one-time request, and just this once, don’t enter a fake address because this account will be used for important notifications and for the recovery of lost certification keys. Once that’s done and you have agreed to the terms of use, a SSL certificate is generated for your domain. Next, a text should pop up, something akin to the following:

 - If you lose your account credentials, you can recover through
 e-mails sent to sammy@digitalocean.com
 - Congratulations! Your certificate and chain have been saved at
 /etc/letsencrypt/live/example.com/fullchain.pem. Your
 cert will expire on 2018-01-02. To obtain a new version of the
 certificate in the future, simply run Let's Encrypt again.
 - Your account credentials have been saved in your Let's Encrypt
 configuration directory at /etc/letsencrypt. You should make a
 secure backup of this folder now. This configuration directory will
 also contain certificates and private keys obtained by Let's
 Encrypt so making regular backups of this folder is ideal.
 - If like Let's Encrypt, please consider supporting our work by:

Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 Donating to EFF:                    https://eff.org/donate-le

What you can glean from this is a) the expiration date and b) the path to the certificates. To make sure that everything is in place, execute the following command:

$ sudo ls -l /etc/letsencrypt/live/example.com

Now, you should be seeing these on your screen:

lrwxrwxrwx 1 root root 40 Jan  2 11:21 cert.pem -> ../../archive/example.com/cert1.pem

lrwxrwxrwx 1 root root 41 Jan  2 11:21 chain.pem -> ../../archive/example.com/chain1.pem

lrwxrwxrwx 1 root root 45 Jan  2 11:21 fullchain.pem -> ../../archive/example.com/fullchain1.pem

lrwxrwxrwx 1 root root 43 Jan  2 11:21 privkey.pem -> ../../archive/example.com/privkey1.pem

If you want to be extra careful, you can generate a 2048 bit encryption, a so-called Diffie-Hellman Group, at this point. All you need is this simple command:

$ sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

It may take a few minutes, but once you’re done, you have a strong DH Group in the directory /etc/ssl/certs/ dhparam.pem.

Step 3 – Configurating SSL

Now that we have a valid SSL cer? fi cate, we need to tell our site to use it in order get that coveted green h? ps://. To that end, we need the site’s NGINX confi g that the SSL is intended for. For the purpose of our example, we’ll stick with the default setting.

In the server section, we erase the first two lines:

listen 80 default_server;

listen [::]:80 default_server ipv6only=on;

and replace them with this:

listen 443 ssl;

server_name example.com www.example.com;

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

If you use the Diffie- Hellman encryption, you need to add a little more:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_prefer_server_ciphers on;
 ssl_dhparam /etc/ssl/certs/dhparam.pem;
 ssl_session_timeout 1d;
 ssl_session_cache shared:SSL:50m;
 ssl_stapling on;
 ssl_stapling_verify on;
 add_header Strict-Transport-Security max-age=15768000;

Apart from adjusting the server block, we also create a second server block for a permanent 301 redirect from http to https. Personally, I like to put this section in front of the actual server block.

server {

     listen 80;

     server_name example.com www.example.com;

     return 301 https://$host$request_uri;


This way, all previous http:// links and hits are redirected straight to the new https:// version

Step 4 – Renew / Auto Renew

SSL certifi cates are only valid for one year; after that, the certifi cate needs to be renewed, which can be done either manually or automatically. This makes a lot of sense because you don’t always notice when a certificate expires, and the number of invalid certificates can go up very quickly. So, to be on the safe side, we create a new CRONJOB, i.e. a command that will be executed by the server at certain intervals.
First of all, let’s talk about how you renew a certificate manually, just to be on the safe side. All you need is this simple command:

$ certbot-auto renew

Now, the certbot will check all existing certificates, renewing them if necessary. Since we’ve only just got our certificates, what we would be seeing on our screen at the moment is this:

The following certs are not due for renewal yet:

/etc/letsencrypt/live/example.com/fullchain.pem (skipped)

No renewals were attempted.

To make sure that this process is repeated in regular intervals, we create a CRONJOB. So, let’s open a new CRONTAB, using the command:

$ sudo crontab -e

Next, we enter the following:

30 2 * * 1 /etc/local/sbin/certbot-auto renew >> /var/log/ssl-renew.log

35 2 * * 1 /etc/init.d/nginx reload

Save and – you’re done! You now have a cronjob that will execute the certbot- auto renew command every Monday at 02:30 before refreshing NGINX at 02:35. The process and the notifications are saved in the log of the following path: /var/log/ssl- renew.log.


That’s it. You now have a domain with a valid SSL certificate that is automatically renewed. If the site also meets the other requirements I listed above, you will see the green https:// on your screen.

If not, use the web console to find out which files or links/ paths stand in the way of your https turning green. Simply open the context menu via right click, examine the element, and the Chrome developer window pops up.

This is where you find the console with all the blemishes on the website. Now, you should be able to determine why your https is not a safe https. Eliminate the mistake on your site, and everything should be golden – or rather, green.

No Comment

Leave a Reply

Der Countdown läuft! AC Kickoff 2018!

Ab morgen gibt es 1€ extra pro Lead*!
Jetzt schnell noch Kampagnen anpassen: https://t.co/gRyoFvvLUN

Mehr Infos gibt es hier: https://t.co/x1l5EpfZRG

*Lead = Double Opt In

AC Kickoff 2018: Amateurcommunity PPL + Revshare stornofrei!
Mehr erfahren -> https://t.co/MPlOex9UU5

Good things come to those who wait – And you have clearly waited enough for the shiny new Webmasterchannel! 🤩🤩🤩

Check out all about it on the blog.

And because we are working on our own page and the #SEO on it atm - have some cool #SeoTips ! 👌