0. Introduction

0.1 Why SSL certificates are essential for every website

Welcome to SSL Certificates for Web Developers. My name is Kevin Skoglund and I'm excited to teach you about SSL certificates and HTTPS. In this course, we will learn what SSL certificates are, how public key cryptography works, and why it's urgent for all web developers to start using HTTPS on their websites. We'll learn how to choose the right SSL certificate by learning about different types of certificate authorities, the different domain scopes, and the different validation types. We will learn to install a free SSL certificate from Let's Encrypt using the EFF's Certbot client. We will learn to purchase and install a paid certificate from a certificate authority. We will learn how to configure a web server to require HTTPS by redirecting any insecure requests and by telling browsers to only contact the website using HTTPS. And finally, we will learn to manage certificates and renew them when they expire.

 

0.2 What you need

In this movie, I'm gonna talk about the things that you need before taking this course. There aren't very many prerequisites, but there are a couple. The first is that you need to already have a working website. It doesn't matter how complex the website is, or what features it has, all that matters is that you have a website that's built and is on the internet and publicly available. You won't be able to take this course if you're still just thinking about the website that you're gonna create in the future. The second thing is you need to have a registered domain name for that website. Just having a public IP address that you can access it with is not enough. You must actually go out and register a domain name and have that domain name point to the website. That's gonna be a precondition of registering for an SSL certificate. The next thing is you need need to be somewhat comfortable working with the command line. Most developers have some familiarity with it, so it's not that big of a deal. A lot of web admin experience is not necessary, but the more experience you have, then the easier it will be to troubleshoot if things go wrong. Or, if you're not comfortable with the command line, you have another choice, which is you need to have a hosting provider who can help you out. Most hosting providers have the ability to perform these steps and set things up for you if you're not comfortable doing it yourself. That's it. Those are the prerequisites. It doesn't matter how much web development experience you have. It doesn't matter what programming languages you know, or what web framework you're using, this won't touch those areas. You're gonna be running commands on the server and configuring the web server software. Once you have everything, let's get started learning SSL Certificates for Web Developers.

 

1. SSL and HTTPS

1.1 What are SSL certificates?

Let's start things off by finding out more about SSL certificates. What are they exactly and how do they work? Let's begin with the simplest explanation and then get more technical from there. The way that the public most commonly knows an SSL certificate is that it's the thing that triggers the little padlock or perhaps the green bar at the top of their web browser. What that indicates is that the webpage is using HTTPS for secure communication. The most basic way to communicate on the web is using HTTP, HTTPS is the secure version of that. That's what the S stands for, is for secure. You maybe even notice that sometimes when you see a URL, sometimes it's HTTP and sometimes it's HTTPS. When we talk about secure communication, what we're talking about is data privacy and data integrity. The fact that someone can't snoop on our data and see what's being sent, and they also can't modify it while it's in transit. Now, a certificate implies that it's certifies something. So, what does it certify? It certifies the ownership of a public key. We'll talk more about public keys and the role that they play in cryptography a little later on. For now, just know that that's what it's certifying. It certifies who owns a particular public key and that's used for encrypting data that's sent between a browser and the remote server. That's how we're able to guarantee data privacy and data integrity, is by using encryption. The SSL in the name comes from Secure Sockets Layer. That's just a protocol that's used for communication. In the earliest days of the web, if you wanted to use HTTPS, then it was using this protocol along with your certificate and your public key in order to communicate. Now, in 1999, around the time that the web was about five years old, a new protocol for communication was introduced, which was TLS, or Transport Layer Security, and it's considered to be a superior version that's become far more common than SSL. And the certificates really don't depend on which protocol we use. The certificate is just certifying the public key and these two communication protocols are using that public key while they communicate, so it really doesn't affect it. But the thing is that the name SSL has stuck. Even though TLS has now been around for five times as long as SSL, no one really uses SSL for communication anymore, they really use TLS, but we still call them SSL certificates. For this reason, you'll actually see them called by many names. Most commonly, they're SSL certificates, but some people call them SSL/TLS certificates. Some people just call them TLS certificates. Some people try to avoid including the protocol altogether and just refer to them as digital certificates. Or because they're certifying the public key, you may see them called public key certificates, or because they certify the identity of the person who owns the public key, you may see them called identity certificates. All of these are valid names, they're all interchangeable. Still, SSL is the most common name that you'll see out there, but you should recognize all of them and understand why those different names exist. So, what's inside one of these certificates? Well, it certifies the ownership of a public key, so we need to know something about the person that owns it. So, we have the organization, we have the URL, the state and the country, we also have the valid data range for the certificate. Certificates aren't valid forever, they're certified just for a certain amount of time and they're certified by an issuer. Someone who actually says, yes, I am going to validate the fact that this organization, this URL owns this public key. So, all of this basic information as well as some technical details, like what type of encryption it uses, is all going to be put into a file, a certificate file, and that's typically a file that ends in .crt or sometimes .cer. Now, the contents of that file is not gonna be readable easily by you. If you open up one of those files, you're gonna see something that looks like this. What that actually is is an encoded version of that information, and it can be decoded. You can take it to a website, you can run some tools on your computer that will decode it, but this is a way to compress it down and make a good machine-readable code that can be passed easily over the internet. Now that we understand a little bit more about what SSL certificates are, let's make sure you understand their purpose. Their primary purpose is to be used with encryption. It's so that we're able to encrypt communications and communicate securely between two different computers, usually a browsers and a remote server. They also tell us something about the identity of the person who owns a particular public key, so they have that purpose as well. And beyond that, they also tell us something about the trustworthiness of that person. Now, there's all sorts of problems related to both identity and trustworthiness, and we're gonna touch on those a little later on, but these are the main purposes. The number one purpose by far is to be able to use this key for encrypting data. In the next movie, let's talk a bit more about how that encrypted secure communication works.

 

1.2 Handshakes and cryptography

