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.
- We will remove the LibApps > Admin > Domains and Certificates option to toggle “Force HTTPS” for good by the end of Q1 2019.
- If your site is not already set to enforce HTTPS, we set that for you beginning Jan 2nd, 2019. We will do this a few sites at a time each day to ensure that everyone is covered before the end of Q1 2019.
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!