Introduction\n\nWith all the breaches that we've seen over the years, we should really be taking security seriously at this point. I'm not talking company "we take your privacy and security very seriously" AFTER being compromised, I mean preemptive technical measures based on lessons learnt in the past, up to date industry guidance and technical best practice. When we put something on the internet, we MUST ASSUME that our something will be tested by security researchers (looking to make the web a safer place), and attached through automated scripts probing for vulnerabilities, and malicious hackers looking to see what they can get away with. Your online service being challenged in this manner is as natural as breathing and as inevitable as the tide, and if you don't believe me you clearly aren't monitoring the usage your site!\n\nWhat Hacking Looks Like: Remote Code Execution\n\nOne such fight for online security is ensuring that only users and the machine(s) running your service(s) can read any communications sent via a process known as encryption. Data is converted into a structure that only the receiver with a predefined key can restructure back into the original message using a digital Private Key (think of it as a VERY long code that's practically impossible to guess). By doing this, we ensure that communications cannot be intercepted with important information stolen (like credit cards when you make a payment) and even tampered with to execute malicious intentions.\n\nIn order to deliver secure communications, traditionally the site owner (me in the case of HeyJournal) needs to create their Private Key, generate a Certificate Signing Request from it (perhaps using OpenSSL for both) and submit this to a trusted Certificate Authority who for a fee signs the request and generates a public certificate. The site owner then provides this certificate on every connection request and coordinates a secure encrypted connection. Traditionally, these certificates are expensive, and because they expire (normally after a year) they become an ongoing (high) cost and thus a barrier to entry for ALL sites to be secure. Fortunately, there does exist a viable and mature solution to these cost-prohibitive traditional certificates.\n\nA lock used to secure our online infrastructure\n\nLetsEncrypt All of Our Sites\n\nThe UK's National Cyber Security Centre is very clear on their guidance for websites, where ALL content should be served over HTTPS, NO exceptions. Their guidance includes even when served pages don't include private content, sign-in pages, or credit card details, meaning that EVERYTHING should be secure. Taking this further, popular browsers (like Chrome and Firefox) now have a secure by default expectation, where they will flag up sites as insecure when served over plain HTTP regardless of the content sent. All over, there are many initiatives taking place to secure the web.\n\nNCSC Blog: Serve Websites Over HTTPS (always)\n\nFirefox Follows in Chrome's Footsteps and Will Mark All HTTP Pages as 'Not Secure'\n\nGoogle Chrome: HTTPS or Bust. Insecure HTTP D-Day is Tomorrow, folks\n\nSo, to try and make the web a safer more secure place to browse, the Internet Security Research Group (ISRG) released a free, automated and open Certificate Authority called LetsEncrypt which they run "for the public's benefit". It provides the (previously mentioned) digital certificates for free in what they describe as the user-friendly way they can so they create a more secure and privacy-respecting web.\n\nLetsEncrypt Logo\n\nLetsEncrypt: About Us\n\nIn my opinion, by providing the ability for any website owner to easily procure certificates for no money, LetsEncrypt removes that barrier to entry that many hosts have due to how expensive it is to procure certificates via traditional means. As someone who has paid for wildcard public certificates, I can attest to the yearly financial outlay making my eyes water 🤣😭! This is especially true when you want to issue a wildcard cert which allows secure connections across all your domains and subdomains. I've provided some links below so you can appreciate the (yearly) costs involved.\n\nGoDaddy Wildcard Certificates\n\n123 Certificates\n\nGlobalSign Certificates\n\nWoman holding her head being stressed out after seeing the costs of SSL certificates\n\nPaying such fees would definitely put off many site owners, leading them to serving their sites over insecure HTTP and opening users up to the dangers of the wild wild west internet. It's never really been an expense that I've "enjoyed" let's face it 😅, however it is definitely a VITAL expense to keep the web secure and your users safe. I've touched on what can happen with insecure websites in a previous article which I've included below.\n\nProtecting Your Site Against Cross Site Scripting (XSS) [SECTION] "Use HTTP Secure ONLY"\n\nSecuring Your Site\n\nSo what does this all look like in practice then? To benefit from the free (as in beer) security certificates that LetsEncrypt has to offer, you need to install a certificate manager piece of software on your machine which serves your site to your users called 'certbot'. This software handles everything for you, can be automated and can have you encrypting your pages very quickly! It works with the LetsEncrypt Certificate Authority using the ACME Protocol to determine that you control your specified domain, for example [mydomain.com] by responding to challenges issued by LetsEncrypt on your server (that only you should be able to control) and signing a one-off value with its generated private key. This is explained in far more detail on the official page included below.\n\nLetsEncrypt: How it Works\n\nACME Protocol (LONG Read)\n\nPrior to configuring your certbot for for your certificates to be issued by LetsEncrypt, as an extra security measure I recommend (if supported) configuring your Certification Authority Authorization (CAA) records on your domain panel to support LetsEncrypt and no other authority. This means that no other Certificate Authority can issue a public certificate for your donation, and is used to prevent hackers from compromising any of the other Authorities available and issuing rogue certificates (they would have to breach LetsEncrypt. More details about this are available below.\n\nWikipedia: DNS Certification Authority Authorization\n\nLetsEncrypt: Certificate Authority Authorization (CAA)\n\nGlobalSign: What is CAA (Certificate Authority Authorization)?\n\nScott Helme: Certificate Authority Authorization\n\nSecuring our web communications with encrypted connections\n\nWhen you are ready to rock and roll, the command to get cracking is actually very simple and I'm going to use my favourite webserver NGinX to illustrate the point. Taking note of the NGinX settings file (attached to this article), we need to issue the following command where the --webroot-path option is taken from the root path from the /.well-known/acme-challenge/ route in the NGinX configuration. This path determines where certbot will place it's challenge responses that LetsEncrypt will then attempt to validate over the internet via the domain (in this case mydomain.com) you control. If everything is set up correctly, then certbot will be able to correctly respond to these challenges and have your certificates generated by LetsEncrypt.\n\ncertbot certonly --webroot --webroot-path /path/to/certbot/folder/ --domain mydomain.com\n\nWhen everything goes according to plan, you'll have your freshly issued certificates ready and waiting to be used by your webserver. One is the public certificate that you serve to anyone that wants a secure connection with your server (fullchain.pem) and one which is used by your server to handle the encrypted connections (privkey.pem). If you use Ubuntu (like I do), they'll likely be stored at the following locations (as written in the attached NGinX webserver configuration file) but you can check the logs of your system to find out specifically where they are for you.\n\n/etc/letsencrypt/live/mydomain.com/fullchain.pem\n\n/etc/letsencrypt/live/mydomain.com/privkey.pem\n\nRenewal can also be automated, which is handy as certificates are valid for only around three months. This period of time was chosen to significantly limit how long stolen certificates can be used for. In order to renew your certificates, just schedule the following (perhaps once a day) using whichever scheduler your system uses, e.g. cron for Ubuntu or Task Scheduler for Windows.\n\ncertbot renew\n\nThis example is for NGinX running on Ubuntu environments, which may differ somewhat from your ecosystem. Have no fear! LetsEncrypt and certbot can work within many different setups and with many different web servers, all of which are detailed in their comprehensive online documentation. For the but of time spent researching and understanding the tool, you could save quite a bit on yearly costs without sacrificing security and thus the safety of your users 😎.\n\nCertbot Getting Started\n\nCertbot: User Guide\n\nTesting Your Configuration\n\nWhen you've secured your web resource with your LetsEncrypt certificate, it is important that you test your configuration to ensure that everything is smooth from a security standpoint. Fortunately for us all, there are a multitude of free (as in beer) resources out there for us to make us of 😎. Many of the separate ones that I manually use are aggregated by the FANTASTIC Mozilla Observatory tool, which only requires you to enter your domain and then runs the tests it's platform as well as the others. I've included the results of HeyJournal at the time of writing, along with the links to individual sites so that you can test out the sites that you control!\n\nMozilla Observatory Scan\n\nQualys SSL Lab Scan\n\nImmuniweb SSL Scan\n\nCryptCheck Scan\n\nIt is important to understand that strong encryption on your site, provided for free by LetsEncrypt is only part of the battle when taking our users privacy and security seriously. Secure connections don't protect against application vulnerabilities, or misconfigured insecure databases being publicly available, or even malicious software installed on the machine hosting your service. Secure communications however are a compulsory measure to make the attackers out there have to think twice before hacking you (not that they won't try... they will).\n\nNo Excuses, LetsEncrypt Our Sites and Build a Safer, More Secure Web\n\nThe security of our sites is VITALLY important, and thankfully with LetsEncrypt we don't have to compromise between secure connections and cost. We may need to learn how to wield such tools initially, but it is definitely worth it in the long run. LetsEncrypt can even save on maintenance as certificate renewal can be completely automated meaning that we can spend more time elsewhere rather than manually using certificates. All of this means that we contribute to making the World Wide Web just that little bit safer 😁.\n\nTake care and all the best, Si.