In the previous movie, we learned that what SSL certificates certify is the ownership of a public key. In this movie I wanna talk a bit more about public keys and the role that they play in secure communication. To do that, we're gonna need to talk about handshakes and cryptography. But don't worry, I'm gonna keep it fairly non-technical so that everyone can follow along. The first thing we need to learn about is something called symmetric-key cryptography. The idea is simply that we encrypt data using a password. So we take some data, we take a password, we put it into an algorithm, and what we get back is some encrypted data that can't be read. We can then later come back and decrypt that data by taking the same password, putting it into an algorithm with our encrypted data, and what we get back is something that is decrypted, or readable. So the name symmetric key is a fancy way of saying that it uses the same key for both, both for encryption and for decryption. And our key is the password, and it works very much like a key would on a normal lock. In fact, we can think of symmetric-key cryptography as being a box that we can lock. We can open it up, we can put data inside of it, and then we can close it and lock it with the key. Then it's encrypted and it stays locked and the only way to unlock it is by using that same key to open the door and get the data back out. That's symmetric-key cryptography. Now, public-key cryptography works a little differently. It's also named asymmetric-key cryptography, which gives you a tip about what's different. We don't have symmetric keys, we have asymmetric keys. That is, they're not the same anymore. Instead, we have a pair of mathematically linked numbers. These are numbers the are derived from multiplying prime numbers together. You don't need to worry about the mechanics of how that happens, just know that at the end you end up with two numbers that are linked together and we refer to them as the public key and the private key. As the name suggests, the private key should always be kept secret and secure. It belongs to you, and you alone. But the public key can be shared widely. We don't care who has it. We can send it in our emails. We can post it on the Internet. We can share it with the world. The advantage of having two linked keys that are not the same, is that then data can be encrypted by the public, using our public key that's widely available, and it can only be decrypted using our private key, which only we have. So it allows the public, generally, to be able to send us private messages that other people can't read. Let's take that locked box example again. Let's imagine now that we have a box with two locks on it. On one side we have a lock for the public key, on the other side is a lock for the private key. Now the public side is unlocked. We can open it and the public can put a piece of data inside, and then they can lock it using our public key. Once it's locked, even another public key can't be used to open it again. Now it stays locked and we can submit it, even over the Internet. It's encrypted data that's completely safe. At that point, the person receiving the data, can use the private key that they have to unlock the private side of the box, and retrieve the data and read it. That's how public-key cryptography works. So now that we understand the difference, we're ready to talk about handshakes. This is also referred to as SSL or TLS handshakes, both of those communication protocols use it. The basic idea is that we're gonna use public-key cryptography in order to communicate. So let's walk through the steps. First, a browser is gonna send a request to a secure server. The server's gonna say hey, I see you have a secure request, let me send you back my SSL certificate, and I'm gonna send you back my public key and other data about my identity. The browser's gonna take a look at that and it's gonna decide whether that public key is something that it can trust. And it's gonna do that by confirming that the certificate is valid. There are a number of different ways that it can do that. The simplest is it can just look and see if the expiration data has passed yet, whether the certificate is still in its valid date range. It can also look at who issued the certificate, to see if that's someone that we trust. If the browser decides that this is something that we can trust, then it can use that public key to encrypt a very long password and send it to the server. It's the same as having that box, opening it up, putting data inside and locking it with the public key. The data that goes inside, is going to be this password. Then that can be transmitted securely, over the Internet, the server can then decrypt that data using its private key in order to retrieve that very long password. Now, here's the important point. The server and the browser now both possess the same password. That's the beauty of public-key cryptography. With symmetric-key cryptography, it works great, as long as both people have the same password, but it can be really tough and challenging to share that password publicly, without someone eavesdropping on it and finding out what it is. With public-key cryptography, we can do all of this in public and not have to worry. Now, both the server and the browser can switch over and use symmetric-key cryptography, using that shared password to encrypt all future communications. So why do it that way? Why switch over to symmetric-key cryptography when we were doing so well with the public-key cryptography? Well, it's because it allows us to have the benefits of both technologies. Public-key cryptography is great for being able to communicate private communication fully in public, but the problem is that the algorithms that do that are quite slow. Symmetric-key cryptography, on the other hand, can be difficult to send that key publicly, which makes it hard to be able to share data anonymously over the Internet, but once we have a shared key and we have a password that we can both work with, then it's very fast. So we use public key in order to swap a password, and then we switch over to symmetric key in order to get the speed advantage. So again, just to recap, the SSL certificate certifies the ownership of the public key, the public key is used to exchange a password, in public or over the Internet, and then that password is used to encrypt all data between the browser and the server from then on. One additional advantage is the fact that all of the passwords that are used for this encryption between the browser and the server are gonna be temporary and not reused. It's a one-time password, just used for this one conversation that's happening between the browser and the server. Other browsers are using a different password, and in the future, if we try and contact the server again, we'll get a new password, because we'll go through that same handshake process again. So the passwords are temporary, and that allows us to help keep that exchange data secret, as well.

 

1.3 The urgent need for HTTPS

In this movie, we're going to discuss why it has become urgent that web developers start using HTTPS on every single website. As our use of the internet has evolved, so has our usage of HTTPS. When the web was first created, HTTPS was there at the beginning, but it was used primarily for encrypting ecommerce pages. We knew if we wanted to buy something online, we needed to have a secure way to do that so we could send our credit card information securely over the internet using HTTPS. As the web continued to grow and develop, more information started going online, and people started putting whole areas of data online that needed a password to be able to get into them. Those password protected pages started using HTTPS because if we need to password protect them, then we should also keep them secure by encrypting them whenever that information is transmitted over the internet. Otherwise, it's freely available to anyone who might be snooping. So as that effort progressed and we saw more and more of those pages start to use HTTPS, at some point around 2010, people realized you know, those login pages that you're using to get to those password protected areas, if they're not already on HTTPS when that page first loads, then you're sending an insecure request in order to get access to a secure area. That means that that password that we're sending for that form is being sent in the clear over the internet. So we saw a big effort to get everyone to start to use HTTPS on their login pages, and those login usernames and passwords would be encrypted when they're transmitted, and then around 2015, we saw another change where HTTPS started to become the default for all pages. We began to realize that data privacy and data integrity matter for everyone all the time, and we could prevent a lot of malicious activity on the internet if we could just get everyone to use HTTPS, and that change has happened very quickly. In January of 2014, 26% of page loads were using HTTPS. In January of 2018, that number had jumped up to 68%. That's a huge change in a very small amount of time. Of the top 100 websites, 81 of them use HTTPS by default now. That's major websites like Google, YouTube, Facebook, LinkedIn, Wikipedia, Reddit, Yahoo, Amazon, Twitter, Instagram, Netflix, Ebay. All of these sites are all using HTTPS all the time, and that's part of what has accounted for that huge jump in page loads using HTTPS, but that's the major companies. What about everyone else? Well, at the same time, there's been a very important effort called Let's Encrypt. It's a project at the Internet Security Research Group that's a consortium that has backing from a lot of these big tech companies, and it launched in April 2016, and the project goal was for all web servers to use HTTPS. Now, those big companies were already doing it, but what about everyone else? They decided to make the process as simple as possible, so they started offering free certificates so it wouldn't cost anything, and they tried to take steps to simplify the setup and maintenance of these certificates, so there was as little friction involved in getting this process going as possible. They recently announced they have over 50 million active certificates out there, and that number is growing rapidly. So it's never been easier to implement HTTPS than it is now. At the same time, there's been important changes happening in web browsers, led primarily by Google Chrome. In January of 2017, Google Chrome made a change, and they started marking all HTTP pages, that's the non-secure pages, which have a password or credit card field on them, as being non-secure, just to provide a big warning. Hey user, this page that you're about to put your password or your credit card in, it's not a secure page. In October 2017, they took another step forward, and they started marking any page with any form on it as being not secure, and also, if you thought you were in Incognito mode, and you might be privately browsing, they also marked those pages as not being secure. Then in July 2018, they're taking another step forward, and they're marking all HTTP pages as being not secure. Their overall goal is to help users understand that HTTP sites are not secure. Let's take a look at what that's gonna look like. So normally, an HTTP page would look like this. Example.com, and it wouldn't say anything next to it. The change is that all those pages now are going to say not secure, and what you're gonna see over time is that not secure warning is gonna become more and more prominent. They're really gonna start to let people know hey, this page is something you need to worry about. It's a buggy page because it's not secure. Now Google Chrome is leading the charge on this, but other browser makers are following right along. They're also gonna make another change to HTTPS pages. Those pages right now get a big nice warning that says hey, this is a secure page. You should feel good about it. That's gonna start going away. You can see that starting September 2018, they're gonna go from having a green lock with the secure word next to it. They're gonna change it from being green and take away the word secure, and then eventually, they're gonna take away the lock altogether. The idea is that you should just expect that the web is secure, and you'll get a big nasty warning if it's not, so that's what's going to happen. It's gonna happen to your users. So it's very important that you implement HTTPS as soon as possible. It's a best practice that improves web security. The web is quickly moving to all HTTPS. Setting it up has never been easier, and at the same time, it's important for us to do it because if we don't, your users are gonna start being alarmed by the messages that their browsers are gonna show them.

 

2. Choose a Certificate

2.1 Certificate authorities (CAs)

