So, you’ve heard about it by now, right? Riiight? The upcoming Chrome browser release, version 62 – slated for October 17, will give a warning when a user lands on a non-https page which contains forms. FireFox, Edge, and other modern browsers will follow suit as well, and warn users when they land on forms which are not loaded over https. Let’s go over what this actually means since there is a lot of confusion about this on the Internet.
What will the Chrome update do in October?
First, it is important to understand what this means in practical terms. Starting with this mid-October update, Chrome browsers will flag as insecure *only those pages that have forms in them but which are not loaded via https*. Pages that have no form elements will be unaffected, i.e., there will be no warning on these pages even when they are loaded over http vs. https.
While this change is a decision made by the browsers and their respective companies, not Springshare, we fully support moving to a more secure / safer communication protocol between servers and browsers. We’re proactively prepping our tools and you, our clients, to ensure a smooth transition to an all-https mode for the Springshare platform.
How does this affect your Springshare tools?
Your Springshare product sites will be affected. For example, the systems have search boxes, which are forms. Therefore, the warning will be displayed if you are not loading that site over https. If you’re using a Springshare owned domain (e.g., libguides.com, libanswers.com, etc.), you can start using https now. If you’re using a custom domain (e.g., ask.mylibrary.org, research.university.edu), you’ll need to work with your IT department to obtain an SSL certificate to load the site over https. More on domains is below.
In addition, you’ll want to check any widgets you’ve added to the systems (other vendor/site widgets, like those from subscription databases, social media sites, etc.) to see whether they are http or https, as non-https widgets will also trigger the warning. If they are not https, check with that vendor/site to see if they offer an https option. Springshare widgets/APIs are either protocol-less (meaning they’ll work on both http and https pages) or are already https. See our FAQ for more info.
v1 systems (LibGuides v1, LibAnswers v1, LibAnalytics)
The best advice we can give you is to move to v2. It’s a free update and the v2 platform is better, more secure, faster, feature rich…so there is no reason to stay on v1. If you’d like some assistance, our support team can help you figure out how to do it in the quickest way possible. We also have dedicated training sessions and step-by-step migration guides (LibGuides, LibAnswers, LibAnalytics) to walk you through the entire process.
For v1 systems on libguides.com, libanswers.com, or libanalytics.com, you have some breathing room because Springshare owned domains support https by default. So, even if you do not migrate to v2 by mid-October, you will still be ok. You’ll just need to start linking to your site using https instead of http.
For v1 systems that have custom domains, you must migrate to v2 before October to avoid https issues, then follow the steps below. We do not support SSL certificates for custom domains for v1 systems.
V2 systems
If your v2 system is on a Springshare owned domain – libguides.com, libanswers.com, libcal.com, libwizard.com, libsurveys.com, libinsight.com, libstaffer.com, libapps.com (phew, we have a lot of domains!) – you’re good to go! These domains already have SSL/https support built-in, so you can update all links to / within your system to https links now. For example, springylib.libguides.com is on a Springshare-owned domain, so I can link to that now via https.
If your v2 systems have custom domains (e.g., ask.mylibrary.org, calendar.university.edu), then you must install an SSL certificate before October 17, 2017 in order to avoid warnings. For example, support.springshare.com is a LibGuides CMS site using a custom domain. For custom domains, you’ll need to work with your IT colleagues to obtain an HTTPS certificate for each custom domain.
You own your domain and thereby you own the certificate, too…we just install it on our servers when it’s ready. If – gasp – you ever decide to cancel any of your Springshare tools where you have an HTTPS certificate, you still own your certificate(s) and can move it/them to any other server.
LibGuides v2 on a Custom Domain
Good news! Last week we introduced a new LibApps Admin feature, Manage Domains, where you can manage your custom domains (LibGuides / LibAnswers / LibCal) and https certificates (LibGuides)! Head to LibApps > Admin > Manage Domains to get started and (of course!) to our guide to learn all about it.
LibAnswers v2 and LibCal v2 on a Custom Domain
By mid-September we’ll release an update that will allow LibApps Admins to install and maintain SSL certificates for LibAnswers and LibCal as well, so it won’t be LibGuides-only for long!
If you really, really need to get SSL certificates installed for LibAnswers or LibCal immediately and cannot wait until mid-September, please contact us and we’ll work with you to install it manually. It’s a bit of a process, but it can be done, so do not hesitate to reach out if you need it ASAP. If you can wait until mid-September, however, you’ll be able to handle the install yourself.
LibWizard, LibInsight, LibStaffer, LibCRM
These products do not have a custom domain option, so nothing needs to be done! These products support https by default.
This domain information and info on widgets/APIs for each app can also be found in our FAQ on the topic.
We hope this post is useful in helping you prepare for this mid-October Chrome update. The new version of Chrome will bring about some changes, but it’s important to realize that it is not as bad as people might first think. If your page doesn’t have form elements it will be unaffected. You should still move to https because it’s just good web practice these days and it will make your system more secure. We are here to help, as always, so please do not hesitate to reach out to our support crew with any questions.
Onwards and upwards, and thanks for being on board!
How will this affect direct links in the system? For example, if a librarian linked to another guide using http://library.louisville.edu/endnote and we switch to https:// will the http:// address automatically redirect to the https:// ?
Hi Terri, in mid September we are going to do another security code update and introduce the functionality for admins to force all links to load over https. So you will have an option whether you want to support both http and https urls, or whether all urls should load as https. I hope this helps, feel free to email us at support with any other questions. Thanks!
Will this update take care of URLs embedded in text, or only links for Databases, Books, and links created as Assets?
Hi Jill, it’s important to emphasize that this only affects LibGuides urls – the links for databases, books, and any other links within Assets are not pointing to LibGuides content – they are pointing to other pages outside of our control so we cannot control these, i.e. we cannot force them to load via https.
Is this a good idea? Sites which don’t have HTTPS may not load if forced.
For example, if you are using the WAM proxy server with the wam_sslhost_replace method for a wildcard certificate, you have to use unsecure links — e.g., you encode nature.com as http://0-www.nature.com.wamproxy.yourdomain.edu and the wildcard converts it to https://0-www-nature-com.wamproxy.yourdomain.edu. This would be a case where forcing all links to load over HTTPS would break most of your database and journal links.
Hi Tom,
The “force to https” is an admin setting within each LibGuides system, i.e. the admin will be able to turn on/off this feature. I hope this helps, please do not hesitate to follow up or send a question to our support queue and we’ll take care of it asap. Thanks!
How will this affect links from outside our libguides.com; for example, if a faculty person or other library has set up links on their websites to our libguides.com site? Will these auto redirect from http to https?
Hi Jill, the “force to https” is an admin-setting for each system so you (as LibGuides admin at your institution/site) will be able to control it. If you prefer that not all links load over https the “regular” links can certainly continue loading over http. Thanks!
I think this actually answers my concern above. Thanks.
Tom
Can you clarify that if we use “force to https”, existing links will not redirect?
Hi Adrienne, when you say “existing links” do you mean links posted on your guides or links to the actual LibGuides? Force https will force any LibGuides urls to load over https. For example, if you had a link to your guide http://mylibguidesurl/myguide somewhere from inside LibGuides or from another webpage, this link would redirect to https://mylibguidesurl/myguide.
If, however, on your guide you have links to other resources (e.g. link to http://somecompany.com/link those will not be redirected to https since we have no control over loading those urls.
So, to clarify, only the urls that we control in terms of loading would be forced to https, if you enable this option. Hope this helps – if you have specific example that you are wondering about please let us know and we’ll respond promptly. Thanks!
Just so I’m clear, if we have custom domains for libguides and libanswers, we need two SSL certificates?
Thanks!
Hi Trish, you either need two separate individual certificates, OR you can get one SAN certificate which would cover both of these custom domains. If you get a SAN (or a wildcard) certificate you would still need to upload it twice in LibApps, once for each domain. But you can cover both domains with a single issued cert – as long as it’s SAN or wildcard type. Let us know if this helps, thanks!