WEBVTT 1 00:00:00.090 --> 00:00:01.380 In this lesson, 2 00:00:01.380 --> 00:00:05.040 we will learn about Certificate Authority (CA) functions. 3 00:00:05.040 --> 00:00:07.140 Certificate Authority functions 4 00:00:07.140 --> 00:00:10.140 include issuing, managing, revoking, 5 00:00:10.140 --> 00:00:12.720 and validating digital certificates 6 00:00:12.720 --> 00:00:15.570 to ensure trust in communications. 7 00:00:15.570 --> 00:00:19.020 Applying Certificate Authority function concepts 8 00:00:19.020 --> 00:00:22.470 requires a good understanding of Certificate Authorities 9 00:00:22.470 --> 00:00:24.420 and Registration Authorities. 10 00:00:24.420 --> 00:00:26.820 Certificate Authorities or CAs 11 00:00:26.820 --> 00:00:30.060 are trusted entities responsible for generating 12 00:00:30.060 --> 00:00:32.520 and signing digital certificates, 13 00:00:32.520 --> 00:00:36.390 thereby establishing the identity of certificate holders 14 00:00:36.390 --> 00:00:40.740 within the Public Key Infrastructure or PKI framework. 15 00:00:40.740 --> 00:00:44.010 Next, Registration Authorities or RAs 16 00:00:44.010 --> 00:00:47.310 act as intermediaries between the end users 17 00:00:47.310 --> 00:00:49.770 and the certificate authorities. 18 00:00:49.770 --> 00:00:52.470 Let's learn more about Certificate Authorities 19 00:00:52.470 --> 00:00:54.210 and Registration Authorities, 20 00:00:54.210 --> 00:00:56.370 and then do a quick demonstration. 21 00:00:56.370 --> 00:00:59.250 First, we have Certificate Authorities. 22 00:00:59.250 --> 00:01:01.830 A Certificate Authority or CA 23 00:01:01.830 --> 00:01:04.560 is the entity responsible for issuing 24 00:01:04.560 --> 00:01:07.050 and verifying digital certificates 25 00:01:07.050 --> 00:01:09.390 within a Public Key Infrastructure. 26 00:01:09.390 --> 00:01:13.260 A Certificate Authority acts as a trusted third party 27 00:01:13.260 --> 00:01:16.230 that guarantees the identities of subjects 28 00:01:16.230 --> 00:01:19.260 by issuing digitally signed certificates 29 00:01:19.260 --> 00:01:22.260 that bind public keys to entities. 30 00:01:22.260 --> 00:01:26.760 This process enables authentication between two parties. 31 00:01:26.760 --> 00:01:30.240 For example, if you trust a Certificate Authority 32 00:01:30.240 --> 00:01:32.760 and I trust a Certificate Authority, 33 00:01:32.760 --> 00:01:34.470 then we can trust each other 34 00:01:34.470 --> 00:01:37.440 because the Certificate Authority that we both trust 35 00:01:37.440 --> 00:01:39.930 has validated both of our identities 36 00:01:39.930 --> 00:01:42.090 and signed our public keys. 37 00:01:42.090 --> 00:01:45.780 This is similar to the transitive property in mathematics 38 00:01:45.780 --> 00:01:48.240 where trust in a third party 39 00:01:48.240 --> 00:01:50.760 enables trust between two entities. 40 00:01:50.760 --> 00:01:54.060 For example, if A is equal to B, 41 00:01:54.060 --> 00:01:59.010 and B is equal to C, then A must also be equal to C. 42 00:01:59.010 --> 00:02:03.120 Certificate Authorities can be either public or private. 43 00:02:03.120 --> 00:02:05.610 Large organizations often establish 44 00:02:05.610 --> 00:02:08.670 private Certificate Authorities of their own 45 00:02:08.670 --> 00:02:11.400 to manage internal communications, 46 00:02:11.400 --> 00:02:13.770 and they do that by creating public 47 00:02:13.770 --> 00:02:16.170 and private key pairs for employees 48 00:02:16.170 --> 00:02:20.730 to securely send and receive signed and encrypted emails. 49 00:02:20.730 --> 00:02:24.450 The main challenge with a private Certificate Authority 50 00:02:24.450 --> 00:02:27.450 is ensuring that all users recognize 51 00:02:27.450 --> 00:02:30.480 and trust that private Certificate Authority, 52 00:02:30.480 --> 00:02:33.780 which is typically managed within an organization 53 00:02:33.780 --> 00:02:35.910 through group policies. 54 00:02:35.910 --> 00:02:40.230 For broader automatic trust across devices and browsers, 55 00:02:40.230 --> 00:02:43.320 public Certificate Authorities such as Verisign, 56 00:02:43.320 --> 00:02:46.575 Let's Encrypt, IdenTrust, DigiCert, 57 00:02:46.575 --> 00:02:50.100 Comodo and GlobalSign are widely recognized 58 00:02:50.100 --> 00:02:51.960 and trusted by default. 59 00:02:51.960 --> 00:02:53.520 Purchasing a certificate 60 00:02:53.520 --> 00:02:55.770 from a public Certificate Authority 61 00:02:55.770 --> 00:02:58.440 ensures that your identity is verified 62 00:02:58.440 --> 00:03:00.240 and trusted by others. 63 00:03:00.240 --> 00:03:03.510 Certificate Authorities perform five key functions 64 00:03:03.510 --> 00:03:05.880 to maintain security and trust 65 00:03:05.880 --> 00:03:08.460 within the Public Key Infrastructure. 66 00:03:08.460 --> 00:03:11.430 First, they provide certificate services 67 00:03:11.430 --> 00:03:15.360 to users by issuing and managing certificates. 68 00:03:15.360 --> 00:03:19.290 Second, Certificate Authorities validate certificates 69 00:03:19.290 --> 00:03:23.160 and verify the identities of applicants requesting them. 70 00:03:23.160 --> 00:03:26.070 Third, they establish and maintain trust 71 00:03:26.070 --> 00:03:30.210 with users, regulatory bodies and enterprises. 72 00:03:30.210 --> 00:03:33.630 Fourth, Certificate Authorities manage the servers 73 00:03:33.630 --> 00:03:37.920 and repositories that store and administer certificates. 74 00:03:37.920 --> 00:03:41.850 Fifth, and last, Certificate Authorities oversee 75 00:03:41.850 --> 00:03:44.400 the entire certificate lifecycle 76 00:03:44.400 --> 00:03:46.770 from issuance to revocation, 77 00:03:46.770 --> 00:03:50.850 ensuring certificates remain secure and up to date. 78 00:03:50.850 --> 00:03:53.670 To handle the significant responsibilities 79 00:03:53.670 --> 00:03:55.800 of running a Certificate Authority, 80 00:03:55.800 --> 00:03:58.320 especially in large scale environments, 81 00:03:58.320 --> 00:04:01.080 organizations often create subordinate 82 00:04:01.080 --> 00:04:03.360 or intermediate Certificate Authorities 83 00:04:03.360 --> 00:04:06.240 underneath the main Certificate Authority. 84 00:04:06.240 --> 00:04:08.250 The main Certificate Authority, 85 00:04:08.250 --> 00:04:11.460 also known as the Root Certificate Authority, 86 00:04:11.460 --> 00:04:14.880 sits at the top of a hierarchical structure 87 00:04:14.880 --> 00:04:18.990 and is the foundation of trust for the entire system. 88 00:04:18.990 --> 00:04:21.060 The Root Certificate Authority 89 00:04:21.060 --> 00:04:24.810 issues certificates to intermediate Certificate Authorities, 90 00:04:24.810 --> 00:04:28.230 which then issue certificates to end entities, 91 00:04:28.230 --> 00:04:30.600 also called Leaf certificates. 92 00:04:30.600 --> 00:04:34.980 For example, a Root Certificate Authority for the military, 93 00:04:34.980 --> 00:04:37.860 might have intermediate Certificate Authorities 94 00:04:37.860 --> 00:04:41.370 for the Air Force, army, Marines, and Navy, 95 00:04:41.370 --> 00:04:44.130 each responsible for issuing certificates 96 00:04:44.130 --> 00:04:46.110 to their respective members. 97 00:04:46.110 --> 00:04:49.230 In this setup, if an Air Force member wants 98 00:04:49.230 --> 00:04:52.050 to communicate securely with a Navy member, 99 00:04:52.050 --> 00:04:53.550 the trust is established 100 00:04:53.550 --> 00:04:56.910 because both of their certificates can be traced back 101 00:04:56.910 --> 00:04:58.920 through their respective intermediate 102 00:04:58.920 --> 00:05:00.330 Certificate Authorities, 103 00:05:00.330 --> 00:05:03.240 to the Common Root Certificate Authority. 104 00:05:03.240 --> 00:05:05.310 This hierarchal structure, 105 00:05:05.310 --> 00:05:07.710 known as Certificate Chaining, 106 00:05:07.710 --> 00:05:09.480 or the Chain of Trust, 107 00:05:09.480 --> 00:05:12.300 ensures that each certificate's validity 108 00:05:12.300 --> 00:05:16.290 is traced back to the trusted Root Certificate Authority 109 00:05:16.290 --> 00:05:19.470 through intermediate Certificate Authorities. 110 00:05:19.470 --> 00:05:23.040 This trust between different branches of the military 111 00:05:23.040 --> 00:05:26.850 helps manage the workload of the Root Certificate Authority 112 00:05:26.850 --> 00:05:28.980 and enhances security across 113 00:05:28.980 --> 00:05:32.580 the entire Public Key Infrastructure system. 114 00:05:32.580 --> 00:05:35.550 Second, we have Registration Authorities. 115 00:05:35.550 --> 00:05:38.370 A Registration Authority or RA 116 00:05:38.370 --> 00:05:40.980 is responsible for accepting requests 117 00:05:40.980 --> 00:05:42.810 for digital certificates, 118 00:05:42.810 --> 00:05:45.030 and performing additional steps 119 00:05:45.030 --> 00:05:48.180 to validate the requester's authorization 120 00:05:48.180 --> 00:05:49.980 to make that request. 121 00:05:49.980 --> 00:05:54.240 For instance, if you try to request a digital certificate 122 00:05:54.240 --> 00:05:58.560 for a domain you do not own, like diontraining.com, 123 00:05:58.560 --> 00:06:02.070 the Registration Authority would deny your request 124 00:06:02.070 --> 00:06:05.610 because you cannot prove ownership of that domain. 125 00:06:05.610 --> 00:06:08.760 In this way, the Registration Authority acts 126 00:06:08.760 --> 00:06:12.060 as the entry point for all certificate requests 127 00:06:12.060 --> 00:06:14.370 in a Public Key Infrastructure. 128 00:06:14.370 --> 00:06:17.190 So, to request a new certificate, 129 00:06:17.190 --> 00:06:21.660 you would generate a Certificate Signing Request or a CSR. 130 00:06:21.660 --> 00:06:26.010 A CSR is a Base64-encoded ASCII file 131 00:06:26.010 --> 00:06:28.830 that you send to the Certificate Authority 132 00:06:28.830 --> 00:06:30.330 to get a certificate, 133 00:06:30.330 --> 00:06:32.610 and it contains the details needed 134 00:06:32.610 --> 00:06:34.260 by the Certificate Authority 135 00:06:34.260 --> 00:06:38.460 to create the certificate and sign your public key. 136 00:06:38.460 --> 00:06:41.520 For example, when requesting a certificate 137 00:06:41.520 --> 00:06:45.150 for a web server, you will include three main groups 138 00:06:45.150 --> 00:06:48.840 of data in the Certificate Signing Request, 139 00:06:48.840 --> 00:06:51.270 your organization's information, 140 00:06:51.270 --> 00:06:53.370 the public key to be signed, 141 00:06:53.370 --> 00:06:56.760 and details about the key type and length. 142 00:06:56.760 --> 00:07:00.030 The organizational information includes fields 143 00:07:00.030 --> 00:07:02.400 like the Common Name or CN, 144 00:07:02.400 --> 00:07:06.300 which is the fully qualified domain name of your server, 145 00:07:06.300 --> 00:07:11.010 such as www.diontraining.com. 146 00:07:11.010 --> 00:07:15.450 Another field is the Subject Alternative Name or SAN, 147 00:07:15.450 --> 00:07:19.200 which allows you to include additional domain names 148 00:07:19.200 --> 00:07:23.760 that the certificate can cover, such as diontraining.net 149 00:07:23.760 --> 00:07:26.190 or diontraining.org. 150 00:07:26.190 --> 00:07:30.270 Certificates that use SAN or Subject Alternative Names 151 00:07:30.270 --> 00:07:33.750 are often called multi-domain certificates 152 00:07:33.750 --> 00:07:37.500 because they can support multiple domain names. 153 00:07:37.500 --> 00:07:40.050 The Organization or O field, 154 00:07:40.050 --> 00:07:43.140 contains the legal name of your organization 155 00:07:43.140 --> 00:07:47.070 such as Dion Training Solutions LLC. 156 00:07:47.070 --> 00:07:50.430 The Organizational Unit or OU field, 157 00:07:50.430 --> 00:07:53.280 can specify a division or department 158 00:07:53.280 --> 00:07:55.530 within your organization. 159 00:07:55.530 --> 00:07:59.070 For example, if I were creating a certificate 160 00:07:59.070 --> 00:08:02.220 for email use, I might list instructors 161 00:08:02.220 --> 00:08:05.130 as the department within Dion Training. 162 00:08:05.130 --> 00:08:08.520 Next, the city or Locality or L field 163 00:08:08.520 --> 00:08:11.520 describes the location of your organization 164 00:08:11.520 --> 00:08:14.010 while the State region or S field 165 00:08:14.010 --> 00:08:18.240 provides the state or region your organization is from. 166 00:08:18.240 --> 00:08:21.900 Finally, the Country or C field lists the country 167 00:08:21.900 --> 00:08:25.170 of operation, such as the United States. 168 00:08:25.170 --> 00:08:29.100 The second group of data in a Certificate Signing Request 169 00:08:29.100 --> 00:08:31.260 is the requester's public key, 170 00:08:31.260 --> 00:08:34.200 which will be included in the final certificate. 171 00:08:34.200 --> 00:08:36.960 The Certificate Authority uses the public key 172 00:08:36.960 --> 00:08:38.970 provided in the request, 173 00:08:38.970 --> 00:08:42.990 and endorses it as part of the validation process. 174 00:08:42.990 --> 00:08:45.420 The third group includes information 175 00:08:45.420 --> 00:08:47.670 about the key length and type. 176 00:08:47.670 --> 00:08:51.570 For example, the Dion Training Solutions LLC 177 00:08:51.570 --> 00:08:55.530 web servers public key, uses RSA encryption 178 00:08:55.530 --> 00:08:58.950 with a 2048 bit key, which is common 179 00:08:58.950 --> 00:09:00.780 for most modern websites. 180 00:09:00.780 --> 00:09:02.250 Now, let's do a demo 181 00:09:02.250 --> 00:09:05.250 and create a Certificate Signing Request. 182 00:09:05.250 --> 00:09:06.930 For this demonstration, 183 00:09:06.930 --> 00:09:10.680 we will use Open SSL on a Cali Linux machine 184 00:09:10.680 --> 00:09:14.010 to show how Dion Training Solutions LLC 185 00:09:14.010 --> 00:09:16.530 requests a web server certificate 186 00:09:16.530 --> 00:09:18.690 from a Certificate Authority called 187 00:09:18.690 --> 00:09:20.760 Totally Trusted CA. 188 00:09:20.760 --> 00:09:23.430 At the start, Dion Training Solutions 189 00:09:23.430 --> 00:09:27.000 does not initially have a public and private key pair, 190 00:09:27.000 --> 00:09:29.130 while Totally Trusted CA already 191 00:09:29.130 --> 00:09:33.120 has its own CA certificate and private key. 192 00:09:33.120 --> 00:09:36.660 During the demonstration, our perspective will start 193 00:09:36.660 --> 00:09:39.840 as that of Dion Training Solutions LLC, 194 00:09:39.840 --> 00:09:42.630 to create and submit the CSR, 195 00:09:42.630 --> 00:09:44.610 or Certificate Signing Request, 196 00:09:44.610 --> 00:09:47.460 and then to process the certificate, 197 00:09:47.460 --> 00:09:51.813 our perspective will shift to that of Totally Trusted CA. 198 00:09:52.680 --> 00:09:55.710 Okay, step one in our process is 199 00:09:55.710 --> 00:09:57.930 to generate a private key 200 00:09:57.930 --> 00:10:01.260 for Dion Training Solutions LLC. 201 00:10:01.260 --> 00:10:04.410 This key will be used in the CSR 202 00:10:04.410 --> 00:10:08.493 or Certificate Signing Request, and should be kept secure. 203 00:10:09.570 --> 00:10:14.463 We'll create this key with this Open SSL command. 204 00:10:16.110 --> 00:10:20.190 This creates a 2048 bit private key 205 00:10:20.190 --> 00:10:24.093 named diontraining_private.key. 206 00:10:25.440 --> 00:10:29.700 Step two, is to generate the Certificate Signing Request 207 00:10:29.700 --> 00:10:34.320 using the diontraining_private.key. 208 00:10:34.320 --> 00:10:37.530 The Certificate Signing Request will include details 209 00:10:37.530 --> 00:10:41.820 about our organization and our public key. 210 00:10:41.820 --> 00:10:45.093 We'll do that with this Open SSL command. 211 00:10:47.610 --> 00:10:50.460 When we run this command, we're prompted to enter 212 00:10:50.460 --> 00:10:54.660 in information about Dion Training Solutions LLC. 213 00:10:54.660 --> 00:10:59.640 In this case, we'll enter our two letter country code as US, 214 00:10:59.640 --> 00:11:03.420 our state or province name as Florida, 215 00:11:03.420 --> 00:11:06.003 our locality name as Orlando, 216 00:11:06.960 --> 00:11:09.850 our organization name as Dion Training 217 00:11:11.130 --> 00:11:15.360 Solutions, LLC, 218 00:11:15.360 --> 00:11:19.083 our organizational unit name as Instructors, 219 00:11:20.160 --> 00:11:24.663 our common name as www.diontraining.com, 220 00:11:25.680 --> 00:11:30.250 our email address as administrator@diontraining.com. 221 00:11:36.450 --> 00:11:39.120 Optional fields like the challenge password 222 00:11:39.120 --> 00:11:41.070 and optional company name, 223 00:11:41.070 --> 00:11:43.773 will be left blank by pressing Enter. 224 00:11:44.970 --> 00:11:48.780 So we've created our Certificate Signing Request. 225 00:11:48.780 --> 00:11:51.750 Step three is verifying the content 226 00:11:51.750 --> 00:11:53.760 of the Certificate Signing Request 227 00:11:53.760 --> 00:11:55.143 that we've just created. 228 00:11:56.250 --> 00:12:01.233 We'll do this by using the following Open SSL command. 229 00:12:02.400 --> 00:12:04.710 This command displays the content 230 00:12:04.710 --> 00:12:06.870 of the Certificate Signing Request 231 00:12:06.870 --> 00:12:09.090 in a human readable format, 232 00:12:09.090 --> 00:12:11.280 showing the details we entered 233 00:12:11.280 --> 00:12:14.880 along with our Public Key Information. 234 00:12:14.880 --> 00:12:18.810 Step four is sending our Certificate Signing Request 235 00:12:18.810 --> 00:12:21.180 to the Certificate Authority. 236 00:12:21.180 --> 00:12:24.270 This is typically done through a web interface, 237 00:12:24.270 --> 00:12:27.120 email, or another secure method. 238 00:12:27.120 --> 00:12:29.070 For demonstration purposes, 239 00:12:29.070 --> 00:12:32.640 we'll simulate that this step is already complete. 240 00:12:32.640 --> 00:12:34.620 Now, in our demonstration, 241 00:12:34.620 --> 00:12:36.660 we're going to assume the identity 242 00:12:36.660 --> 00:12:38.610 of the Certificate Authority 243 00:12:38.610 --> 00:12:41.670 who's just received a Certificate Signing Request 244 00:12:41.670 --> 00:12:45.720 from a company called Dion Training Solutions LLC. 245 00:12:45.720 --> 00:12:49.470 Step one in our Certificate Authority process 246 00:12:49.470 --> 00:12:53.610 is to validate the Certificate Signing Request information. 247 00:12:53.610 --> 00:12:55.380 This will involve verifying 248 00:12:55.380 --> 00:12:58.230 that Dion Training Solutions LLC 249 00:12:58.230 --> 00:13:03.230 owns the domain www.diontraining.com, 250 00:13:03.750 --> 00:13:07.110 and that the organization's details align 251 00:13:07.110 --> 00:13:08.730 with official records. 252 00:13:08.730 --> 00:13:12.030 The depth and thoroughness of these validation checks 253 00:13:12.030 --> 00:13:14.250 will depend on the type of certificate 254 00:13:14.250 --> 00:13:15.513 that has been requested. 255 00:13:16.680 --> 00:13:19.500 Let's assume that all that has been done. 256 00:13:19.500 --> 00:13:22.350 Now having validated the request, 257 00:13:22.350 --> 00:13:24.083 we're going to move on to our 258 00:13:24.083 --> 00:13:26.683 Certificate Authority step two, 259 00:13:26.683 --> 00:13:31.560 creating the Dion Training Solutions LLC digital certificate 260 00:13:31.560 --> 00:13:36.000 and signing it with our Certificate Authority private key. 261 00:13:36.000 --> 00:13:40.983 We'll do this with one long command, right here. 262 00:13:48.330 --> 00:13:53.330 This has created the diontraining.crt or certificate file 263 00:13:54.420 --> 00:13:58.080 that is valid for 365 days. 264 00:13:58.080 --> 00:14:01.470 Step three, is now issuing this certificate, 265 00:14:01.470 --> 00:14:06.470 diontraining.crt to Dion Training Solutions LLC. 266 00:14:06.870 --> 00:14:09.240 Then publishing that certificate 267 00:14:09.240 --> 00:14:12.600 and updating the online certificate status protocol 268 00:14:12.600 --> 00:14:15.300 with the new certificate status. 269 00:14:15.300 --> 00:14:17.130 With the certificate issued, 270 00:14:17.130 --> 00:14:20.730 Dion Training Solutions LLC can now install 271 00:14:20.730 --> 00:14:25.730 this certificate, diontraining.crt on their web server 272 00:14:25.830 --> 00:14:29.250 to enable secure communication with clients. 273 00:14:29.250 --> 00:14:32.250 This is the end of our demonstration. 274 00:14:32.250 --> 00:14:35.670 So remember, Certificate Authorities 275 00:14:35.670 --> 00:14:38.100 are trusted entities responsible 276 00:14:38.100 --> 00:14:40.650 for issuing, managing, revoking 277 00:14:40.650 --> 00:14:43.680 and validating digital certificates 278 00:14:43.680 --> 00:14:46.470 within the Public Key Infrastructure. 279 00:14:46.470 --> 00:14:50.130 They ensure the security of digital communications 280 00:14:50.130 --> 00:14:53.850 by verifying the identities of certificate holders, 281 00:14:53.850 --> 00:14:56.370 and signing their public keys. 282 00:14:56.370 --> 00:14:59.670 Registration Authorities act as intermediaries, 283 00:14:59.670 --> 00:15:01.920 accepting certificate requests 284 00:15:01.920 --> 00:15:05.670 and validating the authorization of the requesters 285 00:15:05.670 --> 00:15:07.800 before the certificates are issued 286 00:15:07.800 --> 00:15:10.140 by the Certificate Authority. 287 00:15:10.140 --> 00:15:13.950 Together these entities manage the entire lifecycle 288 00:15:13.950 --> 00:15:17.280 of digital certificates, ensuring that the process 289 00:15:17.280 --> 00:15:19.710 is secure and trusted. 290 00:15:19.710 --> 00:15:22.140 Understanding these roles is key 291 00:15:22.140 --> 00:15:24.060 to maintaining the integrity 292 00:15:24.060 --> 00:15:27.510 and reliability of secure communications 293 00:15:27.510 --> 00:15:30.603 in a Public Key Infrastructure system.