WEBVTT 00:00.200 --> 00:00.770 Hey, everyone. 00:00.770 --> 00:01.670 And welcome back. 00:01.670 --> 00:08.930 Now, in today's video, we will be discussing about revoking the SSL, TLS certificates and its associated 00:08.930 --> 00:10.910 very important pointers. 00:10.940 --> 00:17.690 Now, one very important part to remember is that the secrecy of a private communication is dependent 00:17.690 --> 00:19.190 on the private key. 00:19.400 --> 00:24.080 Now, this specifically applies to the asymmetric key encryption. 00:24.080 --> 00:31.700 Now, if the web server is compromised and the private key is stolen, then attacker can decrypt the 00:31.700 --> 00:32.870 communication. 00:32.870 --> 00:37.490 So basically a web server has the private key which is stored. 00:37.490 --> 00:43.160 And if web server gets compromised because there have been a lot of cases where this has happened. 00:43.160 --> 00:50.330 So an attacker can easily steal the private key and decrypt the previous communication which he might 00:50.330 --> 00:51.320 have captured. 00:51.530 --> 00:57.470 So what happens when your private key is stolen and your web server is compromised? 00:57.590 --> 01:02.270 Then, in such cases, revocation of the certificate is recommended. 01:02.270 --> 01:04.580 So what happens in revocation of certificate? 01:04.580 --> 01:12.050 You revoke the certificate, you create a new certificate with a new private key, and you implement 01:12.050 --> 01:16.610 the new certificate and the new private key in a secured web server. 01:16.880 --> 01:23.870 So I'm in my Nginx server right now and just to verify if things are working as expected, you will 01:23.870 --> 01:27.890 see that we have a Https Labs internal.com which is working perfectly. 01:27.890 --> 01:35.000 So let's say that this server is compromised and the private key is stolen by the attacker. 01:35.000 --> 01:42.650 So now as a security person or as a DevOps or as a QA, now you know that there has been a compromise 01:42.650 --> 01:45.140 and the certificate needs to be revoked. 01:45.140 --> 01:49.880 So we had basically brought a certificate from let's encrypt. 01:49.880 --> 01:54.680 So let's look into how we can revoke the certificate based on let's encrypt. 01:54.680 --> 01:59.960 So basically the certificate revocation is typically done by the certificate authority. 01:59.960 --> 02:05.880 So in our case, we'll be using the let's encrypt tool to revoke the certificate. 02:06.360 --> 02:08.430 So let's use CERT bot. 02:08.460 --> 02:09.780 I'll say revoke. 02:10.110 --> 02:14.100 Then we'll have to supply the cert path as well as the key path. 02:14.310 --> 02:16.590 So these are the two things which are required. 02:16.590 --> 02:21.120 So in order to get that, let's open up the nginx.conf here. 02:21.120 --> 02:24.930 So you have the certificate path as well as the key path. 02:25.140 --> 02:27.390 So let's put it here. 02:27.390 --> 02:30.540 So I'll copy the certificate path. 02:33.710 --> 02:36.260 And I'll also copy the key path. 02:39.290 --> 02:42.080 All right, So let's run this command. 02:42.440 --> 02:42.980 All right. 02:42.980 --> 02:48.420 So let's quickly verify whether we had pasted things correctly. 02:48.440 --> 02:49.010 All right. 02:49.010 --> 02:49.850 We had not done it. 02:49.850 --> 02:53.390 So let's copy the key part and let me paste it. 02:53.480 --> 02:54.170 All right. 02:54.410 --> 03:01.730 So again, it is starting a new Https connection with their API server for the certificate revocation. 03:01.730 --> 03:04.100 So it says, Would you like to delete the certificate? 03:04.100 --> 03:06.340 Let me just put it as no for the time being. 03:06.350 --> 03:11.480 And now it says that congratulations, you have successfully revoked the certificate. 03:11.570 --> 03:17.870 So the certificate is revoked, although it is not deleted from the web browser, but it has been revoked. 03:17.900 --> 03:21.920 Now we already know about the CRL as well as the Ocsp. 03:22.130 --> 03:27.740 Now certain providers like let's encrypt, for example, let's encrypt does not really support Crls. 03:27.740 --> 03:31.970 However, you have Digicert which supports both CRL as well as Ocsp. 03:32.240 --> 03:37.160 So again, it depends upon the provider from which you got the certificates from. 03:37.280 --> 03:43.410 So once the certificate has been revoked, let's put the labs internal.com within the browser. 03:45.360 --> 03:49.830 So as soon as I put it, you see now it says that secure connection failed. 03:49.830 --> 03:54.810 And it says that this specific certificate has been revoked. 03:54.840 --> 03:56.940 So this is as expected. 03:56.970 --> 03:57.300 All right. 03:57.300 --> 04:01.530 So with Firefox, things seems to be working perfectly well. 04:01.650 --> 04:04.320 Now let's try it with Google Chrome. 04:04.320 --> 04:08.130 So within Google Chrome, let's put the name. 04:08.250 --> 04:14.220 And you see it did not really show that the certificate has been revoked. 04:14.220 --> 04:18.030 So in order to verify, once again, let's open up Ignito mode. 04:18.210 --> 04:19.230 I'll put it here. 04:19.230 --> 04:24.690 And even now it is not really showing that the certificate is revoked. 04:24.720 --> 04:25.770 Let's double check. 04:25.770 --> 04:26.940 Let's retry. 04:27.030 --> 04:28.860 And it does not seem to be working. 04:28.860 --> 04:35.070 So to also quickly verify, let's open up SSL labs and I'll do a SSL server test. 04:35.100 --> 04:42.660 Now let's put it as Https Labs internal.com. 04:42.660 --> 04:49.840 So it is our time to be within the recent worst, but this is just for testing. 04:54.560 --> 04:58.790 And now you see it is giving us an F, So why is it giving us an F? 04:58.820 --> 05:03.090 It basically says that the server certificate is not trusted. 05:03.110 --> 05:07.030 This is one of the primary reason it went to F. 05:07.040 --> 05:10.520 So the revocation of certificate works perfectly well. 05:10.550 --> 05:13.540 However, for Chrome, it does not seem to work. 05:13.550 --> 05:17.640 So there are certain important pointers that you need to remember here. 05:17.660 --> 05:19.160 So let's understand. 05:19.190 --> 05:27.800 Now Firefox makes use of Ocsp so it is able to quickly verify whether the certificate is valid or it 05:27.800 --> 05:28.610 is revoked. 05:28.640 --> 05:32.930 Now Chrome does not make use of Ocsp. 05:33.230 --> 05:36.440 Now Chrome even does not make use of CRL. 05:36.590 --> 05:42.110 However, what Chrome does is that Chrome has its own methods for checking the revoked certificates 05:42.110 --> 05:44.690 and it is called as the CRL sets. 05:44.720 --> 05:53.540 So what CRL set is that it basically maintains its own list of crls, which it in turn collects from 05:53.540 --> 05:56.090 various other certificate authorities. 05:56.100 --> 05:59.460 So let's say that there are five certificate authorities. 05:59.490 --> 06:03.660 Chrome collects the CRL from the five certificate authorities. 06:03.690 --> 06:10.530 It combines all of them together in a mega CRL and then it adds it within the Google Chrome. 06:10.710 --> 06:13.520 Now, there are certain advantages here. 06:13.530 --> 06:19.320 So now one of the advantages is that browser doesn't really need to contact the certificate authority 06:19.320 --> 06:24.080 itself and it can remove the performance and privacy overheads. 06:24.090 --> 06:26.520 But there is a problem with this approach. 06:26.520 --> 06:32.290 The problem is that first CRL set does not have 100% of the revoked certificates. 06:32.310 --> 06:38.310 Again, they have some kind of algorithm, but it is not 100% of all the revoked certificates here. 06:38.340 --> 06:44.400 Now the second problem here is that the CRL are not really updated instantaneously. 06:44.400 --> 06:50.730 So if a certificate is revoked, you will still see Google Chrome to be working perfectly well because 06:50.730 --> 06:53.610 it does not really make use of ocsp here. 06:53.640 --> 07:01.620 Firefox makes use of ocsp so it immediately queries the responder associated with let's encrypt in our 07:01.620 --> 07:05.310 case and it is able to figure it out that a certificate is revoked. 07:05.340 --> 07:07.620 Google Chrome does not really does that. 07:07.620 --> 07:14.550 So this is one of the reasons why you see that the revocation is broken and this is the common problem 07:14.550 --> 07:15.690 across the Internet. 07:15.690 --> 07:20.400 It's not just related to a specific, let's say, Nginx or Letsencrypt. 07:20.400 --> 07:25.690 It is a common problem that you will have to face during the certificate revocation time. 07:25.710 --> 07:30.930 Now, the problem why this happens is because all the browsers, they do not really follow a common 07:30.930 --> 07:31.610 method. 07:31.620 --> 07:38.370 So if a Firefox is making use of ocsp, Chrome does not really make use of ocsp at all. 07:38.370 --> 07:45.420 So this is like every browser has a different way of doing things and this is the reason why you will 07:45.420 --> 07:49.620 see a lot of issues specifically when you are revoking the certificate. 07:49.620 --> 07:56.520 So make sure that if you are using the certificates, make sure that the web server is secured so that 07:56.520 --> 07:59.550 the revocation does not really be a topic at all. 07:59.700 --> 08:05.160 Now the second way is you can make use of services like AWS certificate manager. 08:05.160 --> 08:07.020 So what happens in those services? 08:07.020 --> 08:12.390 That AWS certificate manager itself manages the certificate and the private key. 08:12.420 --> 08:15.050 You do not have access to the private key. 08:15.060 --> 08:21.330 So now the compromise of your web server will not really lead to compromise of the private key. 08:21.330 --> 08:24.690 So you do not really need to worry much about the revocation there. 08:25.270 --> 08:29.740 So before we conclude, this is the Sets website. 08:29.740 --> 08:37.780 So if you look over here, the Oxp and CRL checks are not generally performed by Chrome, and this is 08:37.780 --> 08:41.530 one of the reasons why you will have quite good amount of issues. 08:41.530 --> 08:47.140 Typically when you are revoking your certificates again, once your certificate is revoked and if it 08:47.140 --> 08:51.820 comes within the CRL sets, there would be certain amount of time that it will take. 08:51.850 --> 08:55.660 It is not instantaneous, so you will have to bear with that. 08:55.660 --> 09:01.690 So that's the high level overview about the revocation of certificates and also some of the caveats 09:01.690 --> 09:05.800 that you will have to face once your certificate is revoked. 09:05.800 --> 09:07.690 So with this, we'll conclude this video. 09:07.720 --> 09:11.290 I hope this video has been informative for you and look forward to see you in the next video.