1 00:00:01,140 --> 00:00:06,120 Hello and welcome to this video on understanding SSL TLS certificates. 2 00:00:06,120 --> 00:00:13,260 In this video we will look at the absolute basics of what TLS certificates are why you need them and 3 00:00:13,260 --> 00:00:17,940 how you can configure certificates to secure SSH or web servers. 4 00:00:19,200 --> 00:00:24,690 A certificate is used to guarantee trust between two parties during a transaction. 5 00:00:24,700 --> 00:00:31,900 For example, when a user tries to access a web server, TLS certificates ensure that the communication 6 00:00:31,930 --> 00:00:37,650 between the user and the server is encrypted and the server is who it says it is. 7 00:00:38,770 --> 00:00:43,110 Let’s take a look at a scenario. Without secure connectivity, 8 00:00:43,240 --> 00:00:50,080 If a user were to access his online banking application the credentials he types in would be sent in 9 00:00:50,080 --> 00:00:52,380 a plain text format. 10 00:00:52,380 --> 00:00:58,450 The hacker sniffing network traffic could easily retrieve the credentials and use it to hack into the 11 00:00:58,450 --> 00:01:00,600 user's bank account. 12 00:01:00,730 --> 00:01:02,560 Well that's obviously not safe. 13 00:01:02,720 --> 00:01:10,630 So you must encrypt the data being transferred using encryption keys the data is encrypted using a key 14 00:01:10,660 --> 00:01:17,410 which is basically a set of random numbers and alphabets you add the random number to your data and 15 00:01:17,410 --> 00:01:24,520 you encrypted into a format that cannot be recognized the data is then sent to the server. 16 00:01:24,580 --> 00:01:28,920 The hacker sniffing the network gets the data but can't do anything with it. 17 00:01:30,070 --> 00:01:36,880 However the same is the case with the server receiving the data it cannot decrypt that data without 18 00:01:36,880 --> 00:01:38,170 the key. 19 00:01:38,170 --> 00:01:44,920 So a copy of the key must also be sent to the server so that the server can decrypt and read the message 20 00:01:45,730 --> 00:01:49,160 since the key is also sent over the same network. 21 00:01:49,180 --> 00:01:54,590 The attacker can sniff that as well and decrypt that data with it. 22 00:01:54,610 --> 00:01:58,000 This is known as SYMMETRIC ENCRYPTION. 23 00:01:58,120 --> 00:02:04,900 It is a secure way of encryption but since it uses the same key to encrypt and decrypt the data and 24 00:02:04,900 --> 00:02:11,050 since the key has to be exchanged between the sender and the receiver there is a risk of a hacker gaining 25 00:02:11,110 --> 00:02:17,520 access to the key and decrypting the data and that's where asymmetric encryption comes in. 26 00:02:18,690 --> 00:02:26,430 Instead of using a single key to encrypt and decrypt data asymmetric encryption uses a pair of keys 27 00:02:26,960 --> 00:02:31,980 a private key and a public key well they are private and public keys. 28 00:02:32,010 --> 00:02:39,470 But for the sake of this example we will call it a private key and a public lock we will get back to 29 00:02:39,470 --> 00:02:40,400 that at the end. 30 00:02:40,400 --> 00:02:46,480 But for now think of it as a key and a lock pair a key which is only with me. 31 00:02:46,480 --> 00:02:47,690 So it's private. 32 00:02:47,980 --> 00:02:50,590 A lock that anyone can access. 33 00:02:50,590 --> 00:02:53,840 So it's public. 34 00:02:53,860 --> 00:03:01,660 The trick here is if you encrypt or lock the data with your lock you can only open it with the associated 35 00:03:01,660 --> 00:03:02,710 key. 36 00:03:02,710 --> 00:03:07,750 So your key must always be secure with you and not be shared with anyone else. 37 00:03:07,750 --> 00:03:09,040 It's private. 38 00:03:09,040 --> 00:03:15,760 But the lock is public and may be shared with others but they can only lock something with it no matter 39 00:03:15,760 --> 00:03:16,480 what is locked. 40 00:03:16,470 --> 00:03:24,450 Using the public lock it can only be unlocked by your private key before we go back to our Web server 41 00:03:24,460 --> 00:03:25,180 example. 42 00:03:25,300 --> 00:03:32,720 let’s look at an even simpler use case of securing SSH access to servers through key pairs. You 43 00:03:32,720 --> 00:03:36,170 have a server in your environment that you need access to. 44 00:03:36,260 --> 00:03:39,820 You don't want to use passwords as they're too risky. 45 00:03:40,010 --> 00:03:45,730 So you decide to use key pairs you generate a public and private key pair. 46 00:03:45,890 --> 00:03:49,220 You can do this by running the ssh_keygen command. 47 00:03:49,250 --> 00:03:56,090 It creates two files. Id_rsa is the private key and id_rsa.pub 48 00:03:56,150 --> 00:04:00,880 is the public key. Well, not a public key, a public 49 00:04:00,890 --> 00:04:08,940 lock. You then secure your server by locking down all access to it, except through a door that is locked 50 00:04:09,030 --> 00:04:11,520 using your public lock. 51 00:04:11,580 --> 00:04:15,680 It's usually done by adding an entry with your public key into the servers. 52 00:04:15,720 --> 00:04:19,290 .ssh authorized_keys file. 53 00:04:19,520 --> 00:04:23,660 So you see the look is public and anyone can attempt to break through. 54 00:04:24,050 --> 00:04:30,590 But as long as no one gets their hands on your private key which is safe with you on your laptop no 55 00:04:30,590 --> 00:04:36,650 one can gain access to the server. When you try to SSH you specify the location of your private 56 00:04:36,650 --> 00:04:39,050 key in your SSH command. 57 00:04:39,050 --> 00:04:41,990 What if you have other servers in your environment. 58 00:04:41,990 --> 00:04:45,840 How do you secure more than one server with your key pair? 59 00:04:45,860 --> 00:04:51,860 Well you can create copies of your public clock and place them on as many servers as you want. 60 00:04:51,860 --> 00:04:57,800 You can use the same private key to SSH into all of your servers securely. 61 00:04:57,890 --> 00:05:02,830 What if other users need access to your servers well they can do the same thing. 62 00:05:02,870 --> 00:05:09,500 They can generate their own public and private key pairs as the only person who has access to those 63 00:05:09,500 --> 00:05:10,180 servers. 64 00:05:10,190 --> 00:05:16,910 You can create an additional door for them and lock it with their public locks copy their public locks 65 00:05:16,940 --> 00:05:18,120 to all the servers. 66 00:05:18,140 --> 00:05:23,970 And now other users can access the servers using their private keys. 67 00:05:24,200 --> 00:05:27,210 Let's go back to our Web server example. 68 00:05:27,290 --> 00:05:34,700 You see the problem we had earlier with symmetric encryption was that the key used to encrypt data had 69 00:05:34,700 --> 00:05:39,900 to be sent to the server over the network along with the encrypted data. 70 00:05:39,960 --> 00:05:45,640 And so there is a risk of the hacker getting the key to decrypt the data. 71 00:05:45,670 --> 00:05:50,260 What if we could somehow get the key to the server safely. 72 00:05:50,290 --> 00:05:56,530 Once the key is safely made available to the server the server and client can safely continue communication 73 00:05:56,530 --> 00:06:03,790 with each other using symmetric encryption to securely transfer the symmetric key from the client to 74 00:06:03,790 --> 00:06:10,620 the server, we use Asymmetric Encryption. So, we generate a public and private key pair on the server. 75 00:06:10,720 --> 00:06:17,500 We're going to refer to the public lock as public key going forward now that you have got the idea that 76 00:06:17,530 --> 00:06:24,360 The ssh-keygen command we used earlier creates a pair of keys for SSH purposes. 77 00:06:24,360 --> 00:06:26,280 So the format is a bit different. 78 00:06:26,530 --> 00:06:35,000 Here we use the openssl command to generate a private and public key pair. And that’s how they look. 79 00:06:37,390 --> 00:06:44,620 When the user first accesses the web server using https, he gets the public key from the server. 80 00:06:44,620 --> 00:06:51,360 Since the hacker is sniffing all traffic that is assumed he too gets a copy of the public key. 81 00:06:51,490 --> 00:06:52,900 We'll see what he can do with it. 82 00:06:54,020 --> 00:06:54,770 The user. 83 00:06:54,770 --> 00:07:00,980 In fact the user's browser then encrypts the symmetric key using the public key provided by the server. 84 00:07:02,070 --> 00:07:08,380 The symmetric key is now secure the user then sends this to the server. 85 00:07:08,390 --> 00:07:14,900 The hacker also gets a copy the server uses the private key to decrypt the message and retrieve the 86 00:07:14,900 --> 00:07:15,970 symmetric key from it. 87 00:07:16,310 --> 00:07:22,070 However the hacker does not have the private key to decrypt and retrieve the symmetric key from the 88 00:07:22,070 --> 00:07:29,450 message it received the hacker only has the public key with which he can only lock or encrypt a message 89 00:07:29,570 --> 00:07:36,910 and not decrypt the message the symmetric key is now safely available only to the user and the server 90 00:07:37,340 --> 00:07:44,980 they can now use the symmetric key to encrypt data and sent to each other the receiver can use the same 91 00:07:44,980 --> 00:07:49,450 symmetric key to decrypt data and retrieve information. 92 00:07:49,450 --> 00:07:58,000 The hacker is left with the encrypted messages and public keys with which he can decrypt any data with 93 00:07:58,030 --> 00:07:59,610 asymmetric encryption. 94 00:07:59,620 --> 00:08:05,290 We have successfully transferred the symmetric keys from the user to the server and what's symmetric 95 00:08:05,290 --> 00:08:06,290 encryption. 96 00:08:06,340 --> 00:08:09,900 We have secured all future communication between them. 97 00:08:10,060 --> 00:08:17,760 Perfect the hacker now looks for new ways to hack into our account and so he realizes that the only 98 00:08:17,760 --> 00:08:23,990 way he can get your credential is by getting you to type it into a form he presents. 99 00:08:24,020 --> 00:08:28,750 So he creates a Web site that looks exactly like your bank's web site. 100 00:08:28,770 --> 00:08:30,000 The design is the same. 101 00:08:30,000 --> 00:08:31,230 The graphics are the same. 102 00:08:31,230 --> 00:08:35,470 The Web site is a replica of the actual bank's Web site. 103 00:08:35,520 --> 00:08:38,780 He hosts the website on his own server. 104 00:08:38,820 --> 00:08:41,080 He wants you to think it's secure too. 105 00:08:41,100 --> 00:08:47,100 So he generates his own set of public and private key pairs and configure them on his web server. 106 00:08:48,600 --> 00:08:56,040 And finally he somehow manages to tweak your environment or your network to route your requests going 107 00:08:56,040 --> 00:09:00,030 to your bank's web site to his servers. 108 00:09:00,030 --> 00:09:05,850 When you open up your browser and type the website address in you see a very familiar page the same 109 00:09:05,850 --> 00:09:08,700 login page of your bank that you're used to seeing. 110 00:09:08,720 --> 00:09:15,120 So you go ahead and type in the username and password. You made sure you typed in HTTPS in 111 00:09:15,120 --> 00:09:21,990 the URL to make sure that communication is secure encrypted your browser receives the key you send encrypted 112 00:09:21,990 --> 00:09:28,050 symmetric key and then you send your credentials encrypted with the key and the receiver decrypt the 113 00:09:28,050 --> 00:09:34,830 credentials with the same symmetric key you've been communicating securely in an encrypted manner but 114 00:09:34,830 --> 00:09:40,770 with the hackers server. As soon as you send in your credentials, you see a dashboard that doesn’t look 115 00:09:40,770 --> 00:09:44,170 very much like your bank's dashboard. 116 00:09:44,320 --> 00:09:50,500 What if you could look at the key you received from the server and see if it is a legitimate key from 117 00:09:50,500 --> 00:09:56,430 the real bank server when the server since the key it does not send the key alone. 118 00:09:56,590 --> 00:09:59,610 It sends a certificate that has the key in it. 119 00:10:00,160 --> 00:10:05,010 If you take a closer look at the certificate you will see that it is like an actual certificate. 120 00:10:05,080 --> 00:10:12,160 But in a digital format it has information about who the certificate is issued to the public key of 121 00:10:12,160 --> 00:10:19,080 that server the location of that server etc. on the right you see the output of an actual certificate 122 00:10:19,690 --> 00:10:25,440 every certificate has a name on it the person or subject to whom the certificate is issued to. 123 00:10:25,480 --> 00:10:30,740 That is very important as that is the field that helps you validate their identity. 124 00:10:30,910 --> 00:10:37,680 If this is for a web server this must match what the user types in the you are on his browser. 125 00:10:37,750 --> 00:10:43,930 If the bank is known by any other names and if they like their users to access their application with 126 00:10:43,930 --> 00:10:50,530 the other names as well then all those names should be specified in the certificate under the subject 127 00:10:50,690 --> 00:10:52,690 alternative name section. 128 00:10:52,860 --> 00:10:55,880 But you see anyone can generate a certificate like this. 129 00:10:55,990 --> 00:11:01,590 You could generate one for yourself saying you're Google and that's what the hacker did in this case. 130 00:11:01,660 --> 00:11:06,210 He generated a certificate saying he is your bank's web site. 131 00:11:06,310 --> 00:11:09,940 So how do you look at a certificate and verify if it is legit. 132 00:11:09,970 --> 00:11:15,700 That is where the most important part of the certificate comes into play who's signed and issued the 133 00:11:15,700 --> 00:11:16,940 certificate. 134 00:11:17,050 --> 00:11:21,260 If you generate the certificate then you will have to sign it by yourself. 135 00:11:21,340 --> 00:11:24,190 That is known as a self signed certificate. 136 00:11:24,190 --> 00:11:30,130 Anyone looking at the certificate you generated will immediately know that it is not a safe certificate 137 00:11:30,280 --> 00:11:36,740 because you have signed if you looked at the certificate you received from the hacker closely you would 138 00:11:36,740 --> 00:11:41,790 have noticed that it was a fake certificate that was signed by the hacker himself. 139 00:11:41,900 --> 00:11:45,940 As a matter of fact your browser does that for you. 140 00:11:46,100 --> 00:11:52,340 All of the web browsers are built in with a Certificate validation mechanism, wherein the browser checks 141 00:11:52,340 --> 00:11:59,190 the certificate received from the server and validates it to make sure it is legitimate if it identifies 142 00:11:59,190 --> 00:12:03,540 it to be a fake certificate then it actually warns you. 143 00:12:03,540 --> 00:12:10,200 So then how do you create a legitimate certificate for your web servers that the web browsers will trust. 144 00:12:10,230 --> 00:12:14,610 How do you get your certificates signed by someone with authority. 145 00:12:14,790 --> 00:12:21,390 That’s where Certificate Authorities or CAs comes in. They are well known organizations that can sign 146 00:12:21,390 --> 00:12:23,860 and validate your certificates for you. 147 00:12:23,940 --> 00:12:30,440 Some of the popular ones are Symantec, Digicert, Comodo, GlobalSign etc. 148 00:12:30,690 --> 00:12:36,840 The way this works is you generate a certificate signing a request or CSR using the key you generated 149 00:12:36,870 --> 00:12:39,650 earlier and the domain name of your Web site. 150 00:12:39,780 --> 00:12:43,040 You can do this again using the open SSL command. 151 00:12:43,200 --> 00:12:49,470 This generates a my-bank.csr file which is the certificate signing request that should be 152 00:12:49,470 --> 00:12:51,630 sent to the CA for signing. 153 00:12:51,780 --> 00:12:58,970 It looks like this the certificate authorities verify your details and once it checks out they sign 154 00:12:58,970 --> 00:13:02,000 the certificate and send it back to you. 155 00:13:02,030 --> 00:13:09,500 You now have a certificate signed by a CA that the process trust if hacker tried to get his certificate 156 00:13:09,500 --> 00:13:15,530 signed the same way he would fail during the validation phase and his certificate would be rejected 157 00:13:15,530 --> 00:13:16,220 by the CA. 158 00:13:17,000 --> 00:13:21,050 So the Web site that he's hosting won't have a valid certificate. 159 00:13:21,050 --> 00:13:26,220 The CAs use different techniques to make sure that you are the actual owner of that domain. 160 00:13:27,070 --> 00:13:30,860 You now have a certificate signed by CA that the browser is trust. 161 00:13:31,510 --> 00:13:35,230 But how do the browsers know that the CA itself was legitimate. 162 00:13:35,320 --> 00:13:39,100 For example what if the certificate was signed by a fake CA. 163 00:13:39,190 --> 00:13:42,980 In this case our certificate was signed by Symantec. 164 00:13:43,090 --> 00:13:49,870 How would the browser know Symantec is a valid CA and that the certificate was infact signed by Symantec 165 00:13:49,960 --> 00:13:57,260 and not by someone who says they are semantec. The CA is themselves have a set of public and private 166 00:13:57,260 --> 00:13:58,380 key pairs. 167 00:13:58,700 --> 00:14:05,550 The CA is use their private keys to sign the certificates the public keys of all the CAs are built in to 168 00:14:05,570 --> 00:14:11,720 the browsers. The browser uses the public key of the CA to validate that the certificate was actually 169 00:14:11,720 --> 00:14:13,700 signed by the CA themselves. 170 00:14:13,700 --> 00:14:19,310 You can actually see them in the settings of your web browser, under certificates. They are under trusted 171 00:14:19,360 --> 00:14:21,540 CAs tab. 172 00:14:21,560 --> 00:14:28,350 Now these are public CAs that help us ensure the public websites we visit, like our banks, email etc 173 00:14:28,410 --> 00:14:29,150 are legitimate. 174 00:14:29,940 --> 00:14:35,490 However they don't help you validate sites hosted privately say within your organization. 175 00:14:35,490 --> 00:14:42,210 For example, for accessing your payroll or internal email applications. For that you can host your own 176 00:14:42,270 --> 00:14:43,600 private CAs. 177 00:14:43,950 --> 00:14:49,710 Most of these companies listed here have a private offering of their services. A CA server that 178 00:14:49,770 --> 00:14:52,860 you can deploy internally within your company. 179 00:14:52,980 --> 00:14:58,470 You can then have the public key of your internal CA server installed on all your employees browsers 180 00:14:58,560 --> 00:15:05,480 and establish secure connectivity within your organization so let's summarize real quick. 181 00:15:05,600 --> 00:15:11,790 We have seen why you may want to encrypt messages being sent over a network to encrypt messages. 182 00:15:11,790 --> 00:15:18,540 We use asymmetric encryption with a pair of public and private keys and admin uses a pair of keys to 183 00:15:18,540 --> 00:15:26,180 secure SSH connectivity to the servers. The server uses a pair of keys to secure HTTPS traffic. 184 00:15:26,380 --> 00:15:30,640 For this the server first sends a certificate signing request to a CA. 185 00:15:30,850 --> 00:15:34,090 The CA uses its private key to sign the CSR. 186 00:15:34,120 --> 00:15:37,900 Remember all users have a copy of the CAs public key. 187 00:15:38,020 --> 00:15:43,480 The signed certificate is then sent back to the server the server configure is the web application with 188 00:15:43,480 --> 00:15:45,170 the signed certificate. 189 00:15:45,190 --> 00:15:50,770 Whenever a user accesses the web application the server first sends the certificate with its public 190 00:15:50,770 --> 00:15:51,580 key. 191 00:15:51,730 --> 00:15:58,600 The user or rather the user's browser reads the certificate and uses the CA's public key to validate 192 00:15:58,690 --> 00:15:59,860 and retrieve the servers. 193 00:15:59,860 --> 00:16:06,510 Public key it then generates a symmetric key that it wishes to use going forward for all communication. 194 00:16:06,510 --> 00:16:12,610 The symmetric key is encrypted using the server as public key and sent back to the server the server 195 00:16:12,760 --> 00:16:17,510 uses its private key to decrypt the message and retrieve the symmetric key. 196 00:16:17,690 --> 00:16:24,280 The symmetric key is used for communication going forward so the administrator generates a key pair 197 00:16:24,280 --> 00:16:25,720 for securing SSH. 198 00:16:25,990 --> 00:16:32,320 the web server generates a key pair for securing the web site with HTTPS, the Certificate Authority 199 00:16:32,320 --> 00:16:36,070 generates its own set of key pair to sign certificates. 200 00:16:36,490 --> 00:16:40,000 The end user though only generates a single symmetric key. 201 00:16:40,150 --> 00:16:45,550 Once he establishes trust with the Web site he uses his username and password to authenticate the Web 202 00:16:45,550 --> 00:16:49,250 server with the servers key pairs. 203 00:16:49,260 --> 00:16:55,650 The client was able to validate that the server is who they say they are but the server does not for 204 00:16:55,650 --> 00:16:59,310 sure know if the client is who they say they are. 205 00:16:59,400 --> 00:17:05,700 It could be a hacker impersonating a user by somehow gaining access to his credentials not over the 206 00:17:05,700 --> 00:17:06,780 network for sure. 207 00:17:06,780 --> 00:17:13,210 as we have secured it already with TLS. May be some other means. Anyway, 208 00:17:13,620 --> 00:17:20,250 So what can the server do to validate that the client is who they say they are for this as part of the 209 00:17:20,250 --> 00:17:22,650 initial trust building exercise. 210 00:17:22,650 --> 00:17:28,920 The server can request a certificate from the client and so the client must generate a pair of keys 211 00:17:29,100 --> 00:17:35,790 and a signed certificate from a valid CA the client then sends the certificate to the server for it 212 00:17:35,790 --> 00:17:40,720 to verify that the client is who they say they are. 213 00:17:40,780 --> 00:17:46,370 Now you must be thinking you have never generated a client's certificate to access a Web site. 214 00:17:46,370 --> 00:17:53,000 Well that's because TLS client certificates are not generally implemented on web servers even if 215 00:17:53,000 --> 00:17:55,540 they are it's all implemented under the hood. 216 00:17:55,550 --> 00:18:02,320 So in normal user don't have to generate and manage certificates manually so that was the final piece 217 00:18:02,320 --> 00:18:10,290 about client certificates this whole infrastructure including the CA the servers the people and the 218 00:18:10,290 --> 00:18:18,420 process of generating distributing and maintaining digital certificates is known as public key infrastructure 219 00:18:18,480 --> 00:18:26,350 or PKI finally let me clear up something before you leave I've been using the analogy of a key and 220 00:18:26,350 --> 00:18:29,130 law for private and public keys. 221 00:18:29,170 --> 00:18:35,800 If I give you the impression that only the lock or the public key can encrypt data then please forgive 222 00:18:35,800 --> 00:18:37,660 me as it's not true. 223 00:18:37,750 --> 00:18:42,510 These are in fact two related or paired keys. 224 00:18:42,580 --> 00:18:48,480 You can encrypt data with any one of them and only decrypt data with the other. 225 00:18:48,760 --> 00:18:54,020 You cannot encrypt data with one and decrypt with the same. 226 00:18:54,280 --> 00:18:57,640 So you must be careful what you encrypt your data with. 227 00:18:57,850 --> 00:19:04,060 If encrypted data with your private key then remember anyone with your public key which could really 228 00:19:04,060 --> 00:19:10,250 be anyone out there will be able to decrypt and read your message. 229 00:19:10,260 --> 00:19:18,390 Finally, a quick note on naming convention. Usually certificates with Public key are named crt or pem 230 00:19:18,510 --> 00:19:22,080 extension. So that’s server.crt, 231 00:19:22,080 --> 00:19:30,180 server.pem for server certificates or client.crt or client.pem for client certificates. And 232 00:19:30,180 --> 00:19:36,550 private keys are usually with extension .key, or –key.pem. 233 00:19:36,660 --> 00:19:45,930 For example server.key or server-key.pem. So just remember private keys have the word ‘key’ 234 00:19:46,170 --> 00:19:52,890 in them usually either as an extension or in the name of the certificate and one that doesn't have the 235 00:19:52,890 --> 00:19:56,580 word key in them is usually a public key or certificate. 236 00:19:57,000 --> 00:19:59,040 Well that's it for this lecture. 237 00:19:59,040 --> 00:20:00,490 Thank you for watching. 238 00:20:00,550 --> 00:20:02,370 I will see you in the next lecture.