In this chapter, we're gonna talk about how to choose the right certificate for your needs, and we're gonna begin with a discussion of certificate authorities, or CAs for short. Certificate authorities are entities that issue digital certificates. CAs certify the ownership of a public key. Remember, that's what an SSL certificate does. It certifies the ownership of a public key. So CAs are gonna perform that for us. The way it works is that we're gonna go to one of these CAs, we'll provide them with some information about ourselves or our organization. Most importantly, we're gonna tell them what URL we're gonna be using, then we're gonna give them a public key. And then sometimes we'll have to pay a fee as well. They'll then in turn validate that that public key and that information all matches up and looks good and give us back a certificate certifying the ownership of that public key. It's similar to notarizing an identity. In the real world, you might go to a notary and ask them to notarize a document you are signing. You might bring your identification so they can see you are who you say you are, and they can say that they did see you sign the document. It's a similar process here. The idea is that we have a trusted third party that's going to vouch for this public key. The browsers are gonna keep a list of the certificate authorities, either their own list or they'll borrow one from the operating system. A browser's gonna trust those certificate authorities, and since a CA has certified a particular URL owns a public key, a browser knows that it can trust the public key. Now, we should pause for a moment here and just talk about what kind of trust the browser actually has. What has been certified is that a public key belongs to a particular URL. That's it. It's not saying anything about the entity behind that URL. We don't know if they're good people or bad people. We don't know if their business is doing well or if they're about to go bankrupt. All we know is this public key is a legit key for that URL. We haven't been given a fake one by someone who may be trying to trick us, right? Somehow intervene in the process of connecting to this URL. We know the public key we're getting from whatever website we're connecting to belongs to that website. We'll come back to this point again a little later. So certificate authorities are actually based off of a couple different levels. The first level is root certificate authorities. There are very few of those, those are the ones that have the sort of ultimate authority of the internet to decide who's trustworthy and who's not. But because there's only a few of those, they can't handle the huge volume of certificates that are required, so we need more CAs. Now, we don't wanna just add more root certificate authorities and bestow this sort of top-level trust on them, so what we do is we create intermediate certificate authorities. The root CAs are able to delegate their work and their trust to those intermediate CAs. So a root CA vouches for an intermediate CA, an intermediate CA vouches for a URL's public key, a browser that trusts the root CA then can trust the public key. We end up with a chain of trust. We don't have to know about every single intermediate CA, we just have to know that it's a trusted intermediate CA that's been trusted by the root. There are many certificate authorities that are out there. Most of them require a fee in exchange for their service, in the same way that a notary might require a small fee to notarize a document for you. So at the time that I'm recording this, these are the most popular certificate authorities based on the number of certificates that they issue. You'll notice that on the right-hand side, Symantec actually owns several different ones. So you can actually by a Symantec certificate, or Verisign certificate, GeoTrust, they're all coming from the same place, but it's worth noting that they all have different prices and different options and things like that. So they still function like different companies, they've just all been acquired by the Symantec brand. Up until 2016, if you wanted to get an SSL certificate, these were the companies that you had to go to in order to get one. Now we have another option, which is Let's Encrypt. We'll talk about that in the next movie.

 

2.2 Free certificates with Let's Encrypt

In the last movie, we talked about some of the paid certificate authorities you can use in order to get an SSL certificate. It's also possible to get free certificates now using Let's Encrypt, and we all like free, so let's talk about what that is. Let's Encrypt is a free certificate authority, you can access it at letsencrypt.org, of course that's HTTPS because of course it's gotta be an encrypted site. It's a nonprofit organization that's promoting the adoption of HTTPS. They would like everyone on the web to be using HTTPS all the time, and to help make that happen, they're providing free certificates that are easy to set up. Now, these work exactly like the certificates you get from paid authorities, but there are a couple of small differences. One, you can't get all the same kinds of certificates that you could at all the paid authorities, and we'll talk about different certificate types in a moment. But we have limited choice among the types that we have, and the certificates from Let's Encrypt are valid for 90 days, but they're auto-renewable. At the paid certificate authorities, you typically get one that's good for like a year, maybe more, and then it just sits there on your server and every year you go back and you renew it and you update it again. These certificates are good for a shorter period, but they make it easy for them to auto-renew. It's almost automatic. So they're good for a very short period of time, but they auto renew, they recommend you auto renew every 60 days so that you don't actually run out of time. So six times a year, your certificate will need to auto renew. Let's go to their website and take a look. So this is letsencrypt.org, their website may change over their time as they update it but hopefully there will still be a nice big Get Started button. And we'll come back to that later and find out how we can actually install certificates using Let's Encrypt, but they try to make it as easy as possible. So a couple of other things to note here. First of all, it is a nonprofit, so you can donate to them. There's also documentation to help you out, and then I wanna come over here to About Us, where they have some statistics. Let's take a look at those, because they show some of the points that I've been making. This is a chart on the growth of Let's Encrypt, and you can really see how Let's Encrypt has taken off since the project first started in 2016. So in just a very short amount of time, it has just skyrocketed. It looks like it's going to continue. And then if we look at the percentage of web pages loaded by Firefox using HTTPS, we can also see the enormous growth there. So the blue line is showing all users, the green, orange and red lines are breaking it down by USA, Germany, and Japan. So look at the blue line there, and notice that it's gone from 30% and it's climbing up there and it's at 70%, and it's still climbing. So we're getting there very quickly. And a lot of that growth has happened in 2016, as a result of Let's Encrypt. If you scroll down just a bit more, you can get an idea for how many certificates Let's Encrypt is issuing per day. There's a couple of big spikes in there, but overall, you can see that they're issuing pretty steadily over half a million certificates every single day. So Let's Encrypt offers a great opportunity for us to get free certificates that are easy to set up. We'll come back and talk about how to set them up in the next chapter.

 

2.3 Self-signed certificates

We've learned about certificate authorities and we've seen that there are paid certificates and free certificates. There's another kind of certificate that I at least wanna mention to you, which is self-signed certificates. Self-signed certificates are certificates that have not been approved by a certificate authority, instead they've been signed by you. You're the one who vouches for them, not a certificate authority. That still allows you to perform encryption with them because they still have a public key attached. But what they lack is third party trust. We don't have that organization out on the internet who is vouched or the fact that this public key belongs to this entity. So if you try to visit a website that uses a self-signed certificate, the browser is going to display a security alert because it doesn't trust it. So why in the world would you ever want to use a certificate that isn't trusted by a third party? Well they're useful when you have two systems that wanna communicate with each other that already trust each other. Let's say for example that I work at a big company and I have an office that's in San Francisco and another one in New York. And I control all the servers, so I know what the public keys are on both of these servers. I can vouch for them, I know that they're legit and I don't need a third party to tell me that. Those two servers should be able to communicate and use encryption and use all the kind of mechanisms like TLS that we have to communicate back and forth without having to go to a third party in order to trust them. It's a rare case that you'll ever need that, but they are an option for you. If you're a web developer, 99.9% of the time you wanna stay away from self-signed certificates and use one of the paid or free certificates from a certificate authority. There are rare cases where you might wanna have a self-signed certificate while you're setting things up and trying it out, but most of the time, if going to have users coming to your website, you want them to have that third party trust.

 

2.4 Certificate types

