In 2010, the idea of "HTTPS everywhere" was born by the Electronic Frontier Foundation (EFF), in collaboration with the Tor Project. In 2014, Google announced that websites using encryption woud get a slightly higher rank in its search algorithms. In 2016, Google updated its Chrome browser to explicitly identify sites that do not use HTTPS as "Unsecure".
None of which bothered me much as I do not ask for information from my visitors that requires a secure connection and my websites do not send anything worth securing. I knew it was something I should do, but never got around to it. In October 2022, I finally decided I should install the SSL certificates and use HTTPS instead of plain HTTP.
It took a couple of hours to do because most of the installers and documentation are written for Linux not Apache on Windows that I use. Specifically, I use the Apache installers from Apache Haus. Some of the documentation I found referred to different file formats which confused me no end. It did not help that I run multiple websites on the server and not just the one that most installation help articles use.
I persevered and finally got the certificates and HTTPS to work on my server. This page was written to document how I did it.
Obtaining the SSL Certificates
Looking around the internet I saw that Let's Encrypt is a widely trusted certificate authority (CA). To download and verify them I needed an Automatic Certificate Management Environment (ACME) client. Let's Encrypt lists loads of them but recommends Certbot. That might have been a mistake because unlike some Windows clients, although Certbot downloads the files flawlessly to its own directories, it cannot copy the files to the Apache directories or write to the Apache configuration files to install the certificates properly. That has to be done manually.
For Certbot to work properly the Apache service must be stopped. Certbot is a command line program and Cmd must be run as an administrator for it to work. Just find Cmd in the Start menu and right click on it and choose "Run as administrator"
Running the command prompt as administrator
Once the command prompt is open, type:
certbot certonly --standalone
One advantage of Certbot is that it allows you to enter a comma delimited list of domains for it to get certificates for. These are downloaded together in fullchain.pem. Following the onscreen instructions Certbot will download the files and put them in its directories. The files will be in the "live" directory which are symbolic links to the "archive" directory.
The Certbot directoy structure
Certbot creates a task to look for new certificates and download any new ones twice a day. The command in Task Manager is:
Powershell.exe -NoProfile -WindowStyle Hidden -Command "certbot renew"
This is going to be a problem because Certbot is simply going to download the files and not put them in the Apache folders where they are expected to be. I need to write a batch file or PowerShell script to check when new files are downloaded and copy them to the Apache directories or change the Apache configurations files to use the Certbot directories.
The first time I did this I made a mistake and did not include the www versions of the domin names. I deleted the original certificate and got a new one with the www domains as well.
Configuring Apache for the SSL Certificates
It helped that I used the Apache Haus Apache installers because that is mostly set up for SSL already. From the Certbot "live" directory copy the files fullchain.pem and privkey.pem to the Apache conf/ssl directory.
Open httpd-ssl.conf for editing. In the Server Certificate: section add the line:
Then comment out or delete the other directives in the section
In the Server Private Key: section add the line:
Then comment out or delete the other directives in the section and save the file
Open httpd-vhosts.conf for editing and in every virtual host entry, including the default, change the listening port to 443, the default port for HTTPS transfers,
then add the lines:
Each virtual host needs a new block of directives to listen on port 80 and redirect it to the https version. So for each virtual host create this:
ServerAlias example.com */example.com
Redirect permanent / https://example.com/
Then save the file and restart the Apache service so the changes can take affect.
The trailing slash on the redirects is needed to handle subdirectories. Without it, people get redirected to the homepage.
Open Port 443
Port 443 is the default port for secure HTTPS transfers and it should be open on your router port forwarding section of its control panel and it should point to the IP address of your web server.
Port 443 open on the router
Testing the Configuration
It is difficult to tell whether HTTPS is working properly when sitting at the server, but there are a lot of websites that can check your site and its certificates for you.Just search for "ssl checker". If everything is configured properly then you should see something like this:
My result from Qualys SSL Labs
My result from Ionos SSL Certificate Checker
HTTP to HTTPS Without a Certificate
3 out of 4 isn't bad
One of my sites is a little weird in the way it was set up years ago. I've got the domain name ihor4x4.com and a friend of mine registered icehouseoffroad.com which points to the server. Because I don't own that domain name I cannot get a SSL certificate for it. Because the https handshaking occurs before any files are exchanged, I cannot redirect https://icehouseroad.com to https://ihor4x4.com. Redirect permanent / https://ihor4x4.com works for the http version of icehouseoffroad.com but there's no way it will work for the https version which browsers report as "This site can’t be reached".
The website checker Detectify once offered free checks for personal, non-commercial sites. I took advantage of that and was grandfathered in when they no longer offered it. Shortly after I added the SSL certificate they did a scan of the site and something new turned up in the report they make. Three of my pages came up with the warning that there were files being served as Mixed Content (HTTPS vs HTTP). Looking at the report it said that the three pages were displaying HTTP content through the HTTPS connection. What was happening?
Mixed Content (HTTPS vs HTTP) warning from Detectify
Chrome, my usual browser had the usual secured padlock, so I tried the site Edge, Firefox, and Opera. The browser that showed any sign that something was amiss was Firefox and that showed a small warning triangle by the padlock.
Firefox padlocks: secure and with a warning
Why was this HTTP content still displaying and why didn't the browsers seem to treat it very seriously?
I opened the developer section of the browsers by pressing F12, and they all seemed to say the same thing:
Mixed Content: The page was loaded over HTTPS, but requested an insecure element. This request was automatically upgraded to HTTPS, For more information...
I took a look the pages and sure enough there were HTTP links in them. The browsers had automatically changed those to HTTPS requests and downloaded the content. They were only images, but would they have issued a stronger warning or not download the content at all if a HTTPS connection was not available or if the link was to a different file type?
As there were no warnings given by most browsers, I looked around to see if there was some sort of online checker. There are sites that will check individual pages for HTPP vs HTPPS content, but there are others that will attempt to crawl an entire site. Two of the best I have found are JitBit SSL Check and Missing Padlock - SSL Checker. HTTPS Checker has a free downloadable checker. It works very well but the free edition is limited to 500 pages, this is OK for my sites.
These tools are very useful for finding mixed content, and especially useful for finding pages that now have content completely blocked by my sites' Content Security Policy (CSP) rules. Some pages that were flagged by these tools was found to be missing content. The browser developer tools gave the following error:
Mixed Content: The page was loaded over HTTPS, but requested an insecure plugin resource. This request has been blocked; the content must be served over HTTPS.
Needless to say, the pages hghlighted by Detectify and the other tools are being checked and the links upgraded.
This page created October 22, 2022; last modified November 25, 2022