Activating SSL on your Virtual Hosts

This is the least difficult thing to do but once was the most difficult thing to do. You are making it so any user of your website can send you information so powerfully encrypted that nobody can determine what they sent you as it's leaving their web browser. The world may still have the ability to read what you are sending them depending on how things are done, but you'll have definitely made them safe while sending to you.

When I first noticed the Let's Encrypt people and their offerings, I was emotionally overjoyed. For a group of people to do so much good for so many for so little, it just tugs my heart strings all over. Let's Encrypt teaches you a few things and then sends you to [Certbot+ACME] to accomplish your goal. When I did it before, it was the easiest command-line work I ever did, but in this case I'll be using that tab in Webmin called Let's Encrypt to do it this time.

One of the details you should think about prior to doing this operation is how the divide of your secure vs. public browsing should be handled with respect to bandwidth. Will your customers be shopping in a way that they transfer dozens of high resolution photos at each new page change? Is that media something sensitive that reveals too much information about the client's persona at that IP address, or is it safe for ISP snooper's to see? If it's okay for anybody in the world to know what they are looking at on your site, then divide your content into a SSL (https://) and plain type (http://) website where you can deliver most of the public information content without the calculations of encryption. In my case I have very little planned for transfer in or out and I want all the information to be secure, but I have plans for lots of self-directed learning to describe my service that won't need encryption. When I did it with the command-line method I was given the option to have all the traffic SSL or split it. After completing the video below I realized the Let's Encrypt tab in webmin does not give the option to combine the traffic. If you want everything to be encrypted and use the method I show in the video you will need to have your domain registrar do a permanent forward to send the port 80 traffic to your port 443 or tweak your virtual servers to redirect traffic to the SSL site.

e.g. In your port 80 virtual server for "" you would have this line:

That's a permanent (301) redirect that matches expressions starting with "" and puts what's after that into a variable ((.+)), then rewrites the request in the clients browser to be "" appended by that first variable ($1) from the pattern matching expression.

  • from
  • to

Notes about the video below: The Let's Encrypt module drops the Secret Key, Public Key and Certification into a specific directory. Knowing that directory helps a hacker with access to your system, so does knowing the name of the file. You can move that file to a better location (hint-hint) like maybe where your Apache or Nginx manages and defends them, and also change the file name from the default one to something else. At about 7 minutes in I copy an old-index.html file into the secure server directory, but didn't rename it to index.html to conform to Apache's default page settings; it causes errors later that I fix later. Also be on the lookout for where I assume wrong that I can require client side SSL certificates; that causes trouble for me that I do correct later. I thought I was requiring it to do handshaking and session keys.

If you test your website with Qualys SSL Labs ,

and you get a complaint about, "The server does not support Forward Secrecy with the reference browsers. Grade reduced to ??", you're going to need to follow instructions like these verbose ones from the maker, SSL/TLS Strong Encryption: How-To - Apache HTTP Server Version 2.4, to edit your Apache /etc/apache2/mods-available/ssl.conf files.

These instructions are similar but easier to follow: SSL Enabling Forward Secrecy |

Copy & Paste text for edits I made to my ssl.conf file (bold text highlights the difference):

  • <Old directive in file>
    • <New directive in file>
  • SSLCipherSuite HIGH:!aNULL
    • SSLCipherSuite HIGH:!aNULL:!MD5
  • #SSLHonorCipherOrder on
    • SSLHonorCipherOrder on
  • SSLProtocol all -SSLv3
    • SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
  • #SSLStrictSNIVHostCheck On
    • SSLStrictSNIVHostCheck On
    • SSLPolicy safe-stapling
    • SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

See also:

Addendum Note:

Go see the Qualys post about DNS CAA. It looks technical, but if its read lightly a couple times the importance will become apparent:

Even the public comments at the bottom of the post are valuable.

(added 9/19/2017)

I ran into a quirk while using LetsEncrypt in webmin for another Virtual Host site on my server. I built the vhost in Apache for both the secure and insecure site, and put a .htaccess file in the port 80 folder to immediately forward to the port 443 folder. This made the Webmin => Webmin Configuration => SSL Encryption => Let's Encrypt fail its process. It does some writing into the V.Hosts folders and reads from them, but because I was forwarding they couldn't read what they wrote... maybe? I am sure that when I renamed the .htaccess file to hide.htaccess everything went well. In three months I'll find out if I need to hide the .htaccess file again.