 Hi everyone. Thank you so much for joining us for our webinar today, How and Why Libraries Should Move to HTTPS. Just a few housekeeping items before we get started. So just so you guys know, all callers will be muted. If you lose your Internet connection, try refreshing your browser and use the link that was emailed to you earlier today. If you have to leave early or if you want to watch the webinar again, we will be hosting the webinar on our website at techsoup.org slash community slash events dash webinars. We'll also be sending an email with the presentation and the recording and any relevant links. If you're on social media, feel free to tweet at us at TechSoup using hashtag TS webinars. However, we will be monitoring the chat box that you see on the left-hand side of your screen. So just a little bit about TechSoup, we are in 236 countries and territories and we serve over a million organizations around the world. We partner with several technology partners like Adobe, Intuit, Amazon Web Services, Microsoft, Symantec to help make our mission possible to provide technology that's either discounted or donated or free. So for today's webinar we have a lot of people with us which is really nice. But before we get started, I just want to make sure you guys can hear me. So if you don't mind telling me where you're calling in from and using the Q&A box just so I know where you guys are calling in from and I can read a few of them out. Okay, so we have Lee from Kentucky so she can hear me. North Carolina, Austin, Texas, Chris from Arizona. Cool. Okay, so it seems like the sound is working okay. So I'm going to go ahead and introduce today's presenters. So today we have Sarah Grant. So she is the Director of Communications at Let's Encrypt which is a 501c3 nonprofit. She advocates on behalf of the Let's Encrypt goal of getting the web to 100% encryption with user spanning from individuals in countries with oppressive governments to Fortune 50 companies. The idea is that everyone benefits from a more secure and privacy respecting web. So thank you Sarah for joining us today. We also have Bobby Hammond who is a librarian and digital experience consultant. Bobby is with the Colorado State Library. He builds and maintains websites for the State Library and other library related organizations. And he also consults on user research, UX, and analytics. And we have Michael Enos who is the Senior Director of Community and Platform for TechSoup Global. So he won't be presenting today but he'll be on standby for any technical questions that you guys might have. He also worked at the Second Harvest Food Bank of Santa Clara and San Mateo counties to manage technology and information systems. He helped transform the organization into a more effective enterprise using sophisticated technology to efficiently distribute food, communicate, raise money, and measure the food bank's impact. And then we have LaChica Phillips. You've probably seen her name in the chat box and she's here to help with any technical issues that you might have. And then myself, my name is Seema and I'm the online learning producer here at TechSoup. And I'm going to go ahead and pass it off to Sarah now. Thank you Seema for that nice introduction. I'm looking forward to talking with you all today about encryption and less encrypt. I left at the opportunity to speak with you because libraries are very near and dear to my heart personally. I have a lot of fond memories of holding up in a quiet corner of the library during summer vacations and love renting books today digitally from the library. And because the American Library Association has been a sponsor of less encrypt since our very early days, and we love the work that is being done there to ensure the open access of information. So I'm looking forward to sharing our little corner of the web with you today. As we get started, just so we have a sense for who's on the other side of the screen, would you all be willing to complete two quick poll questions for us? The first question is whether your library has moved to HTTPS. You can respond, I think on the screen, and we'll give you a couple more seconds to answer. Results are in. So as you can see, there is a small group of people who have already adopted HTTPS, the JAG, and a lot who haven't, and a significant portion of you are not quite sure. And that's quite common as we'll see going forward. There are a lot of reasons for there being a lack of adoption of HTTPS. And then the second question is for those of you who haven't switched or you're not quite sure, what has prevented you from doing so? There's four answers here. Could it be the cost, the lack of in-house technical expertise, if not being a priority, or your organization or you're seeing little benefit from the effort? If you can respond on the screen, I'll show the results in just a couple seconds. So no one said the cost is to stop you. That's awesome. And it looks like the technical difficulty and lack of prioritization are two main barriers. And we'll talk about both of those things today. Thank you for participating in these polls. That's very helpful and informative. And my screen is lagging just a bit. Now we're on the right slide. So to get us started, I want to talk about the goal of Let's Encrypt. And it is very single-minded. I even got, you know, I weavled it into my introduction that I gave to Seema. It is to get the web to the point where an average web user doesn't visit a website that is not protected by HTTPS on an average day. And you can tell if your website or any website is HTTPS protected by encryption. First, if it has the S after HTTP, the S stands for secure. And second, depending on what browser you're using, there are various green locks or green writing or other iconography that indicate whether the site is HTTPS. You may be asking yourself, why is this something that I should care about right now? Some of you mentioned the lack of prioritization as a barrier to adoption. Well, change is afoot. There are changes coming to the user experience for Chrome which is used like 70% of the time. So the vast majority of users who have a browser are using Chrome. And sometime this month, Chrome 68 is going to come out and it will mark all HTTP sites as not secure. So right now there is not a browser warning and that's going to change imminently. Later this year, Chrome 70 will come out and it will include a red warning on HTTP pages when users enter data. So for example, I'm in Minnesota and my home library is the Hennepin County Library. If the Hennepin County Library wasn't secured by HTTPS, I would see a big red warning flash on the screen when I'm trying to enter my login information. So this type of warning damages the credibility of the site. It makes people wonder if they are even on an authentic library site and it discourages them from using library resources. So those are all reasons why now is a good time to move to HTTPS. Bobby will talk about a few reasons later why his library system made the switch and also show you some examples of what the updated UI will look like. You can get a sense for yourself. Why is HTTPS important for everybody? Another way to ask this question I guess is, why is this my problem? And the answer is that your users rely on you to be a good steward of privacy habits on their behalf. The web is simply too complex for an average user to detect authentic versus fraudulent or malicious websites. We all know about things like phishing and spear phishing, but it's very difficult for anybody, even experts, to know when a site is real or not. And it's exhausting to have your guard up all the time every day on every website that you're visiting. And secondarily, as a site owner, you expect integrity of your content. Do you want ads to be injected into your site without your knowledge? Directing people to these phishing pages? Absolutely not. It used to be that people only expected payment sites to have encryption. Remember how we all were trained back in the day to look for the green mark before we put our credit card information into a site at checkout? Today the web is so much more complex that really every site needs to be protected by encryption. Another thing you might be thinking is we are just a little library in my hometown of Duluth, Minnesota, and why would anyone want to mess with us? We're probably flying under the radar, we're probably flying. Well, as an anecdote, last summer we were talking with people who worked in the government in the state of Ohio, and they related to us that their Medicare and Medicaid sites had just been modified only weeks earlier. A group associating itself with Al-Qaeda took over the site and put up extremist messaging and images. It's not to say that HTTPS or an SSL certificate could have 100% stopped a willful attacker, but it certainly would have been a significant line of defense for these websites. And ultimately the point is that even the most mundane sites like a Medicare site can be the target, and without HTTPS you are making yourself low-hanging fruit. We're at today. As of just this month on a daily basis, 72% of web page loads are encrypted. That sounds like a great number, and in truth it is. I'll put it in context for you a little bit later, but it also means that one out of every four times a web page is loaded, someone is exposed to unsecured content. Just in your own life. Think about how many websites you visit yourself on a daily basis. So the mission of Let's Encrypt is to get that number to 100%. We monitor this number very closely. You can see it tracked on our website if you are so interested. And this is the barometer against which we measure our success and our achievement of our mission in the world. Now that I've concluded the portion of our presentation where I leave you with a sense of fear and disillusionment, I'm sorry it had to happen, here's the reality. If you haven't switched to HTTPS, you're not alone. Newsweek, which gets millions of visitors every single day, doesn't use HTTPS. And until just last year, a few others you might have heard of didn't use HTTPS either. Bing.com, Baidu, Inger, CNN. Millions and millions and millions of people every day were visiting these really significant sites and they weren't using HTTPS. So don't think that you are way behind the curve on this. Adoption has really picked up in the last couple of years. And there's a lot of reasons why people have dragged a seat. I'll tell you about a few of them. First of all, it's always been really complicated. Depending on your level of familiarity with HTTPS, you may already be intimately aware of that fact. For a long time, somebody in your organization needed to figure out you even needed a certificate. Then figure out where you get a certificate. Figure out what kind of certificate you need. Figure out how to request the certificate. Go through a really historically painful manual verification process. Maybe set up a new email address. Hey, figure out how to install your certificate. And remember to renew it on time. All of this can take a long time. Weeks, months, we've talked to some organizations that have been on the journey toward adopting HTTPS for years if they have a lot of domains that they're working with. And lastly, it's always required payments. So sometimes that can be up to hundreds or even thousands of dollars a year. Enter Lex and Crip. We are a 501c3 that was started by folks from Mozilla and the University of Michigan, EFS and I. And we were started because there was a really slow adoption curve of encryption on the web. There were a lot of factors that I just outlined to you that were slowing progress. And Lex and Crip was specifically created and designed to respond to these problems. We are backed by a lot of the titans of the internet, Cisco, Akamai, Google Chrome, Mozilla, Facebook. All of these are sponsoring organizations that ensure our continued ability to provide trusted and reliable certificates. I just checked the stats. We're now securing over 90 million websites around the world. I'd like to share with you a little bit about our organization philosophically and how we operate. It's a little bit different from the traditional type of certificate authority that the kind of category of industry we're in. First of all, we are very focused on automation. Automation ensures ease of use, reliability, and scalability. Scalability is very important for our mission as a nonprofit. Reliability is very important to be a trusted certificate authority and provider of HTTPS. And ease of use is what makes it approachable and easy for people without a great deal of skill to adopt HTTPS. We are free. People have suggested to us that we charge a dollar or even one cent to cover our costs. But then someone would have to find a credit card or a PayPal account and find out who in finance can authorize the charge and remember to pay when it's time for renewal, not to mention that there are lots of people in countries, in different countries, where they don't have access to a credit card. So we are free. Our certificates are free. We pride ourselves on being transparent and open. You may have heard of this expression security through obscurity before, which is a kind of industry term for you keep things secure by not telling anyone anything about what's really happening behind the curtain. And we do not believe in that as an approach. We are really diligent about making sure that our users and our sponsors and supporters are aware of what is happening at Let's Encrypt. Whether it is good things or sometimes there are bad things that happen. We think it's responsible for people to know about both. And lastly, we are a global organization. We believe this is a secure web is for everybody. There are three types of SSL certificates that you can get from a certificate authority like Let's Encrypt. We only offer one kind which are called domain validation or DV more commonly. These assert control of a domain. And it associates a certificate, associates itself with a cryptographic key, a public key with the domain. And it doesn't assert who owns the server legally nor does it assert anything content-wise about the site. So an important misconception that we like to clear up is that the green lock doesn't mean in the broadest sense that a site is safe. It just means that the connection between the site and the server is encrypted and secure. This is true of all SSL certificates. Although the two following kinds, organization and extended validation, we try to give a greater deal of assurance by including additional pieces of information that are vetted through a manual and human process. We don't provide these types of certificates because we are automation-oriented nonprofit and doing a lot of these extra steps would be not feasible for us in the budget that we have available. And because we believe that domain validation is a fundamentally fine way of encrypting your communication. I won't get into too many technical details about how Let's Encrypt works, but as a basic overview of the process, the Acme server or the Acme client, which is your web server, issues the certificate request. And Bobby will take you through his example a little bit later and talk about how his library did it using what's called SIRTBOT. That's our recommended client. It's run and maintained by the electronic frontier foundation. And the client requests the certificate, the Acme server sends back a series of challenges, which are basically tests for you to prove that you have control over the domain. Then the subscriber, you complete the challenge and send the message back to Let's Encrypt that they've been completed. If the challenges are completed successfully and verified by the Acme server, us, Let's Encrypt, the certificate is issued. If it's not successfully completed, then the certificate request is denied. So you can see that this is a pretty quick and straightforward and automated process. If you should decide to use Let's Encrypt to get your certificate, you may encounter some questions. We encourage you to go to our community forum to get these questions answered. There are over 10,000 members of the forum. Most questions that you might have have already been asked and answered. That said, there is no question that is too basic. The people who are in the forum are very helpful, very friendly. We actively monitor and participate in the forum to make sure that it continues to have an open and welcoming presence. Our response time is typically within minutes. Our developers monitor the forum and they participate as well as a lot of people with a great deal of expertise. The reason that we point people to our community forum is that as a nonprofit, we do not have an email support or help system in place. The idea is that with an automated request and certificate retrieval process and the encouragement of setting up a cron job to have your certificate renewed, there should be very little that requires manual intervention. But if you have a question, feel free to ask it. I'd like to talk a little bit about what makes lesson crypts different beyond, of course, being a nonprofit and offering free certificates, of course. One of the most significant differences is that our certificates last for 90 days and then they need to be renewed or they will expire. And when a certificate expires, that means that your website will go back to being HTTP. Before lesson crypts, the standard for a certificate lifetime was one or three or even five years. But that means that if you or someone accidentally leaked your private key and you didn't know about it, someone could be manipulating your site for a really long time without your knowledge or control. And certificates with shorter lifetimes mitigate that threat. They also encourage automation. So we suggest that every 60 days you set up a cron job to just make sure that the certificate is renewed. And that way, if there is some kind of a problem, you'll get pinged about it and you'll have 30 days to try and figure out how to work out any kinks. We could even see some day having certificates that are shorter than 90 days, hours or days long. And this would essentially really reduce or even eliminate the need to revoke a compromised certificate because it would just expire. Also, a little bit more on our commitment to transparency. We are great advocates for certificate transparency, which is a concept wherein all certificates are recorded in a public log. And you as a domain holder can go to the log and see what certificates have been issued against your domain. So that makes it a lot easier for you to know if something kind of unusual is happening, and it also allows researchers the opportunity to see if there are any unusual or questionable behaviors happening inside of certificate authorities. We have our whole certificate authority available on GitHub. And I mentioned earlier our quick and complete incident disclosure. And lastly, by being a nonprofit, we have the benefit of oversight from our 501c3 status. Okay, so Let's Encrypt is everywhere. One of our key principles is being a global operation. And that is because here in the United States, we have a lot of options for getting certificates. You could go to Symantec or DigiSearch or Komodo or many others to get an SSL certificate. But there are a lot of places in the world where it is quite difficult and before Let's Encrypt even impossible. In fact, there are countries that as far as we know, we are the only certificate authority who is willing to issue a certificate to their CTLD, their country code top level domain. And a lot of those countries you can probably guess which ones they are. And they're places where there is a higher likelihood of having website communications be intercepted where people could be persecuted for the kinds of information that they are even reading about or opinions that they are expressing. So we feel it's really critical to offer a secure web to everybody. All right, so I promised that I would put in context the number of 72% of page loads being encrypted today. And here it is. HTTPS was invented essentially in 1994. And essentially 20 years following, 40% of page loads, 39.5% were encrypted on a daily basis. And today that number has almost doubled. Let's Encrypt has been a major catalyst for this kind of progress, which is when you think about movement of the entire web, it's practically inconceivable how quickly HTTPS has come to be the standard. But we just made our certificates free and available and reliable. It's people like you who have pushed the agenda internally, taken up the banner and made it happen that have really changed the game as far as HTTPS adoption goes. So we feel great about where the web is and where it's going. And I'd just like to end by saying if you haven't adopted, go ahead and do so and help us get to 100%. Here are some ways that you can contact Let's Encrypt. And I will turn it over to Bobby to talk a little bit about his organization experience moving to HTTPS. Thanks, Sarah. So my name is Bobby Hammond. I'm the digital experience consultant here at the Colorado State Library. And we recently moved all the websites we host over to HTTPS. And I'm going to talk a little bit about our experience in making that transition and why we thought it was necessary. First, just to give you a bit of context about what we do, we don't have a single website. The Colorado State Library builds, maintains, and hosts websites for free for almost any Colorado Library cultural heritage organization or other library-related organization that wants one. So we host a number of sites for various units of the State Library itself and also for many smaller Colorado libraries and for several other external clients as well. So we have a lot of websites that we're responsible for on several different servers, on several different platforms, mostly WordPress, some Drupal 7, and even a couple of Omega sites. My own work focuses mainly on the front end of these sites, HTML, CSS, PHP, and JavaScript are my stock and trade. So I'm not a systems administrator, so I can't really talk in depth about how the process of moving to HTTPS worked from that point of view. But I hope that my experience will be relevant to many of you who also aren't necessarily working directly with your servers, but maybe are supervising an IT staff, or in some way helping to guide your organization's IT policy. And I think my background matches that of a lot of librarians, for example, especially in smaller academic and public libraries who are or might be soon tasked with implementing HTTPS encryption. So I hope my experience will be informative and hopefully reassuring if you are at all anxious about moving to HTTPS, not to take away any of the drama here, but it really was really easy for us. So I'm going to talk about what we did in kind of the reverse order. First I'm going to give you a few more details about what we moved and how, and then I'll talk about what the major factors were for our decision to make the move to HTTPS. So as I said, we host a lot of websites, and not just our own, but websites for many smaller Colorado libraries and related organizations. In total we've moved at least 29 individual sites and 32 sub-sites on 15 different domains and 46 sub-domains over to HTTPS. And so with so many sites to look after, we didn't take the decision to move to HTTPS lightly. It wasn't something that we could do on the run as it were, especially in the early phases of the project. We did some very careful planning and testing to make sure that we could implement HTTPS without it being a major pain in the neck for us or causing major problems for our clients. So we did some prospective content reviews to find potential problems that we might encounter if we move to HTTPS and to see if those problems could be easily resolved. And for some sites, we would implement a certificate on a development site first and test for any problems there before trying with the live site. But especially as we gained experience in the process, not every site required such a full-scale testing. So if we couldn't do it on the run, we could at least do it at a jog, I'd say. We started this process in early 2017. Previously we had in place a couple of secure certificates for some special purpose sites. So we had some experience with the old methods of purchasing certificates and installing them and then renewing them manually. But for most of our sites, the vast majority of our sites just served content over HTTP. With the availability of free certificates however, courtesy of Let's Encrypt, we began the process of moving all of our sites over to HTTPS. So we moved sites over in small bits at first, the standalone sites with their own domains. But as we did more, it became easier for us to manage, and we moved larger and larger sets of sites over. So overall, the process took about 10 months to complete. We were not working on it full-time obviously during those 10 months, but rather would do batches of sites at a time in the midst of doing our other tasks. So obviously as you know, we used Let's Encrypt for the free certificates. Thank you very much, Sarah and her colleagues by the way. And we used Certbot to get them into place and working on the servers. One wrinkle in this process was that many of our sites are on sub-domains. So at first, we wanted to use domain wildcards for those rather than have a certificate for each site. But we were actually ready to move those sites before the wildcards were available. And our experience with the individual certificates and Certbot had been so simple that eventually we just decided to just go ahead and move all the sites without the use of a wildcard. So each site, even if it's a sub-domain, for us, they have their own certificate. So this is what the process looked like from my perspective. And again, I'm not a systems administrator, so I can't really talk about what the process looked like from their point of view. I can say that they found the Certbot documentation very helpful and they ran into very few problems in implementing the change. So I don't think they had recourse to the forums at all, though it's great to know that those resources are there. But the documentation for Certbot is really quite good. So when we were ready to move a set of sites, we'd schedule a time usually fairly early in the morning and warn any clients that might be affected about what we were going to do and ask them not to log into the admin areas of the site while we were working just out of an abundance of caution. And our systems administrator would get the certificate in place and along with rules to force all the traffic to HTTPS. And once that was done, then it would sort of flip over to me and we'd change any of the site settings that were required and then look at each page in the sites to make sure that there weren't any errors. And though on every page there was a nice green lock in the URL bar. So I'm sorry if this story lacks compelling drama, but I can't recall any significant problems for any of our sites during this whole process. For the end user, the transition was mostly seamless with any site downtime probably counted in minutes, not even a half an hour probably. Most of the sites we moved were pretty small with under two dozen pages in total. So looking at each page to clean up any HTML problems was not a major task. And we encountered only one ILS vendor who didn't support HTTPS for a library's catalog search form. But that was early in the process and by the time we actually moved the site the library had changed to a different vendor anyway. So it proved not to be a problem. The automatic renewals for the certificates via CertBot have also been a real boom. The former process of renewing certificates was much more labor intensive, basically the same as getting a new certificate every time. And so we've not encountered any issues with the cron job and the automatic renewals since we put the certificates in place. Basically it's been you put CertBot in place and you forget about it and you just let it run. So that's been great. Let's back up a little bit to before we began the move to HTTPS and talk about why we moved. There were some practical reasons why we thought this was necessary and also some loftier reasons as well. So here's what I think were the major factors for us is that we wanted to ensure better security for our clients and their patrons. And that was sort of a pole or a carrot for us. But there was also the stick. And I think this was the most important for us. Browsers were becoming more blatant in how they flagged insecure content. And we were afraid that these warnings were going to confuse our users both the patrons of the libraries we hosted sites for and the library staffs themselves who were content authors and site admins. And it might even deter them from using the site altogether which we didn't want. And we suspected that the changes that were in place in 2017 were just the thin end of the wedge, that there were more measures like this in the works. And so we wanted to get out ahead of any future changes that would make maintaining insecure content completely untenable. And finally, we felt that changing to HTTPS was just the right thing to do in terms of good netizenship and our own professional practice as people who build things for the web. And I'll explain a bit more about each of those as we go on. So these aren't the only reasons that you could move to HTTPS. There are other major reasons. But these were not really a factor for us. So for instance, HTTPS is faster. There's better search ranking and there's more privacy. These are not bad reasons for moving to HTTPS. It's just that they were not major factors for us. And for you things could be different. Site speed was not a major factor in our decisions. We didn't worry about HTTPS being slower which I've heard some people do. But we didn't ever really talk about it being faster either. If there are performance issues with some of our sites and there are other things that we worry about much more than the certificates. Search ranking, everyone likes better search ranking. But again, this was not a major factor in our decision. It's great, but it just rarely came up in our discussions. And finally, privacy. Everyone who is not Mark Zuckerberg probably likes more privacy. At some degree, this is a factor for us wanting to be good netizens. But we never really thought about our move to HTTPS as striking a blow for privacy or sticking it to the man or anything like that. I mean, if it did stick it to the man in any way, great. I'm all for that. But it was not a major motivating factor for us. Here's what I think were major motivating factors. And I give them here in the order in which they occurred to me not necessarily in the order of their importance. But first was security. So I have to admit that I kind of regret using this image on the slide because it might be taken as implying that we felt that there was some sort of vulnerability in WordPress or any other CMS that moving to HTTPS would fix. And that's not the case. HTTPS doesn't encrypt anything on your server. It only deals with Internet traffic. And it is only a part, as Sarah said, only a part of a larger suite of security measures for any secure site. So in no way did we think it was the end all be all of site security. But because most of our sites run on WordPress, which we like a lot, that makes them a very popular target for nefarious activity. So as Sarah said, there's no site too mundane to become a target of a hacker. So our mindset towards security has always been that if there is something we can do to improve the security and reliability of our sites without unduly affecting user experience, then we'll do it. We always assume that our sites and their users are vulnerable and try to be more active in taking reasonable measures to decrease the chances that our clients and their patrons will encounter anything malicious on one of our sites. And by being both free and pretty easy to install and maintain, the secure certificate certainly seems like a reasonable addition to our security measures. And this, I think, is the major reason bad user experience was probably the most important motivation for us. Credit for this, as Sarah says, goes to the browser developers who started ratcheting up the scariness of their insecure content flags. Again, my work is mostly concerned with website front-ends and user experience. So maybe I am overrating this as our chief motive, but it was certainly the most important factor for me. So the warnings shown here are really not in your face for the average user, but they were significant enough that we worried it was going to be concerning to our clients and to their patrons. And as a librarian, I was especially concerned with this because I think that one of the main reasons people like libraries is because they are trusted guardians and providers of information. So any signal to users that your website is somehow not doing all that it can to give reliable information in a safe environment is a threat to the foundational idea of your library itself. And definitely not something you want. So I didn't want to see any library patron or any library staff using one of our websites to ever see one of these warnings and think that the site could not be trusted. Plus we assumed that more changes like this from browser developers were in the works. So it would be a good idea to make the change to HTTPS sooner rather than later. So we could more easily plan the transition on our own schedule rather than be forced to move more quickly by a browser change that would make it really unpleasant to use in secure sites. So user experience was probably the major practical reason why we moved to HTTPS. Another is this, maybe more hazy motivation of good netizenship. I put a little rainbow on the slide to indicate it's kind of utopian nature. But I think it's a practical motivation in terms of how I view my professional responsibilities as someone who builds things for the web. HTTPS is now the standard best practice for building websites and apps. So as web professionals I think it behooves us to follow best practices whenever possible. And it's a signal to our users that we care about them, that we care about our websites, and that we care about the web in general. And of course you do not want to be the last site on your block of the internet to not have a nice green lock like that one guy in your neighborhood who refuses to mow his lawn. So whether you are principally concerned with security, privacy, search optimization, site performance, or user experience, HTTPS can help make your part of the web a bit better. And by doing so it helps make the entire web a little better too. And like a well designed website and thoughtful and informative content it's a sign to your users that you are maintaining your professional responsibility to help make the web safer and more reliable. So now actually that I've said that it sounds more utopian than I thought it would and I probably should have used a bigger rainbow. But anyway our own experience here at the State Library has shown I think that moving to HTTPS can be pretty cheap and a painless process. So why not do it? And for whatever reasons you think are the most important. As Sarah's presentation said, the old reasons for not moving to HTTPS that it was expensive and time-consuming and complicated I don't think they really apply anymore. So it's just the right thing to do and it's the right time to do it. And it's been pretty easy for us and it will probably be pretty easy for you too. So again, it sort of lacked drama but that's the story of our transition to HTTPS. So thank you very much for the opportunity to talk with you and if you have any questions I'd be happy to take them. And here is my contact information if you have any questions later. All right, thank you Sarah. Thank you Bobby. If you guys have questions please feel free to use the chat box on the left-hand side of your screen. We have about 15 minutes left and we have three experts here available to help you answer any questions you might have about moving to HTTPS. So one question that we have in terms of once you've implemented a certificate in terms of actually testing it and making sure that it works, how do you go about doing this? So I think Michael, we have him here and he's the tech expert so he's going to go ahead and answer that question first. Thanks Seema. Yeah, there's some free tools on the Internet and one of the ones that I've used before for testing essentially the perimeter of a website and a domain is through a company called Qolsys provides at SSL Labs. I'm going to paste the actual site into the chat window so you can see it. And essentially if you go to the site, and this is a secure site, you can see it's HTTPS, but you type in your domain and it will provide essentially a report card. It does a lot more than just check for the certificate. It goes deeper. And so as Bobby had mentioned earlier this is really just one step in ensuring the security of your site but it is a very, very important one and this free tool will essentially test you. But you should have that test done after use. You can use it. It will test for any domain but it's especially helpful once you begin the process of securing your domain with certificates and other technologies. Excellent. Thanks for sharing that. And if you guys didn't see the URL, it's in the chat box if you want to check that out. So we have another question from Jim. Is there a good tutorial somewhere on installing a certificate on a Linux server with WordPress? Yes, I think that would be a Michael question. I'm going to pass it back to Michael. Yeah, I think depending on the flavor of Linux server that you're working with, if it's Ubuntu, my advice would be to go to the actual project, the Ubuntu project site, or do a Google search for that and look at the documentation there. In terms of installing search generally, there's tutorials available actually from all the major search providers that are on their websites. And they are specific generally to the type of server that you're installing the certificate for. The general process is, and I think that this is what I can talk to a little bit from a technical perspective, is require your sysadmin or somebody who has access to the server to issue what's called a CSR, which is a request basically with some information about the server. And then that's given to the certificate. There's some challenges that occur to ensure that you own that domain. And then of course you receive the certificate and it's got the sort of private key that then binds it back against that server and gives you that request. And so if it's a Linux server or it's a Windows server, it's the same process as just the exact commands or the things that you use are slightly different. So if I could just chime in here too. I'd want to plug the certbot documentation. So it's certbot.eff.org because they have instructions that are keyed toward software and system so that you can make your pick there. And our systems administrators were very impressed by the documentation. Perfect. Thank you. So in terms of cost, and I think Sarah maybe you want to answer this and then Bobby you can also share your experience. How much does it cost in time and money to transition to HTTPS? I know you mentioned that it was free but I guess from beginning to end if you want to share in terms of resources and actual money involved. Sure. So go ahead Bobby. Well this is just a very rough calculation off the top of my head but in total we spent maybe a week. So and when I say we I think three people two systems administrators and myself kind of planning out the transition and figuring out how the process was going to work. And then after that like I said it was an hour every other week or something like that just to make just to move sites over. And of course the certificates themselves are free and the time involved was pretty minimal I think. I did want to speak quickly to something that Bobby mentioned earlier which I know he mentioned the fact that they decided to not use a wildcard cert. And in often times I just wanted to reiterate the fact that it may be tempting to use a wildcard cert for East but if you have many sites it's actually more secure to individually have them bound. So it's somewhat because if you're using the same cert for all your websites if something was to be compromised then all your sites using a wildcard cert are compromised. So best practice is really to have a separate cert for your key your key assets essentially and not use a wildcard cert on that domain. Right and while Let's Encrypt does offer wildcard certificates we started by just offering DV domain validation certificate specifically designed to as Michael said make it easy and automated and secure and really the preferable option so we second that motion. Okay we have another question that just came in and I think Sarah maybe you want to answer this one what happens if my library doesn't or can't transition to HTTPS? Well in the short term you're just going to be subjected to the increasing browser warnings that Bobby and I talked about and that will go on for some time and become more and more prominent as the proliferation of HTTPS continues it will become more infrequent for a person to encounter an insecure site and therefore more possible for browser makers to put up larger and larger warning signs. Eventually we envision there being a world where browser makers essentially make HTTPS sites so warning laden that it's impractical essentially to be on the web if you don't have a secure site now that many years off and you know you don't need to be concerned about getting kicked off the web if you will but a lot of the things that Bobby mentioned as pros you know if you don't have HTTPS your site is going to be loading more slowly it's going to be kicked down in search results so there are correlating disadvantages to not adopting HTTPS and I guess ultimately it is possible for all sites to convert there are lots of legacy or complicated or unique circumstances that may make it more difficult but it is possible. Okay, I think we have time for one more question so Lydia is asking how would visitors find your site if they try going to the non-HTTPS URL is it a redirect or do you force the HTTPS and I'm not sure who wants to take that question. I will defer to Michael if he wants to say exactly how but we force all the traffic to HTTPS Yeah, that's exactly what happens is that the web server admin will change the web server settings to essentially force traffic to HTTPS and not allow traffic on HTTP. From a search engine perspective and from an end user perspective that happens it's not noticeable to them I think if they try to type in HTTP, forward slash forward slash and then the website address it will just automatically switch that to HTTPS and all modern web servers that would be able to provide that functionality and I think that just a little bit about the last question I think that there are some older technologies that may not be able to provide that functionality and I would say that perhaps that would be a priority first to look at those systems and upgrading those systems if we all know that as mentioned that this is the way that the internet is going in terms of security. And the flip side of that is if someone types in HTTPS and then your URL they won't ever be able to get to it if you don't have a certificate in place. That's correct. Alright everyone I think we are out of time so just to close up thank you Sarah, Bobby, Michael for presenting this information hopefully you have a better sense of HTTPS and how drama-free it is to actually move over. So just before we go if you can chat one thing that you learned in today's webinar in our chat box thanks for our presenters to understand what you learned from today's presentation so they can use it for future presentations. We also have a post-event survey so once you log off you should be prompted to answer a few questions. Any feedback that you have for us really helps, it helps dictate future content so please take a couple minutes if you don't mind sharing that information with us. If you are on social media we post a lot of helpful tips so please give us a like, heart or follow. We also have a blog, blog.techsoup.org where we post articles and again useful tips and tricks and things like that. We have webinars coming up we have our next one on 724 Design Thinking 101 726 we have a webinar on a monthly giving program and an 814 how to produce captivating digital content so please join us for our future webinars. Again if you want to listen to this webinar again it will be archived on our website at techsoup.org and again thank you Sarah, Bobby and Michael and to our sponsor ReadyTalk for today's webinar and then also to LaChica for answering all the technical questions and we look forward to seeing you guys in the future.