Some folks probably noticed that we're now using an SSL certificate to encrypt communications to the site. This is a Good Thing(tm). In case you hadn't noticed but are curious what's going on here, I'll provide a few details. First, if you're not familiar with the basics of HTTPS and TLS/SSL, you can start there. I'm going to assume that's something that everyone at least has a conceptual idea of. In the past (and still in most cases today), in order to get an SSL certificate to encrypt your site, you could do one of two things: 1. Generate a certificate request with a vendor like Thawte, Symantec, VeriSign, or many others, and pay them to sign your certificate and validate it for you to use. 2. Generate and sign your own certificate (self-signing). Both can provide the same level of technical encryption/security. The problem with the second option is that there is no way for a visitor to know for sure that the certificate you have generated actually belongs to the site that they are trying to visit. It could be an imposter posing as the site (MITM Attack) in order to hijack your credentials. Having your certificate validated by a trusted vendor allows visitors to be confident that they are visiting the correct server and site. Browsers know about these trusted vendors as well, and they have essentially a database of acceptable certificate signers like the vendors mentioned above. If the browser comes across a certificate that is self-signed, it will throw up a big warning to caution you that the certificate isn't from a legitimate vendor and that you should be careful. Some folks may have heard about a new certificate signer called Let's Encrypt. They are a new organization sponsored by a host of big tech companies and organizations with the goal of providing free SSL certificates for websites. The reasoning is simple - encryption is good for privacy and data security, but certificate signing has always been a big barrier ($$$) to entry for many sites (including TheHelper.net!) The way to achieve this goal was to make as much of the process automated as possible, so there would be very little cost to setting up the infrastructure to handle the certificate requests. The way Let's Encrypt works is this: 1. You request a certificate for a specific domain name, like www.example.com. 2. Let's Encrypt receives the request and attempts to visit the domain and do a handshake to identify that the server where www.example.com points is the same one making the request. Typically this is handled with a small program you run on the server such as Certbot. It places a small file on the server in the web root of the site www.example.com, which the external Let's Encrypt service can then request from the server via the internet and read. This verifies that the domain points to the correct server, so Let's Encrypt can then issue and sign the certificate via the Certbot (or similar) application. 3. Once the certificate is obtained, you simply configure your webserver to reference its location and use an encrypted connection for new visits. Let's Encrypt certificates have a fairly short lifespan (90 days) and as such, they require renewal on a regular basis. Luckily, the renewal process is a simple command that can be automated to run on a set schedule via the server holding the certificate, so it's a pain-free process after day 1. Hope you found this little write up informative and interesting. Let me know if you have any experience with Let's Encrypt and feel free to ask questions for anything that isn't clear.