In this movie, we will discuss the different types of certificates. All certificates perform the same basic function, they certify the public key belongs to a website or organization, but there are differences in how they are issued that are important to understand. The first difference is the domain scope. The most common type of certificate is a single domain certificate. This would be a certificate where a public key is certified to belong to a single website, for example, www.coolsite.com. Notice that that URL includes the subdomain in front of it, www. Our certificate and our public key would be certified only for that single domain, including the subdomain. If we wanted it to apply to multiple subdomains, for example, library.coolsite.com or members.coolsite.com, well, then we would need to get a wildcard certificate. It's exactly the same, it just allows us to have different subdomains. We'd have one certificate and one public key, and we could use them for coolsite.com, library.coolsite.com, members.coolsite.com and so on. There's a third variation on this which is the multi-domain certificate. Again, it's the same kind of certificate, but we're allowed to have one public key and one certificate that's able to be used for multiple domains. It'd be used for coolsite.com, greatsite.org, and coolsite.net. There's a fourth variation on this which is the UCC or SAN certificate. That stands for Unified Communication certificate or Subject Alternative Name. Those are similar to multi-domain certificates, but they're primarily used for Microsoft Exchange and Office communication environments. Paid certificate authorities may offer some or all of these different domain scopes as options when you purchase, and you'll just wanna purchase the one that's right for you. The second difference is the level of validation. The three validation levels are domain validation, organization validation, and extended validation. All three would use the same public key and the same type of encryption. What is different is the effort that the certificate authority makes to validate the ownership of that public key. Simply put, they charge more money to do more work in validating that an owner is who they are. Domain validation is the most common, and they're only certifying that the public key and the website domain name are related. Typically, the way this is done is an automatic email is issued to the website owner that's listed in the WHOIS database. That's the database of people when they register a domain name. So, it'll send it to whoever says that they own this website, and if they can receive that email and respond to it, then that's proof of ownership enough. They may also ask you to post a data file on the website because if you own the website, you should be able to put a small data file up there that they can then see publicly. Those are just very simple ways that we make sure that a URL belongs to a public key. Organization validation has the same kind of validation as domain validation, but it also confirms the authenticity of the organization by checking business databases for articles of incorporation and confirming the physical address of the business. That's it, it just checks those databases and makes sure that this entity does actually exist, it's not made up. Extended validation does the same type of validation as organization validation, but it takes one additional step to validate the organization. An actual human person contacts the business at a published phone number. They may even speak to several people there. But just having an actual person check to make sure that someone answers the phone there and this business is who it says it is. And that's all it does, it just checks to make sure that someone answers the phone and says yes, this is the right business. Now, of these three levels, domain validation is gonna be the cheapest, the fastest, and the easiest. Extended validation is going to be the most expensive. Now, of course, certificate authorities want to sell you that most expensive option. They'd like you to pick extended validation, so they're gonna make it sound like they're doing a whole lot of extra validation and that it's so valuable to have extended validation. But at the same time, they wanna keep their cost low and validate it as cheaply as possible, so beware their sales pitch. The original idea was that these validation levels are supposed to imply that more validation means that the site is more trustworthy, but what you're paying for is really just basic online research and a few phone calls to verify that the business exists. It says nothing about whether a business is reputable or whether it's in good financial shape, just simply that it exists. One of the perks of having extended validation, though, is that many browsers will display it differently when you go to a site that have extended validation. They'll put a nice, big green bar at the top and they might even put the company's name instead of the URL. That can make them look much more trustworthy. Certificate authorities love that, but the problem is that hackers can buy extended validation certificates, too. They realize that these make websites look more trustworthy than they actually are, and for that reason, a lot of the browser makers are beginning to stop doing that. They're gonna stop showing these big trustworthy banners for extended validation certificates, and the values of extended validation certificates is going to decline. So, in short, if your goal is to encrypt your communications or to prevent browsers from complaining to your users, just pick simple domain validation. If you're goal is to provide the highest reassurance to your customer as possible, go ahead and still pick the extended validation. It does still convey that additional trust right now. If the additional cost of getting extended validation makes you pause, then you probably don't need it.

 

3. Install a Certificate with Let's Encrypt

3.1 Certbot

In this chapter, we're going to learn to install SSL certificates using Let's Encrypt. If you visit the Let's Encrypt website, they recommend that you do that using something called Certbot. Certbot is a separate project from Let's Encrypt. It's developed by the Electronic Frontier Foundation, or EFF, and it's a client for Let's Encrypt that's written in the Python programming language using something called the ACME protocol, ACME stands for Automatic Certificate Management Environment. So, you have three different groups that are all working together to make SSL certificates easier. Let's Encrypt provides free certificates. The group that developed the ACME protocol makes it easy to manage certificates. And then you have the EFF, which has created the Certbot client which uses that ACME protocol to issue Let's Encrypt certificates. To see how it is easier, let's look at an overview of a traditional SSL certificate installation. We'll go into this more in depth in the next chapter. The first step is that you need to generate a public-private key pair, then you need to use that public key to create something called a certificate signing request, or CSR. It basically is the public key plus some additional information. Then you'll visit a website for certificate authority and you'll pick out the kind of certificate you want. That might be a single domain certificate or a wild card certificate. You might choose domain validation or extended validation. Once you've selected your certificate, you'll submit your information and your CSR data. Then you'll wait for them to validate you. After that process is done, you'll actually receive a certificate. That certificate is a digital file that you would need to put on the web server, and then you need to edit the web server's configuration file to tell it where to find that digital certificate file. Now let's look at an overview of the process when using the ACME installation. You would login to your server, perhaps using a command line client or SSH to get to a remote server. You would download Certbot or another ACME client software. And then you run the software, and that's it. The software walks you through all the steps. It generates the public-private keys. It contacts Let's Encrypt and proves to them that you own the domain. Then it receives and restores the certificate file. It edits the web server configuration so that it knows where to find it. Their goal was to make obtaining certificates much easier, and it is. Now, it should be noted, this is the best case scenario. It's important to understand all the steps that it performs, because some setups you may need to perform some of those steps yourself. For example, if you use Apache or Engine X as a web server, then Certbot should edit the configuration file for you, but if you use other web servers, it may not. The Certbot process is continually improving their support for different servers and different configurations. In the next movie, I'm gonna demonstrate how to do a Certbot installation.

 

3.2 Install using Certbot

In this movie, I'm gonna demonstrate how to install an SSL certificate using Certbot. So to begin with, let's go to the Let's Encrypt page and you'll see that there's a big button here for Get Started. So somewhere on this page, it may change over time but there should be something to say, let's get started. And it'll tell you here that Certbot is their preferred way to do it. And there's a link to the Certbot site. Certbot, of course, is a separate project by the EFF. So if we go to this page, it comes up and it says okay, we're gonna help you do this but I need to know what software you're using, and what kind of system you have. So for my demonstration, I'm gonna be showing it with one of my servers, I'm gonna be using the Nginx web server software, that's a very popular choice. Apache is also a very popular one. But you see they have a couple of other choices here. And then I can choose the system that I'm using. And I'm gonna be using Ubuntu 16.04. So that's the one I have, you'll choose the one you're using. And then it'll come up and it'll say, okay, here's the instructions, right? It goes through and it just gives you all the steps that you need. Now these instructions may change after the time that I've recorded this, and if they do, definitely go with what they tell you on the website. I'm recording it at this point in time, these are the current instructions as of today. But if there's a difference, go with their instructions. They'll modify them if they need updates. So the website that I'm gonna do this to is a temporary website that I've set up. I've just called it SSL Test and I registered the domain name ssltest.site. Now you have to have a domain to get a certificate. It's not enough to just have an IP address, you must register a site with a domain name because we have to attach our certificate to a domain. So I've registered ssltest.site and just put up a simple HTML page as a sample. I can log in to that from my command line using SSH, I have a shortcut here that it'll just let me log in as SSL tester. And you can see that I'm just in the home directory called Kevin. I'm going to change directories to my web directory and let's take a look at what's in there. You'll see that I have something called SSL test site and if I check again for SSL test site and see what's in that directory, you'll see there's just a simple file there called index.html. And we see that over here in Chrome. So now I'm going to go to my Nginx directory which for me is stored in etc/nginx. I'm just gonna clear my screen, we'll do ls-la so we can see the list of what's in there. You'll see that there's that directory called sites available. If we look inside there, sites available, you'll see ssltest.site is one of the sites that's available to me. And I have it configured and turned on and we know that because we can see it in the browser. So now I'm gonna go to cat sites-available/ssltest.site and you'll see that I just have a very basic configuration file in there. Now if you're using Nginx, yours is possibly very different than that. I just put in the most basic thing that I could, just sort of get things up and running. So now if we go back this Certbot page, we can follow the instructions that they have and install Certbot. So I've already done these steps. I actually have already done them so that all of these first steps are done, I've installed all the apt-get repository updates and things that I need. So now, come down here, once I've installed the software, it's just as simple as running this command right here. Sudo certbot space dash dash nginx. So I'm gonna copy that line, we'll come back over here, I'll clear the screen and let's run it. So I'll type in sudo certbot space space dash nginx. Now for me, it already remembered that I had my sudo password entered, for you it may pop up and ask you for a password. But then it runs the Certbot program. So it says, alright I'm gonna be using Nginx, the installer is Nginx, so first I need an email address that we're going to use. So I'm gonna put in my email address. So it starts a new secure connection to Let's Encrypt. Read the terms of service, once we agree to them we type in A. Would you be willing to share your email address with the EFF who helped develop Certbot? You can say yes or no, it's up to you. I'm gonna say no in my case. Now which names would you like to activate it for? And we have a choice. Select the appropriate names, commas or spaces, or leave them blank. Let's do it just for the first one, so number one. So does the challenges, the checks to make sure, it's actually doing the domain verification right there. It did that by actually putting a digital file on the website so that it was visible to Let's Encrypt and then it cleans it up and takes it away afterwards. So that proved that we're on the system that's making the request. It validated it that way. So do we want to redirect our HTTP traffic to HTTPS? It's gonna do that for us. So we do wanna redirect that, we wanna make all requests that used to go to HTTP now go to HTTPS. So let's say, two, let's redirect. And that's it. Congratulations. It tells you where the file has been saved, notice that here. It's in etc/letsencrypt/live/ssl.site/fullchain.pem. Pem is just a format that it puts that in. And it tells us where our private key is. Now this is our private key, we never wanna share with anyone. It tells us when the certificate will expire, so we'll need to set up something that will renew this for us periodically. Right now it's only going to last for a few months. And that's the whole process. Now I'm just gonna clear the screen, and let's hit the up arrow a couple of times. And let's take a look at that ssltest.site and you'll notice that it actually modified our config file for us. See that? So it has listen 443, that's the port that's used for secure connections and it tells us where it finds that certificate file, right here, SSL certificate is the directive. It tells us here, tells us here where our private key is located. And it also did a redirect here so anything that comes in just to ssltest.site gets redirected to HTTPS. So now let's switch back over here to SSL test and let's hit return. And look at that. It redirected me automatically to HTTPS. It's no longer possible to go to the insecure version of the site. We now know that we have everything set up and working. Now that's a demonstration using Linux Ubuntu and Nginx but if you follow the instructions on the Certbot site, it should not matter which one of these platforms you use. You should be able to plug in anything here and it will walk you through the process.

