TL;DR Now that LetsEncrypt is stable, there is no excuse.
At Cherry Hill, we have switched all of our clients to HTTPS for our LibrarySite, LibraryDAMS (Islandora) and Read at the Library summer reading clients, as well as our bespoke hosting clients. While some have commercial certs, we have set up most of them with free LetsEncrypt.
In the last year, LetEncrypt has gone from being quirky to being stable. It now is easy to install and works with almost all common operating systems. It works with shared systems, and renewal is easy to automate.
The one area that might be lagging is shared hosting with systems like cPanel and Plesk. While there are integrations available for both of those systems, some hosting companies have been slow to implement them. AFAIK, There is a LetsEncrypt integration for the FOSS Webmin/Virtualmin hosting management system.
You cannot start on this soon enough. At least half of the sites/projects that we switch have links and widgets that block full security, and sometimes these can be difficult and time-consuming to track down. Hint: our first step is to search the css for "http://“. Unfortunately, there are quite a few service widgets that need to be updated by their providers.
The Cherry Hill Company
> On Aug 30, 2017, at 7:44 AM, Benjamin Florin <[log in to unmask]> wrote:
> How is everyone handling the switch to HTTPS-everywhere-all-the-time next
> In October Chrome v62 will start marking all pages served over HTTP with
> text input elements as insecure (
> Almost every page we serve or link to has a search box on it, so most
> libraries will effectively have to go HTTPS-only.
> Switching sites on our own domain to HTTPS-only will be easy, but requiring
> HTTPS from the databases, journals, repositories, etc that we link to is
> How is everyone else dealing with this? Do you have a sense of the scope of
> the problem? Are you already HTTPS-only?