WEBVTT 00:00.540 --> 00:02.790 Welcome to the Knowledge Portal Video series. 00:02.820 --> 00:09.270 In the last lecture we looked into how we can have a self-signed certificate for the Nginx based web 00:09.270 --> 00:09.960 server. 00:09.990 --> 00:13.200 Today we are going to talk about SSL termination. 00:14.580 --> 00:21.480 Now, if we look at a scenario where you have a reverse proxy and there is a upstream which is application 00:21.480 --> 00:21.990 server. 00:22.140 --> 00:28.830 Now generally we if we talk about application server like Tomcat or maybe PHP, FPM, they are not very 00:28.830 --> 00:29.880 good at. 00:30.860 --> 00:35.390 Handling the SSL based connections, it will actually slow them down. 00:35.390 --> 00:42.500 And this is one of the reasons why in the enterprise as well, there is a SSL termination which is done 00:42.500 --> 00:44.330 at the reverse proxy itself. 00:45.660 --> 00:53.070 Now in this example, this is a example.com domain where nginx is acting as a reverse proxy and there 00:53.070 --> 00:59.790 is one application server and we have a SSL based website which is Https. 01:01.150 --> 01:05.980 So generally web browser calls https example.com. 01:06.850 --> 01:10.090 And there is a SSL connection which is established. 01:10.120 --> 01:14.830 However, the SSL termination happens at the reverse proxy itself. 01:15.490 --> 01:17.470 The SSL does not. 01:18.540 --> 01:25.050 Interfere between the communication of example.com, reverse proxy and the application server. 01:25.050 --> 01:31.020 So the communication that is taking place between the reverse proxy and application server is still 01:31.050 --> 01:32.370 based on plain text. 01:33.460 --> 01:40.600 Only the communication between a web browser and the reverse proxy is happening with the SSL. 01:41.200 --> 01:46.300 And this is one of the reasons why it is called SSL termination at the reverse proxy. 01:46.630 --> 01:48.940 And this is the ideal configuration. 01:51.010 --> 01:56.140 Now, many times this is not a very viable solution. 01:56.140 --> 02:02.200 Specifically, if your application server is residing in an environment which is not fully trusted. 02:02.890 --> 02:08.650 So in this case, what happens is there are two SSL connection that happens. 02:08.890 --> 02:12.650 The first is between a client and the reverse proxy. 02:12.670 --> 02:15.940 So here the termination happens as the reverse proxy site. 02:15.970 --> 02:22.660 However, the communication between reverse proxy and the application server again happens with a second 02:22.690 --> 02:24.410 SSL based connection. 02:24.430 --> 02:30.760 So essentially what is happening over here is there are two SSL connections, one between client and 02:30.760 --> 02:35.000 reverse proxy, and the second is between reverse proxy and the application server. 02:36.040 --> 02:42.850 Now, generally, if we talk about enterprise, they will try to avoid the second SSL based. 02:43.800 --> 02:48.000 A connection because it actually slows down the overall performance. 02:48.390 --> 02:50.460 Now, whenever you have. 02:51.290 --> 02:56.000 Your applications server on the cloud, which you really don't trust. 02:56.180 --> 03:04.340 Then having a SSL termination to the upstream is a mandatory requirement specifically if you are following 03:04.340 --> 03:06.980 a PCI based compliance. 03:08.170 --> 03:15.430 Now I have a website called as Vodacom, which is basically running on a reverse proxy, so I'll show 03:15.430 --> 03:17.950 you on how exactly it works. 03:21.120 --> 03:24.110 Now I'm connected to my production server. 03:24.120 --> 03:30.480 So if I do a vim on zilveren underscore SSL dot conf. 03:30.480 --> 03:33.450 So essentially this is my configuration file. 03:33.600 --> 03:36.330 Now the server name is zalora.com. 03:36.330 --> 03:38.010 It's listening on 443. 03:38.520 --> 03:40.680 These are my certificates. 03:40.680 --> 03:43.140 So this is my certificate and this is my key. 03:44.190 --> 03:50.340 It is doing a proxy pass to the upstream server over here and this is essentially what is happening. 03:50.340 --> 03:54.300 So this is my Nginx acting as a reverse proxy. 03:54.660 --> 03:59.900 So this configuration is essentially stored in the nginx reverse proxy. 03:59.910 --> 04:07.650 So Nginx will itself terminate the SSL on on the same server. 04:08.130 --> 04:14.610 However, as far as proxy pass is concerned, it is still using the Http based connection. 04:15.630 --> 04:21.780 Now if I open https say Vodacom. 04:25.770 --> 04:33.480 Essentially the website is loading and the SSL is getting terminated at the reverse proxy itself. 04:33.600 --> 04:40.680 Now, if you want to know more about this particular connection, let's go to more information. 04:40.920 --> 04:44.580 Let's view the certificate now in the common name. 04:44.580 --> 04:47.850 It is saying that this certificate is issued. 04:47.880 --> 04:54.510 This issued by Comodo and issued to Vodacom. 04:55.020 --> 05:00.270 If we go into the details here, there are multiple intermediary software. 05:00.280 --> 05:08.760 So if we look first hierarchy starts with the address external route, followed by Comodo, RSA. 05:09.060 --> 05:17.280 And there is one more over here, and this is one of the reasons why the bundle was given by the Comodo 05:17.280 --> 05:21.900 itself, because traditionally a web browser will not trust these certificates. 05:21.900 --> 05:24.990 It will only trust the root certificate. 05:24.990 --> 05:30.300 And this is one of the reasons why the CA bundle was essentially introduced. 05:31.050 --> 05:40.170 Now, one more important thing to know is if I just go to https.com by default, the browser will only 05:40.170 --> 05:42.330 show secure content. 05:42.540 --> 05:46.020 Now I have not configured my WordPress. 05:46.800 --> 05:49.230 To work on full SSL based connection. 05:49.230 --> 05:52.110 So essentially I need to unblock it. 05:55.190 --> 05:58.570 I'll say disabled protection on this page. 05:58.580 --> 06:05.810 And essentially now it will show the whole page by itself because there are many requests which are 06:05.810 --> 06:09.800 still going with the Http connection and browser. 06:09.800 --> 06:15.020 When we open Https, it will not load the Http based requests. 06:16.670 --> 06:20.780 So this is it about the SSL termination. 06:20.810 --> 06:27.590 The only thing I wanted to show here is that if you are having a reverse proxy environment, then you 06:27.590 --> 06:33.800 need to write your SSL termination at the reverse proxy based Nginx.conf. 06:34.280 --> 06:35.360 So this is it. 06:35.360 --> 06:39.080 I hope this has been informative for you and I'd like to thank you for viewing.