NOTLAR
https://letsencrypt.org/

 

3.3 Install using a hosting provider

In the previous movie we saw how easy it is to install a Let's Encrypt certificate using Certbot. But that's not the only way to install it. If you want to install Let's Encrypt and perhaps you don't have shell access, so that you can't access the server to run those commands, or maybe you're not comfortable with the command line, or you tried it out and it didn't work. Then you have another option, which is that if you have a hosting provider you can contact them and ask them to set up a Let's Encrypt certificate for you. This has become a very common request and most hosting providers can assist you. You'll just need to open a troubleshooting or tech support ticket with them and ask them to help you out. On the Let's Encrypt website right after the instructions about how to use it with shell access it says Without Shell Access and it says then you can contact your hosting provider and they actually have a link here to a list of hosting providers that do really good support for Let's Encrypt. Now this is probably not an exhaustive list, but it is a very long list. If we go down here for that has full support, there's a few for those, but then for a regular support look at this long list, it just keeps going down and down and down. All of these all support Let's Encrypt. Now there are a few that say they don't have support and hopefully that will change in the future, but for now chances are your web host can help you get this set up. So just contact them and see if they can walk you through it. There is one other thing that they note here, which is that if you still don't have support from your provider you can do something called manual mode. Now this does require you to actually upload some files and it's a much longer, involved process, but it is possible. You can follow this link to manual mode and then you can use Certbot, but by uploading some files yourself. It's not as convenient and it definitely should be your last resort.

 

4. Install a Purchased Certificate

4.1 Certificate signing request (CSR)

In this chapter, we're going to learn how to install a purchased certificate. If you already installed a free certificate, using Let's Encrypt in the previous chapter, then you can safely skip this entire chapter. In this chapter, we're only gonna be looking at paid certificates that come from traditional certificate authorities. The first thing that those certificate authorities are gonna want when you go to their website, is for you to give them a certificate signing request, or a CSR, so let's learn how we create that. The first thing you need to know about certificate signing requests, is you should not be tempted to use any of the online CSR generators that are out there. They do the job perfectly fine, but they have a big problem. The first step in creating a CSR, is generating a public-private key pair. You'll remember from our discussions about public key cryptography, that private key is something we want to keep private. It's not something that we wanna generate on some unknown, remote website, and then transmit over the public Internet to our own computer. The private key could be compromised. Either the remote site could keep a copy of it, or someone could see it as it's being transmitted. So, we always want to create our key pairs locally. There are a number of different software tools that'll let you do that, and they vary by platform. One of the most popular is something called OpenSSL. It's available for a variety of platforms. Many systems come with it pre-installed, or they have it available as a package, so that it's very easy for you to download. Once you have it installed, then you can use it to generate a key pair, and to create a CSR. And OpenSSL will walk you through the process of creating a CSR, by asking you to enter some organization information. The way we're gonna interact with OpenSSL is from the command line. We can use the command line in OpenSSL to generate a private key, using a command like this, openssl genrsa, rsa is the type of public key we're creating, and then we tell it the name of the output file we wanna use, here I've got -out, and then the name of the file, I've called it domain.key, but you would use whatever domain name you were creating the key for. And then, 2048, 2048 is the size of the key, it's the number of bits in the private key, and you're gonna wanna use 2048. Some certificates are gonna require that it be at least 2048, anything less than that is considered too insecure. Once we have our private key, then we can use it to generate a CSR. We'll again use OpenSSL to do that, but this time, we'll use the req command with it, openssl req -new, because we're creating a new request, req is short for request, and then we tell it where to find the key, and what we wanna use as an output file for our CSR. We can also do both of these steps, all in one, by using openssl req, and then using the -new option, and then also providing -newkey rsa:2048, and then specifying both the keyout, and the out. That tells us what files we're gonna use for saving both our private key, and the CSR. Most of the time, you can just do this third step, and do it all in one. It's exactly the same as doing the other two steps. The other two steps have the benefit of you being able to use an existing private key if you wanted, instead of having to create a new one. Lemme demonstrate. On my Mac, I'm in the command line, and I'm inside a folder that I've created called ssltest.ssl. Now, you can call it anything you want, you can put it anywhere you want, we just want these files to be somewhere where they're not gonna get lost. So, I'm inside that directory right now, and I'm gonna check and see if I have my program. I'm gonna use which openssl. It comes up and says yes, I know which file to use, which means it is there, so I have that software installed, and ready to go, Open SSL, and then I'm gonna use genrsa, I'm gonna use the two step process. The output file I'm gonna call ssltest.key, and again, it's a 2048 bit key that I'm creating. So, there it is, it created the key for me. Can take a look now, in the directory, and we see that's there. We can take a look at that file, and see it has some information here that's, it's encoded, so that we can't read it. It's possible for OpenSSL to decode that, so that we could read the content that's there. This is, most of the time, what your private key's gonna look like. So now that we have our private key, let's generate a CSR using it. So, openssl req this time, because I'm creating a new request, I use the -new option, - key, and I'm gonna tell it where to find that key, so it's the file that I just created, and then tell it where to store the output file using the -out option, I'll call that ssltest.csr. So, it's gonna ask me some questions, I can leave some of them blank, but it's best to try and answer as many as I can, because this information is part of my application, for my certificate. So, I'm gonna put in the country code, two letters, US, the state or province name, for me, that's gonna be, Pennsylvania, the locality name, Philadelphia, organization name, I'll leave that blank, organization unit, that's very often gonna be left blank, the common name, now here, it says, either put in server FQDN or your name. FQDN stands for fully qualified domain name. So, you wanna put the full domain name that you're using for this application. So, if that's admin.mysite.com, you wanna put it in the whole thing, including the subdomain at the beginning. This is part of your application. So, I'm gonna just make this ssltest.site, that's the full domain name that I have. .site is the ending, it's not .com, it's .site. So, I'm gonna do that, for my email address, I'm gonna put in a fake one for now, you'll wanna put in your real email address of course, and then, it asks you for some extra attributes. You wanna leave these blank. The first one is a challenge password, that has absolutely nothing to do with the cryptography, or the security of your certificate. This is a password that potentially, the certificate authority could use, to ask you before you made changes to your site. But the thing is, no one uses it. It's a feature that just, no one uses, so just leave it blank. I'll hit return on both those, and now it's done. ls -la, now you can see I have two files in there, and if we take a look at that ssltest.csr file, you'll see that the certificate request is right here. Now, you may be wondering, what happened to our public key? Right, we have our private key, that's what we created here, what about the public key? What happened is when we created the CSR, OpenSSL went to the private key, and from the information inside the private key, it was able to deduce the public key, to extract it. So, then it was able to take that public key, and to put it inside the CSR. We can actually take a peek inside the CSR, using OpenSSL, lemme just show you how I did that, openssl req - text -in ssltest.csr and no out. So, this is going to show us the text of the request, it's basically gonna decode that request for us. You can see what's inside of it. Notice here, here's that, all that information I put in, right, in the subject, it has all that information. And then, our public key is right here, public key algorithm tells what kind it is, what bits it is, everything it needs to know about the public key is right there. That is our public key. So, that's the certificate sign-in request. It's our basic answers to some questions, plus our public key. So, these are the two key files that we're going to need, to enable SSL certificates. The CSR is the public key that we'll submit when getting our certificate, it'll be used for our certificate. This other key is the private key, that we're going to put on our web server, to be able to encode and decode information with that public key, to enable public key cryptography to work.

 

