WEBVTT 00:01.140 --> 00:06.120 Hello and welcome to this video on understanding SSL TLS certificates. 00:06.120 --> 00:13.260 In this video we will look at the absolute basics of what TLS certificates are why you need them and 00:13.260 --> 00:17.940 how you can configure certificates to secure SSH or web servers. 00:19.200 --> 00:24.690 A certificate is used to guarantee trust between two parties during a transaction. 00:24.700 --> 00:31.900 For example, when a user tries to access a web server, TLS certificates ensure that the communication 00:31.930 --> 00:37.650 between the user and the server is encrypted and the server is who it says it is. 00:38.770 --> 00:43.110 Let’s take a look at a scenario. Without secure connectivity, 00:43.240 --> 00:50.080 If a user were to access his online banking application the credentials he types in would be sent in 00:50.080 --> 00:52.380 a plain text format. 00:52.380 --> 00:58.450 The hacker sniffing network traffic could easily retrieve the credentials and use it to hack into the 00:58.450 --> 01:00.600 user's bank account. 01:00.730 --> 01:02.560 Well that's obviously not safe. 01:02.720 --> 01:10.630 So you must encrypt the data being transferred using encryption keys the data is encrypted using a key 01:10.660 --> 01:17.410 which is basically a set of random numbers and alphabets you add the random number to your data and 01:17.410 --> 01:24.520 you encrypted into a format that cannot be recognized the data is then sent to the server. 01:24.580 --> 01:28.920 The hacker sniffing the network gets the data but can't do anything with it. 01:30.070 --> 01:36.880 However the same is the case with the server receiving the data it cannot decrypt that data without 01:36.880 --> 01:38.170 the key. 01:38.170 --> 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 01:45.730 --> 01:49.160 since the key is also sent over the same network. 01:49.180 --> 01:54.590 The attacker can sniff that as well and decrypt that data with it. 01:54.610 --> 01:58.000 This is known as SYMMETRIC ENCRYPTION. 01:58.120 --> 02:04.900 It is a secure way of encryption but since it uses the same key to encrypt and decrypt the data and 02:04.900 --> 02:11.050 since the key has to be exchanged between the sender and the receiver there is a risk of a hacker gaining 02:11.110 --> 02:17.520 access to the key and decrypting the data and that's where asymmetric encryption comes in. 02:18.690 --> 02:26.430 Instead of using a single key to encrypt and decrypt data asymmetric encryption uses a pair of keys 02:26.960 --> 02:31.980 a private key and a public key well they are private and public keys. 02:32.010 --> 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 02:39.470 --> 02:40.400 that at the end. 02:40.400 --> 02:46.480 But for now think of it as a key and a lock pair a key which is only with me. 02:46.480 --> 02:47.690 So it's private. 02:47.980 --> 02:50.590 A lock that anyone can access. 02:50.590 --> 02:53.840 So it's public. 02:53.860 --> 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 03:01.660 --> 03:02.710 key. 03:02.710 --> 03:07.750 So your key must always be secure with you and not be shared with anyone else. 03:07.750 --> 03:09.040 It's private. 03:09.040 --> 03:15.760 But the lock is public and may be shared with others but they can only lock something with it no matter 03:15.760 --> 03:16.480 what is locked. 03:16.470 --> 03:24.450 Using the public lock it can only be unlocked by your private key before we go back to our Web server 03:24.460 --> 03:25.180 example. 03:25.300 --> 03:32.720 let’s look at an even simpler use case of securing SSH access to servers through key pairs. You 03:32.720 --> 03:36.170 have a server in your environment that you need access to. 03:36.260 --> 03:39.820 You don't want to use passwords as they're too risky. 03:40.010 --> 03:45.730 So you decide to use key pairs you generate a public and private key pair. 03:45.890 --> 03:49.220 You can do this by running the ssh_keygen command. 03:49.250 --> 03:56.090 It creates two files. Id_rsa is the private key and id_rsa.pub 03:56.150 --> 04:00.880 is the public key. Well, not a public key, a public 04:00.890 --> 04:08.940 lock. You then secure your server by locking down all access to it, except through a door that is locked 04:09.030 --> 04:11.520 using your public lock. 04:11.580 --> 04:15.680 It's usually done by adding an entry with your public key into the servers. 04:15.720 --> 04:19.290 .ssh authorized_keys file. 04:19.520 --> 04:23.660 So you see the look is public and anyone can attempt to break through. 04:24.050 --> 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 04:30.590 --> 04:36.650 one can gain access to the server. When you try to SSH you specify the location of your private 04:36.650 --> 04:39.050 key in your SSH command. 04:39.050 --> 04:41.990 What if you have other servers in your environment. 04:41.990 --> 04:45.840 How do you secure more than one server with your key pair? 04:45.860 --> 04:51.860 Well you can create copies of your public clock and place them on as many servers as you want. 04:51.860 --> 04:57.800 You can use the same private key to SSH into all of your servers securely. 04:57.890 --> 05:02.830 What if other users need access to your servers well they can do the same thing. 05:02.870 --> 05:09.500 They can generate their own public and private key pairs as the only person who has access to those 05:09.500 --> 05:10.180 servers. 05:10.190 --> 05:16.910 You can create an additional door for them and lock it with their public locks copy their public locks 05:16.940 --> 05:18.120 to all the servers. 05:18.140 --> 05:23.970 And now other users can access the servers using their private keys. 05:24.200 --> 05:27.210 Let's go back to our Web server example. 05:27.290 --> 05:34.700 You see the problem we had earlier with symmetric encryption was that the key used to encrypt data had 05:34.700 --> 05:39.900 to be sent to the server over the network along with the encrypted data. 05:39.960 --> 05:45.640 And so there is a risk of the hacker getting the key to decrypt the data. 05:45.670 --> 05:50.260 What if we could somehow get the key to the server safely. 05:50.290 --> 05:56.530 Once the key is safely made available to the server the server and client can safely continue communication 05:56.530 --> 06:03.790 with each other using symmetric encryption to securely transfer the symmetric key from the client to 06:03.790 --> 06:10.620 the server, we use Asymmetric Encryption. So, we generate a public and private key pair on the server. 06:10.720 --> 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 06:17.530 --> 06:24.360 The ssh-keygen command we used earlier creates a pair of keys for SSH purposes. 06:24.360 --> 06:26.280 So the format is a bit different. 06:26.530 --> 06:35.000 Here we use the openssl command to generate a private and public key pair. And that’s how they look. 06:37.390 --> 06:44.620 When the user first accesses the web server using https, he gets the public key from the server. 06:44.620 --> 06:51.360 Since the hacker is sniffing all traffic that is assumed he too gets a copy of the public key. 06:51.490 --> 06:52.900 We'll see what he can do with it. 06:54.020 --> 06:54.770 The user. 06:54.770 --> 07:00.980 In fact the user's browser then encrypts the symmetric key using the public key provided by the server. 07:02.070 --> 07:08.380 The symmetric key is now secure the user then sends this to the server. 07:08.390 --> 07:14.900 The hacker also gets a copy the server uses the private key to decrypt the message and retrieve the 07:14.900 --> 07:15.970 symmetric key from it. 07:16.310 --> 07:22.070 However the hacker does not have the private key to decrypt and retrieve the symmetric key from the 07:22.070 --> 07:29.450 message it received the hacker only has the public key with which he can only lock or encrypt a message 07:29.570 --> 07:36.910 and not decrypt the message the symmetric key is now safely available only to the user and the server 07:37.340 --> 07:44.980 they can now use the symmetric key to encrypt data and sent to each other the receiver can use the same 07:44.980 --> 07:49.450 symmetric key to decrypt data and retrieve information. 07:49.450 --> 07:58.000 The hacker is left with the encrypted messages and public keys with which he can decrypt any data with 07:58.030 --> 07:59.610 asymmetric encryption. 07:59.620 --> 08:05.290 We have successfully transferred the symmetric keys from the user to the server and what's symmetric 08:05.290 --> 08:06.290 encryption. 08:06.340 --> 08:09.900 We have secured all future communication between them. 08:10.060 --> 08:17.760 Perfect the hacker now looks for new ways to hack into our account and so he realizes that the only 08:17.760 --> 08:23.990 way he can get your credential is by getting you to type it into a form he presents. 08:24.020 --> 08:28.750 So he creates a Web site that looks exactly like your bank's web site. 08:28.770 --> 08:30.000 The design is the same. 08:30.000 --> 08:31.230 The graphics are the same. 08:31.230 --> 08:35.470 The Web site is a replica of the actual bank's Web site. 08:35.520 --> 08:38.780 He hosts the website on his own server. 08:38.820 --> 08:41.080 He wants you to think it's secure too. 08:41.100 --> 08:47.100 So he generates his own set of public and private key pairs and configure them on his web server. 08:48.600 --> 08:56.040 And finally he somehow manages to tweak your environment or your network to route your requests going 08:56.040 --> 09:00.030 to your bank's web site to his servers. 09:00.030 --> 09:05.850 When you open up your browser and type the website address in you see a very familiar page the same 09:05.850 --> 09:08.700 login page of your bank that you're used to seeing. 09:08.720 --> 09:15.120 So you go ahead and type in the username and password. You made sure you typed in HTTPS in 09:15.120 --> 09:21.990 the URL to make sure that communication is secure encrypted your browser receives the key you send encrypted 09:21.990 --> 09:28.050 symmetric key and then you send your credentials encrypted with the key and the receiver decrypt the 09:28.050 --> 09:34.830 credentials with the same symmetric key you've been communicating securely in an encrypted manner but 09:34.830 --> 09:40.770 with the hackers server. As soon as you send in your credentials, you see a dashboard that doesn’t look 09:40.770 --> 09:44.170 very much like your bank's dashboard. 09:44.320 --> 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 09:50.500 --> 09:56.430 the real bank server when the server since the key it does not send the key alone. 09:56.590 --> 09:59.610 It sends a certificate that has the key in it. 10:00.160 --> 10:05.010 If you take a closer look at the certificate you will see that it is like an actual certificate. 10:05.080 --> 10:12.160 But in a digital format it has information about who the certificate is issued to the public key of 10:12.160 --> 10:19.080 that server the location of that server etc. on the right you see the output of an actual certificate 10:19.690 --> 10:25.440 every certificate has a name on it the person or subject to whom the certificate is issued to. 10:25.480 --> 10:30.740 That is very important as that is the field that helps you validate their identity. 10:30.910 --> 10:37.680 If this is for a web server this must match what the user types in the you are on his browser. 10:37.750 --> 10:43.930 If the bank is known by any other names and if they like their users to access their application with 10:43.930 --> 10:50.530 the other names as well then all those names should be specified in the certificate under the subject 10:50.690 --> 10:52.690 alternative name section. 10:52.860 --> 10:55.880 But you see anyone can generate a certificate like this. 10:55.990 --> 11:01.590 You could generate one for yourself saying you're Google and that's what the hacker did in this case. 11:01.660 --> 11:06.210 He generated a certificate saying he is your bank's web site. 11:06.310 --> 11:09.940 So how do you look at a certificate and verify if it is legit. 11:09.970 --> 11:15.700 That is where the most important part of the certificate comes into play who's signed and issued the 11:15.700 --> 11:16.940 certificate. 11:17.050 --> 11:21.260 If you generate the certificate then you will have to sign it by yourself. 11:21.340 --> 11:24.190 That is known as a self signed certificate. 11:24.190 --> 11:30.130 Anyone looking at the certificate you generated will immediately know that it is not a safe certificate 11:30.280 --> 11:36.740 because you have signed if you looked at the certificate you received from the hacker closely you would 11:36.740 --> 11:41.790 have noticed that it was a fake certificate that was signed by the hacker himself. 11:41.900 --> 11:45.940 As a matter of fact your browser does that for you. 11:46.100 --> 11:52.340 All of the web browsers are built in with a Certificate validation mechanism, wherein the browser checks 11:52.340 --> 11:59.190 the certificate received from the server and validates it to make sure it is legitimate if it identifies 11:59.190 --> 12:03.540 it to be a fake certificate then it actually warns you. 12:03.540 --> 12:10.200 So then how do you create a legitimate certificate for your web servers that the web browsers will trust. 12:10.230 --> 12:14.610 How do you get your certificates signed by someone with authority. 12:14.790 --> 12:21.390 That’s where Certificate Authorities or CAs comes in. They are well known organizations that can sign 12:21.390 --> 12:23.860 and validate your certificates for you. 12:23.940 --> 12:30.440 Some of the popular ones are Symantec, Digicert, Comodo, GlobalSign etc. 12:30.690 --> 12:36.840 The way this works is you generate a certificate signing a request or CSR using the key you generated 12:36.870 --> 12:39.650 earlier and the domain name of your Web site. 12:39.780 --> 12:43.040 You can do this again using the open SSL command. 12:43.200 --> 12:49.470 This generates a my-bank.csr file which is the certificate signing request that should be 12:49.470 --> 12:51.630 sent to the CA for signing. 12:51.780 --> 12:58.970 It looks like this the certificate authorities verify your details and once it checks out they sign 12:58.970 --> 13:02.000 the certificate and send it back to you. 13:02.030 --> 13:09.500 You now have a certificate signed by a CA that the process trust if hacker tried to get his certificate 13:09.500 --> 13:15.530 signed the same way he would fail during the validation phase and his certificate would be rejected 13:15.530 --> 13:16.220 by the CA. 13:17.000 --> 13:21.050 So the Web site that he's hosting won't have a valid certificate. 13:21.050 --> 13:26.220 The CAs use different techniques to make sure that you are the actual owner of that domain. 13:27.070 --> 13:30.860 You now have a certificate signed by CA that the browser is trust. 13:31.510 --> 13:35.230 But how do the browsers know that the CA itself was legitimate. 13:35.320 --> 13:39.100 For example what if the certificate was signed by a fake CA. 13:39.190 --> 13:42.980 In this case our certificate was signed by Symantec. 13:43.090 --> 13:49.870 How would the browser know Symantec is a valid CA and that the certificate was infact signed by Symantec 13:49.960 --> 13:57.260 and not by someone who says they are semantec. The CA is themselves have a set of public and private 13:57.260 --> 13:58.380 key pairs. 13:58.700 --> 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 14:05.570 --> 14:11.720 the browsers. The browser uses the public key of the CA to validate that the certificate was actually 14:11.720 --> 14:13.700 signed by the CA themselves. 14:13.700 --> 14:19.310 You can actually see them in the settings of your web browser, under certificates. They are under trusted 14:19.360 --> 14:21.540 CAs tab. 14:21.560 --> 14:28.350 Now these are public CAs that help us ensure the public websites we visit, like our banks, email etc 14:28.410 --> 14:29.150 are legitimate. 14:29.940 --> 14:35.490 However they don't help you validate sites hosted privately say within your organization. 14:35.490 --> 14:42.210 For example, for accessing your payroll or internal email applications. For that you can host your own 14:42.270 --> 14:43.600 private CAs. 14:43.950 --> 14:49.710 Most of these companies listed here have a private offering of their services. A CA server that 14:49.770 --> 14:52.860 you can deploy internally within your company. 14:52.980 --> 14:58.470 You can then have the public key of your internal CA server installed on all your employees browsers 14:58.560 --> 15:05.480 and establish secure connectivity within your organization so let's summarize real quick. 15:05.600 --> 15:11.790 We have seen why you may want to encrypt messages being sent over a network to encrypt messages. 15:11.790 --> 15:18.540 We use asymmetric encryption with a pair of public and private keys and admin uses a pair of keys to 15:18.540 --> 15:26.180 secure SSH connectivity to the servers. The server uses a pair of keys to secure HTTPS traffic. 15:26.380 --> 15:30.640 For this the server first sends a certificate signing request to a CA. 15:30.850 --> 15:34.090 The CA uses its private key to sign the CSR. 15:34.120 --> 15:37.900 Remember all users have a copy of the CAs public key. 15:38.020 --> 15:43.480 The signed certificate is then sent back to the server the server configure is the web application with 15:43.480 --> 15:45.170 the signed certificate. 15:45.190 --> 15:50.770 Whenever a user accesses the web application the server first sends the certificate with its public 15:50.770 --> 15:51.580 key. 15:51.730 --> 15:58.600 The user or rather the user's browser reads the certificate and uses the CA's public key to validate 15:58.690 --> 15:59.860 and retrieve the servers. 15:59.860 --> 16:06.510 Public key it then generates a symmetric key that it wishes to use going forward for all communication. 16:06.510 --> 16:12.610 The symmetric key is encrypted using the server as public key and sent back to the server the server 16:12.760 --> 16:17.510 uses its private key to decrypt the message and retrieve the symmetric key. 16:17.690 --> 16:24.280 The symmetric key is used for communication going forward so the administrator generates a key pair 16:24.280 --> 16:25.720 for securing SSH. 16:25.990 --> 16:32.320 the web server generates a key pair for securing the web site with HTTPS, the Certificate Authority 16:32.320 --> 16:36.070 generates its own set of key pair to sign certificates. 16:36.490 --> 16:40.000 The end user though only generates a single symmetric key. 16:40.150 --> 16:45.550 Once he establishes trust with the Web site he uses his username and password to authenticate the Web 16:45.550 --> 16:49.250 server with the servers key pairs. 16:49.260 --> 16:55.650 The client was able to validate that the server is who they say they are but the server does not for 16:55.650 --> 16:59.310 sure know if the client is who they say they are. 16:59.400 --> 17:05.700 It could be a hacker impersonating a user by somehow gaining access to his credentials not over the 17:05.700 --> 17:06.780 network for sure. 17:06.780 --> 17:13.210 as we have secured it already with TLS. May be some other means. Anyway, 17:13.620 --> 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 17:20.250 --> 17:22.650 initial trust building exercise. 17:22.650 --> 17:28.920 The server can request a certificate from the client and so the client must generate a pair of keys 17:29.100 --> 17:35.790 and a signed certificate from a valid CA the client then sends the certificate to the server for it 17:35.790 --> 17:40.720 to verify that the client is who they say they are. 17:40.780 --> 17:46.370 Now you must be thinking you have never generated a client's certificate to access a Web site. 17:46.370 --> 17:53.000 Well that's because TLS client certificates are not generally implemented on web servers even if 17:53.000 --> 17:55.540 they are it's all implemented under the hood. 17:55.550 --> 18:02.320 So in normal user don't have to generate and manage certificates manually so that was the final piece 18:02.320 --> 18:10.290 about client certificates this whole infrastructure including the CA the servers the people and the 18:10.290 --> 18:18.420 process of generating distributing and maintaining digital certificates is known as public key infrastructure 18:18.480 --> 18:26.350 or PKI finally let me clear up something before you leave I've been using the analogy of a key and 18:26.350 --> 18:29.130 law for private and public keys. 18:29.170 --> 18:35.800 If I give you the impression that only the lock or the public key can encrypt data then please forgive 18:35.800 --> 18:37.660 me as it's not true. 18:37.750 --> 18:42.510 These are in fact two related or paired keys. 18:42.580 --> 18:48.480 You can encrypt data with any one of them and only decrypt data with the other. 18:48.760 --> 18:54.020 You cannot encrypt data with one and decrypt with the same. 18:54.280 --> 18:57.640 So you must be careful what you encrypt your data with. 18:57.850 --> 19:04.060 If encrypted data with your private key then remember anyone with your public key which could really 19:04.060 --> 19:10.250 be anyone out there will be able to decrypt and read your message. 19:10.260 --> 19:18.390 Finally, a quick note on naming convention. Usually certificates with Public key are named crt or pem 19:18.510 --> 19:22.080 extension. So that’s server.crt, 19:22.080 --> 19:30.180 server.pem for server certificates or client.crt or client.pem for client certificates. And 19:30.180 --> 19:36.550 private keys are usually with extension .key, or –key.pem. 19:36.660 --> 19:45.930 For example server.key or server-key.pem. So just remember private keys have the word ‘key’ 19:46.170 --> 19:52.890 in them usually either as an extension or in the name of the certificate and one that doesn't have the 19:52.890 --> 19:56.580 word key in them is usually a public key or certificate. 19:57.000 --> 19:59.040 Well that's it for this lecture. 19:59.040 --> 20:00.490 Thank you for watching. 20:00.550 --> 20:02.370 I will see you in the next lecture.