One of the subjects which I have written about, was that it was difficult for small-time Web-masters to obtain SSL certificates, responsible for giving httpS:// URLs, and for allowing secure connections to the server. And this seemed to be true entirely for reasons of profit, ironically even though the Internet today is focused strongly on wanting to provide security and privacy, via httpS:// specifically.
In my own, past efforts to obtain such a certificate, which is based on Public Key Cryptography, I turned to the Certificate Authority named ‘CACert’. But one drawback in using their free services, is the fact that their acceptance is not bundled with most browsers, and the official reason for that is, apparent audit failures in the past.
This meant that whatever httpS:// URLs I did have, would only display error messages in the browsers of other people, unless steps were taken to install their Root CA manually. And this can wreck the entire purpose of having a Web-site.
Well there is a new game in town, which I have started to subscribe to, named “Let’s Encrypt“. The premise of this provider is, that they can carry out all the authentication steps via automated robots and clients, yet satisfy all the requirements – and Oh Yes, They Are Free.
Since I have started using Let’s Encrypt, you may notice that all the URLs which I had offered as http:// in the past, now also have an httpS:// version. You can try to access the following link via SSL below:
I must warn you though, that if instead, you would like to open this blog using SSL, you will get an icon warning you that certain objects in this part of my site are non-secure. This message appears because I have many URLs, including images, embedded into my blog as the older http:// variety, and know of no fast way to convert all of those into httpS:// URLs. Hence, by its nature my blog will continue to display this mixed content, partially SSL and partially not, and for that reason I see no benefit to you, of accessing it via SSL.
Also please note that at the time I am writing this, there is no eGroupWare site. This may change in the future, but for now remains absent.
In This Preceding Posting, I wrote about a bizarre error, according to which the domain name did not resolve properly to my real IP address. As far as I can tell by now, this error was of limited scope. But even as such, it seems like such an unlikely error, that I feel I may be missing some obscure explanation of what happened. However, to the suggestion that the whole resolution of what the command
produced, was merely a trick which my sleep-deprived mind was playing on me, does not wash, and the reason is the fact that this error actually prevented the authentication bots associated with Let’s Encrypt from authenticating my site, simply because the server of this root CA, acting as a client, was unable to connect to my server, under the IP-address which was given.
Yet, I do wonder whether somehow, having installed the authentication robots / clients on my machine, might have made this error local, entirely to my machine, temporary as the error was…
And so the question can crop up, as to what, exactly, the purpose of Let’s Encrypt is supposed to be for my server. And the answer is, that I wanted from the beginning to be able to embed my Mini-Showcase into my Facebook Page, which I and most other people access via httpS://, and into which I can therefore only embed iframes that refer to httpS:// URLs of my own. And, which average Facebook members are supposed to be configured, to open easily.
I suppose that another question which crops up, is how I find my own experience with Let’s Encrypt. But as I have only been a user of their service for two days now, I must reply with guarded optimism. It is a bit different, from my perspective, to allow a client program installed via Linux package manager, to change my Apache server config. But that is what these software packages do. And so if a Web-master is of the most suspicious type, he may not trust this. But for the moment, my main impression is that these client-programs, running on my server, are doing what they are supposed to be doing.
It should also be noted, that one repository we need to be subscribed to, is the Debian / Jessie Backports, as the required packages are not in Main.
They do require though, that we run both our regular http:// URLs through the same server, through which we also run our httpS:// URLs. Well, there might be a complicated way to do it differently, but the only way a naive user could set it up easily, is through one server.
Which also explains why some of my own configuration has changed. In the past, my SSL server was physically a separate machine, from the one providing regular, unencrypted HTTP.