4.2 Sign up for an SSL certificate

In the previous movie, we learned how to create a certificate signing request. Once we have that, we're ready to go to a certificate authority to sign up for an SSL certificate. You'll remember earlier, I gave you a list of some of the different paid certificate authorities. This is that same list again, and I'm showing them to you in roughly the order of their market share, so based roughly on the number of certificates that each one of these companies provides. I haven't used any of them, so I don't have a favorite to recommend to you. They're all going to offer slightly different features and at slightly different prices, so shop around. What's common about all of them is that you're going to have to choose the domain scope, that's whether you want to have it just for a single domain or a wild card domain or multi-domain, and you're gonna choose the validation level, whether it's domain validated, organization validated, or extended validation, and you may also be asked to choose the time period. Do you want a certificate that's good for one year or for two, and some companies may offer you a discount for signing up for multiple years. Then you'll provide your contact and your billing information, and eventually, you'll be asked to upload that certificate signing request file that we created in the last movie. After that, they'll tell you what steps you need to follow in order to get validated. It may be that there's an email that comes into your inbox that you need to respond to or they may call you up to get you validated. Eventually, once you've been validated, they'll send you a link so that you can download your certificate file. That will be your SSL certificate that's ready for you to install on your website.

 

4.3 Install on Apache

In this movie, we're gonna talk about how to install a purchased SSL certificate on an Apache web server. This is one of the hardest parts of the process of installing an SSL certificate because it requires us to know a little bit about how Apache works and to get in there and mess with those files and that's not a skill that necessarily everyone has. Most certificate authorities have installation guides to walk you through the process so you can always look there as a first place to find information or to help troubleshooting. The number one rule you should remember is that before you start editing any configuration files, make a backup of them. If you have a backup, then if you completely mess things up, you'll always have a file that you can go back to so just simply copy the existing configuration file before you start making changes. Depending on which version of Apache you have and how you have it configured, those configuration files might be in several different places. The most common are to have it inside the etc directory in a directory called httpd or a directory called apache2. It's also very common to break up the configuration for different sites into different virtual host files and to store each of those files separately and those might be in a directory called vhosts.d or sites so you could look for them there. Once you find the file, make a backup and then you can start editing. What you're typically looking for in one of those virtual host files is something that looks kind of like this. It has something that looks like an HTML tag with those less than and greater than signs on either side of it and it says VirtualHost. It might have an IP address or it might have an asterisk which would be a wild card and then it usually ends with :80. That's telling it to listen for requests on port 80. It has your ServerName, it has DocumentRoot, and there might be many other directives in there. This is just the simplest possible version. What we wanna do is either copy that and make a new directive or edit it so we have VirtualHost, notice now that it says :443. That's very important. That's the one that we're gonna use for SSL. It's a different port, not the regular port 80 and we'll talk about that in the next chapter. And then you wanna add some directives. You wanna tell it to turn on SSL. You wanna tell it where to find your SSL certificate file, where to find your private key, and if you've been given a chain file, how to find that chain file. Some companies will give you a single certificate file. Others may include an intermediate certificate file which may be referred to as a chain file. Remember we talked early on about how certificate authorities delegate and create a chain of trust from the root certificate down to all these different CAs. Once you've got that configured, then you'll just need to tell Apache to check the configuration. It can do that with apachectl configtest and it'll test out your configuration without doing anything, tell you if you have any errors. And then you'll tell it to restart. Now restart will just sort of say immediately let's stop Apache and restart it. I find an even nicer way to do it is with the graceful command that lets any existing connections that might be going on to go ahead and finish up. It doesn't close out log files immediately, things like that, so it's a little more of a graceful restart. So either one of those will get the job done. It'll restart Apache using its new configuration and enabling SSL. Make sure you check out the next chapter though where we talk about what to do with those connections that are on port 80.

 

4.4 Install on NGINX

In this movie, we're going to learn how to install a purchased SSL certificate on an Nginx web server. Installing the certificate on the web server is one of the hardest parts of the whole process. Mostly because you have to go in and edit configuration files for the web server and that may not be something that you're used to doing. Most certificate authorities have installation guides that can help you through the process. The number one rule to make sure that you back up any configuration files before you start editing them. That way if you completely mess up the whole process, you'll still have those working configuration files that you can restore and get things back up and working again. So be sure to make a copy of the working configuration file before you start making changes. Those configuration files are likely going to be stored in a directory called etc and a directory called nginx. Sometimes they might also be in a directory called opt/nginx. Inside that directory, you should find another directory called sites-available, there might also be one called sites-enabled, you don't wanna worry about that one. Sits-available is the directory that should contain the configuration files. Sites enabled should just be linked to those files. Inside that directory you should find a configuration file for your website that probably looks something like this. It might have a lot of other directives inside there but it's generally gonna say server and then have curly braces and then the key thing you wanna notice is that it says listen space 80. That's letting it know that this is port 80 that it's listing on to get requests. Now port 80, we'll talk more about in the next chapter but for now, what we wanna is make another directive or you can actually change this existing directive. Instead, we wanna make sure that it says listen 443 ssl. We gonna instead of listening on port 80, we're gonna be listening on port 443. Now again, this can be a separate directive. The whole thing, server all the way down to the end of the curly braces can be a whole separate one or you can modify the existing one. Eventually, we're going to have two of them. But for now it doesn't matter, we just need to have one of them. Notice then after I tell it to listen on port 443, I tell it the path to my certificate file and the path to my private key. Those are the different paths that I'm providing so that it knows how to find both that public key certificate to serve to people and the private key to use to interact with it. Once you've made those changes to the configuration file, you can actually check out the file to see if it works correctly using Nginx with whatever command you use to make that run. It's very common to use etc/init.d/nginx in order to access that program. The -t option tells it to just do a test just to see if the configuration is valid. And then if it is, we can tell it to restart or if we don't wanna completely restart the server, we can actually do a more graceful restart by telling it just to reload its config files without actually restarting the whole program. Either of those would get the job done. Once we've done that, we should be able to connect to our website using https. Make sure you check out the next chapter though where we talk about what to do about connections that come in over port 80.

 

4.5 Install on hosted web server

In this movie, we'll talk about other ways to install purchased SSL certificates on hosted web servers. If you use a web server that's different from Apache or Engine X and you don't know how to install your SSL certificate or if you don't have shell access, or if you're just not comfortable editing the web server config files, then you're gonna need to have someone help you through that process. Most hosting companies have installation guides to walk you through it. If that still seems daunting, that still seems like that's too much, and I don't blame you, it's not an easy process if you're not familiar with it. Most hosting companies will also make the changes for you. You just create a technical support ticket for them, you tell them what you wanna do, that you have this SSL certificate, you need help getting it installed on whatever kind of web server you may have, and they usually have people who can do it. For someone who's very familiar with working with these config files, it's a very simple operation, and they can do it in a matter of minutes. For you, it might seem overwhelming, because it's something that you don't do frequently, but they can help you out. So your best bet if you feel stuck is to contact the hosting company and ask them for help.

 

5. Configure a Web Server to Require HTTPS

5.1 Redirect requests to HTTPS

