(Past HTTPS posts: Aug 24, 2017 | Sept 28, 2017 | Jan 25, 2018 | June 7, 2018)
All major browsers are now flagging HTTP pages as “not secure” as a matter of course. This move toward web-security-by-default is something we at Springshare agree with, so we’ve implemented several things to help all of you ensure that your users are always enjoying a secure experience with Springy Apps – security certificates, forcing HTTPS, and removing TLS1.0 support, to name a few – and we’ll continue to roll out security options in future. In addition, we’re always vigilant in making sure that our code and our servers are safe and secure.
You may be wondering…why should I care if my pages are loading over HTTPS? Well, it’s all about your users’ security & privacy! With data leaks and cyber attacks on the rise, it just makes sense to take advantage of every opportunity to give your users the most secure web experience possible, and HTTPS is the baseline. Also, if you’d like to use the forthcoming LibCal billing functionality (online payments FTW!), an HTTPS connection is required.
Many of our customers have already made the move to HTTPS-only, and found it easy to do! There is no downtime or cost when moving to HTTPS (unless you choose to purchase your own security certificate) and it ensures a better, more secure experience for all of your users. In fact, we have issued over 2,000 certificates (for free!) so that all you need to do is push one button to switch to all secure access, all the time. It’s a win for everyone!
What We Do / What We’re Going to Do:
- We provide free, automatically renewed Let’s Encrypt security certificates, in addition to the ability to upload your own security certificates.*
- Load your page using https to double check whether or not your site has a valid, active security certificate.
- Simply click in your address bar and type https://yoursiteURL.
- We offer the ability for sites to force all of their pages to load over HTTPS. It is not enabled by default (yet), because there may be some content on your site that you need to update prior to making that move. (See below for more info on mixed content.)
- We offer HTTPS access for all APIs, so you can ensure security of any information transferred via API.
What You Can Do Now:
- Check your site for “mixed content“: content embedded in your page that is loaded over HTTP instead of HTTPS.
Why does this matter? If your overall page is loading over HTTPS, but an embedded item on the page is trying to load over HTTP, the embedded item will not display on the page. Although Springshare has supported HTTPS for a long time, this is the primary reason we have not enforced it yet: giving you time to update your widgets and ensure all content continues to load on your pages.
- This content could be a search widget, a video, or anything else you’ve embedded. If it’s embedded in your site, it must be embedded via HTTPS.
- Notes on how to find mixed content in your site is below in the “Searching for Mixed Content” section.
- If your widget is loading over HTTP, check the site where you got the widget to see if they offer an HTTPS version.
- If your widget is from a Springy app, it’s easy! Just add https: to the beginning of the “src” to require that it load via HTTPS.
- If you use Springy APIs anywhere, make sure you’re using them over HTTPS. If not, update your calls by adding that s.
- Force your LibGuides, LibAnswers, LibCal, and LibWizard sites to load over HTTPS.
- This ensures a secure experience for your users when using those apps.
- LibInsight, LibStaffer, and LibCRM are designed to always load over HTTPS, so there’s nothing to change for those systems.
- This will be enabled for all sites by the end of Q1 2019.
Searching for Mixed Content:
- In LibGuides:
- Widget items: use the filtering options in the Content > Assets area. Once on that page, limit Type to Widgets, enter http: in the Description / Metadata field, and click Filter. Click the edit icon for each item and review as noted above.
- In LibAnswers you can use the “Search” part of the Admin > Assets > Search & Replace Links tool to find all instances of http: in your FAQ answers (yes, even though it says Search & Replace Links 😉 ). Be sure to check off the “Perform a search only” checkbox when using this tool. The first section will list any Public FAQ Links that contain http: – which may be just fine (though if there is an https equivalent, then it’s a good thing to update). The second section lists Public FAQ content that contains http:. Be sure to check this second area, as it’s likely where you may have embedded something. Also remember to check your Embedded Media / Widgets in your Public FAQs!
- Load your page over HTTPS and use your Browser’s developer tools (usually something along the lines of: right click on the page > select Inspect > select the Console tab) to see what it marks as “mixed content” on each page. This may take a while, considering the number of pages you may have on your site, but it’s an option.
- Another option is to use one of the myriad of tools that have popped up to help with this very thing! Do a web search on “mixed content check” (or similar keywords) and you’ll find options like “Why No Padlock?”, etc. (We’re not endorsing any particular thing; that site is simply noted as an example.) Continuing with using that site as an example, it works like this: you enter your https link into the tool and it scans that page (and any page that it links out to), notes any mixed content, and reports back to you with a list. It’s a great way to find all mixed content at once and/or as a check before forcing HTTPs for your site.
* Using a custom domain and seeing that your site does not have a security certificate?
Your DNS records could be pointing to the wrong place or there could be a Certificate Authority Authorization (CAA) in place that is preventing us from getting a Let’s Encrypt certificate on your behalf. We’ve contacted the handful of sites where we know this is a problem. If you’re seeing that you do not have a security certificate, contact your IT department with this information:
- Check that your DNS records are pointing to the right place.
- Check to see if CAA is enabled. If so, either:
- Add Let’s Encrypt to your acceptable certificate issuer list,
- Remove it so we can obtain / manage a certificate on your behalf, or
- Purchase and upload your own security certificate.
If you do not either allow us to successfully obtain a security certificate on your behalf or purchase one on your own, your site will be unreachable when we require all pages be loaded via HTTPS (by the end of Q1 2019). Let us know if you have any questions!
Is the URL checker going to help us identify which ones are not secure in any way — because all external vendors are not at the same state of readiness, for instance, EBSCO and Gale at the moment. We can begin by working through our database AZ list, but wondered how the url checker might help us identify these with incorrect redirects (although they may still redirect with the unsecure notification)?
Hi Susan –
We have no way of knowing what non-Springshare site is ready or not…you’ll have to check in with each of those sites. All we can say is that Springshare’s apps are good to go in terms of supporting HTTPS. I’m not sure quite what you mean by URL checker, though – are you talking about LibGuides’ Link Checker functionality? If so, that’s only going to check for broken links, not whether or not a site can support https. If you meant something else, just let us know!
If a guide has been unpublished, does it matter if it still has mixed content? Does it make the whole shebang insecure, or is it irrelevant since no one will see it or use it?
Hi Laura –
If it’s unpublished, it doesn’t matter…though if you ever plan to publish it, you will need to make sure that content is updated in order to have it appear. So if you want to start by checking mixed content on published and private guides first, then go through the unpublished guides (updating any that will / may be published at some point) at a later date, that approach should be just fine!