In the last couple of chapters, we talked about how to install an SSL certificate so that it's there and up and running. Now we need to talk about how we make a few more configurations to really get HTTPS in the state that we want it and the first and most important thing is we wanna redirect requests that come in over HTTP, that is insecure requests, we wanna redirect those to HTTPS. By default when you type a URL in your browser and you type http:// that's gonna send that request to port 80. That's the standard web port that most web browsers use and we saw that when we were looking at the configuration files in the last chapter that the configuration was listening on port 80. You may have noticed that when we implemented SSL, we did it on port 443. That's the default for these secure requests. It keeps them separate. So insecure requests come in on port 80, secure requests come in on port 443. So if you type https, it's gonna send that request to port 443. What we need to do now is redirect all requests that come in to port 80 to port 443 because we don't want them going to port 80 anymore, right? We're gonna be using https all the time. Now if you did this using Certbot and Let's Encrypt, it can configure this for you automatically. It's one of the steps that it asks you in the process. It says, "Hey, do you wanna do this?" Most times you wanna say yes. You wanna say, "Yes, please configure that for me," and it'll take care of it. But if you've got a purchased certificate, then you'll need to add a configuration to make that happen. If you're using Apache, you just wanna make sure that you have a separate virtual host configuration that includes :80, so that's on port 80, and then you wanna make sure that you have this line that says redirect permanent. Now I have DocumentRoot there as well. You actually I don't think even need that. I think just having redirect permanent will tell it to redirect everything that comes in, that's what the slash means, everything in every directory that comes in, it's gonna get redirected to https:// and then your domain. That will then redirect all those requests. A request will come in on port 80. Your web server will say, "Hey, you got the wrong place. "Here's the new one." It'll send that back to the browser and the browser will immediately make a new request on port 443 and get the secure connection. If you're working with NGINX, then you'll want to have a separate server directive, that's server and then those curly braces, a separate one from what you have for 443, this one's gonna say listen 80 and we're gonna tell it to return 404, which means that everything is gonna be returned as not found, but if the host equals yourdomain.com, if that's what they're asking for, then we're going to redirect them, that's return 301, that's a redirect, 301 is the http code for a permanent redirect, so return a permanent redirect to https and then $host$request_uri. So it basically says whatever you just asked for, I'm gonna tell you to ask for it again using https. Once you do that, either request that use http or request that use https in the URL will both get directed to your secure https connection. And all requests that come into your website will be using your new certificate.

 

5.2 HTTP Strict Transport Security (HSTS)

In this movie, we're going to talk about something called HTTP Strict Transport Security or HSTS for short. A few years ago, browser developers came up with a great idea. If we want everyone to be using the web as securely as possible, then it'd be a great idea if we had the ability to tell web browsers that they should only interact with some websites using HTTPS. If we could tell them, then they would know. The browser could remember that fact and it could automatically direct all requests for that website to HTTPS. There would be no more insecure connections. Now in the last movie, we went ahead and told the web server that it should make this redirect course. But remember how that happens. The browser first makes an insecure request to the web server, the web server responds by saying oh, no, no, you want the secure connection, so it sends a insecure request back to the web browser. The web browser then says oh, now I understand, I'm going to reissue the request on a secure connection, and it issues the request back. But there's first that insecure connection that happens. This prevents that. Because now the web browser knows to automatically redirect. We never have to make that insecure request. That's important because it protects us against something called downgraded attacks and man in the middle attacks, where hackers could potentially capture that insecure connection and they could steal our cookies or our session ID or they could even respond to that request by doing a redirection of their own to send us to a fake website. For example, they might redirect your insecure request to a website that looks like your bank website, and you enter your credentials thinking you've now been redirected to the secure version of your website but you're in fact entering those credentials into a hacker's website. So that's the problem that HSTS can help us solve. The way that you do that is you add a directive to the HTTP header. So the first time that a browser comes to your site, it may or may not be making a secure request to the site. But once it makes that first one and it gets this directive from your web server, well then it knows. From then on, all connections should use HTTPS. The directive name in the header is called strict dash transport dash security. That's what the browser's looking for and it wants to know how long it should remember it and any other information you want to provide. So, typically it'd say max dash age equals and then the number of seconds that the browser should remember this setting, in this case I've set it to 300 which is five minutes, and then I told it to also include subdomain so it's not just my main domain but all subdomains as well. That's up to you. If you wanted to remove that because you didn't want all subdomains, you could take it away. But typically you do want it there. And then once you've done that, restart the web server. So how do you add this directive to the HTTP header? There's a number of different ways that you could do it. The most common way, if you're using Apache, is to add a directive to your secure VirtualHost file. That's the one that ends in colon 443 and just add a directive called header always set and then the name, Strict dash Transport dash Security, and then in quotes what we want to set, max age equals 300, semicolon, includeSubdomains, semicolon. If you were on Engine X, you would also add it to the server configuration that says 443 on it, that's the one that's for ssl. We would say add underscore header as the directive. Again, strict dash transport dash security and then in double quotes, max age equals 300, semicolon, includeSubdomains, semicolon. And then notice I have a semicolon. The first one is semicolon inside the quotes, that's what we're setting in the header. The second one is a semicolon that's actually for Engine X's configuration. Once you've done that and restarted the web server, then the browser will remember for the time that you specified to only use HTTPS for their connections. Now its a good idea to start with a small number like five minutes and then increase the maximum age over time. So it's always expressed in seconds, so 300 seconds is five minutes. Once you get that working and you feel confident about it, then up it to a bigger number. So we have a bigger number like one week, or a larger number for one month. Once we know all those are working, then we can go ahead, the sort of gold standard, the one that we're really looking for, is two years. That's ultimately where you want to end up. So start with five minutes just to make sure that if you screw something up you don't have to wait too long for things to reset themselves so you can try again. But once you have it working, try and get up to two years. The reason why is because once we get to two years, we can take advantage of something called HSTS preloading. We're going to talk about how to that in the next movie.

 

5.3 HSTS preloading

In this movie, we're going to continue our discussion of HSTS, by talking about a great feature called preloading. Let's review what we've talked about with HSTS so far. And let's do it by thinking about the steps that happen when a user tries to interact with a website, starting with an insecure connection. So the user goes to their browser, and they enter http:// and the domain name. That's not going to be a secure connection, because they used http. The request is going to be sent by the browser, using HTTP on port 80, then the web server is going to be told that it should redirect all requests on port 80 to use HTTPS. We did that in the first movie of this chapter. After that, the web browser's going to say, "oh, okay, I misunderstood, let me resubmit the request." This time using HTTPS on port 443. And then we've configured our web server already to us our SSL certificate, and to respond to that correctly. In the last movie, we also told the web server to send back a header with an HSTS directive as well. Essentially telling the browser, "Hey, don't make that mistake again. From now on, for the period of time that I've specified, I want you to always use HTTPS." So we've now managed to secure things going forward. However, what about that very first connection. That very first connection is still going to be an insecure connection. Now if our user was smart enough to use HTTPS the first time, then they'll get that HSTS directive, and they'll never have an insecure connection. But if they start out with an insecure one, there's still that chance that that very first time they would do something insecurely. That's what HSTS Preloading helps us solve. The browser keeps a preloaded, global list of HTTPS-only websites. It's a list of every website that is supposed to use only SSL. It's a long list and it's getting longer. It's available on Chrome and on most major browsers. When I say major browsers, that's Firefox, Safari, Internet Explorer 11, Internet Explorer Edge, Opera, it's a long list. Now I highlight Chrome there, separate from the major browsers, because Chrome is the one who spearheaded this project, and they're the ones who maintain this global list that most of the other browsers use. Now the header is still useful to have for other browsers, they just won't get the advantage of preloading. In order for us to use preloading, we have to do a couple of things. We have to first do all of the security measures that we've already done, to do redirecting and everything, to include the HSTS directive. The HSTS directive must also have a large enough maximum age. It must be at least one year, but two years is preferred, and you should include sub domains. And then you have to add at the end of it, after the last semicolon, preload. And that tells it that you would like to preload this. And then, you must go to a website for hstspreload.org and submit your site. And tell Chrome, "hey Chrome, I would like to be added to this list. I would like you to check and see if I'm eligible, and if so, add me to the list." If you're accepted to that list, then the next time that a user receives a browser update, and they update their browser software, their browser will receive the updated list and your site will be on it. Let's go to the hstspreload website. So heres what the hstspreload website looks like right now. That may change over time, but you'll see that you can just enter a domain up here, and then click the button. And it will check to see your preload status and eligibility to be included. It goes on to provide information about this, and how this works, what browsers are included. There's a compatibility matrix that you can check out. It has the submission requirements. Those are the things that we've been working on throughout this tutorial. Have a valid certificate. Redirect everything from HTTP to HTTPS, so that if we're listing on port 80, everything goes to port 443. Serve all your sub domains to HTTPS. Serve a HSTS header on the base domain. The maximum age must be at least one year, two years is what they recommend. The includeSubDomains directive must be specified. Preload must be specified. And if you're serving an additional redirect, that redirect must also have the HSTS header. That's a minor detail that we won't need to worry about. And then they give you an example of what that looks like. So I encourage you to follow all these steps. It's a way to build up your security over time. First start by adding the SSL certificate. Then redirect all of your insecure requests, to make sure that they use that certificate on a secure connection. Then set up HSTS, slowly increasing the maximum age until you get that sorted out. And then once you have all of that working, setup preloading so that all browsers will know that your website should be HTTPS all the time.

 

6. Manage Certificates

6.1 Expiration dates

It's not enough for us simply to install an SSL certificate. Certificates must also be managed over time. In this movie, we're going to talk about expiration dates. All SSL certificates have an expiration date, so they all expire at some point. Now, this is not just a plot by the certificate authorities to get more money out of you. It's actually a security feature. SSL certificates convey trust, and expiration dates allow us to renew that trust. After all, the website may have changed hands over time, so the ownership needs to be re-validated periodically. It also gives us an opportunity to update the public and private key. Now, we could renew our certificate and use the same public key again, but this gives us the chance, at least, to provide a new public key. Hopefully that private key was kept secure and safe and was never compromised, but if it happened to have been compromised without us knowing, this gives us a chance to make sure we start fresh with a new public-private key pair. It also gives us the opportunity to update security standards. If the best practice changes and we want to use a different type of encryption algorithm, for example, we don't wanna have to wait five years to get everyone on board with that new best practice. This allows us to provide security updates throughout the internet much quicker. Now, an expired certificate is basically the same as a certificate that's just not valid. It's not any good, and browsers won't respect it. They'll display security warnings instead that can spook your users, and users aren't necessarily gonna check and see, oh, well, the only thing wrong with this certificate is just that it expired yesterday. Right, so this is something we need to keep on top of. So you're gonna need to keep track of when those certificates expire, and then you'll wanna update them at least one month before the expiration. You don't want it to creep up on you and catch you by surprise. Make sure you have plenty of time to deal with it. It's a good idea to mark your calendar with the date the certificate expires, as well as a date that's at least one month before the expiration so that you can make sure that you renew it. Don't rely on the certificate authority to tell you when your certificate needs renewing. It's not their job, it's up to you. It's very easy to figure out when a certificate expires. You just go to the website. If you click on the locker, the secure icon that's right there to tell you whether it's secure, you should have some option to allow you to review the certificate. In Chrome, I can do it this way, and you'll see right here it says who it's issued by and it says when it expires. So I need to mark my calendar for September 18th, and I also need to mark it for August 18th to make sure that I handle this one month ahead of time. Now, if you're using a purchase certificate, then you'll need to go through the whole process again. You'll need to generate a new certificate signing request and you'll need to go back to the website, you'll need to pick the certificate you want, reapply, give them the CSR, that whole process has to start over again, and you'll have to reinstall it on your system as well. The content of the certificate will be different, so you'll have to reinstall it. Now, if you're using Let's Encrypt, then you can also take advantage of Certbot and use it to manage the updates as well. Certbot can help you to renew those. In the next movie, I'm gonna explain how that works.

 

6.2 Renew Let's Encrypt certificates

In this movie, we're gonna learn how to renew Let's Encrypt Certificates. Let's Encrypt Certificates are only valid for 90 days and since we wanna renew our certificates at least a month before they expire, that means that about every 60 days, these have to be renewed. That means that we'll be renewing our certificates six times a year. That's a lot of work, and a lotta things that we have to remember. So we wanna make sure that we have a good easy way to do it, and that we automate that process as much as possible. Fortunately for us, Certbot includes a feature to allow us to renew those certificates and that makes it much easier. When we run the Certbot program and ask it to renew it will first check and see whether the certificate expires in less than 30 days. If it's more than 30 days away, then it does nothing. If the certificate is less than 30 days though, then it goes ahead and renews for us and it does that using the same options that we used originally when we asked to get the certificate. It's intended to be run as a daily automated task. So everyday your web server will just check and say hey, have I reached that 60 day limit yet? Am I 30 days away from my expiration? If I am, let's go ahead and renew. On a Unix system you would do that using a cron job. On Windows you could do that using task scheduler. Let me demonstrate how it would work on Unix since that's probably what most web developers are gonna use. You would type in the command sudo certbot renew and if you add the option --dry-run, then it will just show you whether it would do it or not. It doesn't actually perform the renewal, it just acts like it would. So it gives you a chance to see what it would do, without actually doing anything. When you're actually ready to do it, well then you just take away the dry run option, sudo certbot renew and it will renew your certificate. You can also add the -q option if you don't wanna get output. And that's gonna be important if you decide to set this up as a cron job. You don't want the output from it, you just want it to do it quietly in the background. So if you haven't used cron before, it's kind of its own thing and you would have to learn how cron works if you don't know already. To set up a cron job, you provide a line telling it when the command should run and what command should execute. So a line in a cron job file might look something like this. You see I have certbot -q renew as the command that I wanna run and then there's these weird symbols that are before it. That's actually the cron time format. The first item is the minute, the second one is the hour, then it's the day, the month, and the day of the week. And it's how I tell it when I want my cron job to run. The asterisk means any time. So if we read it backwards, starting from certbot -q renew and read backwards, the first asterisk means run this task on every day of the week, Sunday, Monday, Tuesday, Wednesday, Thursday, Friday. I don't care what day of the week it is, run it on all of them. The one before that says run it on any month. The one before that says run it on any day. One before that is for hour and it says run it for any hour, but the /12 means, every twelve hours. So two times a day, every 12 hours, it's going to run this task. It doesn't matter what hour it is, it's just gonna make sure it happens every 12 hours. And then the last one is the minute. It says to run it at the zero minute of the hour. So every 12 hours, this cron job would run. Now before you go off and start creating the cron job, note that certbot may have already created this cron job for you. You wanna go and look and see whether you have a cron job already included in /etc/cron.d and then it's probably gonna be called certbot. If you see that in there, it means that it probably has already created it. Let me demonstrate. So I'm gonna ssh into my ssl_tester server again. And let's just check and see. Let's go cd and then /etc/cron.d. These are daily cron job files. ls -la will show me what's in there and you'll see that there is one already called certbot. If we take a look at what's in there cat certbot you'll see exactly that. See this line right here. Tells it every 12 hours and then it tells this long command here. They've written a much longer version. Here's the key part here, certbot -q renew, but they've written a lot fancier stuff. It's a little bit more robust. They told it what shell to use and what path to use. This is a little bit more advanced crontab usage. But you can see they've already put it here. So certbot added it for me, I don't actually need to do anything. Now if you were doing it yourself, you could add your own file to cron.d. You could copy exactly what they've got there or you could use my smaller version or another common way to do that is just to use crontab -e, but crontab would run the cron jobs as the user that you are right now. So putting it in that .d directory, makes sure that it always runs as sudo where as doing it using crontab -e, might not have access to the sudo scope that it needs. Once you got your cron job in place or a scheduled task in Windows, then certbot will take care of the renewal for you on a regular basis and you won't have to worry about certificate expiration.

 

7. Conclusion

7.1 Next steps

I want to thank you for taking SSL Certificates for Web Developers with me. I hope that you now understand the importance of using SSL certificates and employing HTTPS on your websites, and you see how easily it can be set up. Let's Encrypt, in particular, has made this process so much easier. Just to review, remember that when I ran Certbot, it registered and installed a free certificate, it configured the web server to redirect all request HTTPS and it even set up a cron job to renew the certificate automatically. I only need to add the HSTS directive and sign up for HSTS preloading and I'm done. There's no reason not to make this change. The next step in your journey is to convert all your websites to HTTPS and to tell your friends and coworkers how important it is for them to use HTTPS, too. Together, we can make the internet more secure.