1 00:00:00,090 --> 00:00:00,990 In this lesson, 2 00:00:00,990 --> 00:00:03,240 we're going to discuss digital certificates. 3 00:00:03,240 --> 00:00:04,320 Now, a digital certificate 4 00:00:04,320 --> 00:00:06,210 is a digitally-signed electronic document 5 00:00:06,210 --> 00:00:09,060 that binds a public key with a user's identity. 6 00:00:09,060 --> 00:00:10,740 Now, when I talk about a user here, 7 00:00:10,740 --> 00:00:13,110 the user can be a real live person like you and I, 8 00:00:13,110 --> 00:00:15,030 or it can be a server, a workstation, 9 00:00:15,030 --> 00:00:18,210 or other device that is assigned a digital certificate. 10 00:00:18,210 --> 00:00:20,070 Now, these certificates are commonly going to use 11 00:00:20,070 --> 00:00:22,350 the X.509 protocol standard 12 00:00:22,350 --> 00:00:24,960 for digital certificates inside of PKI. 13 00:00:24,960 --> 00:00:26,640 And these certificates contain the owner 14 00:00:26,640 --> 00:00:29,310 or user's information, including things like their name, 15 00:00:29,310 --> 00:00:31,530 their organization, and even their public key, 16 00:00:31,530 --> 00:00:33,180 as well as containing all the information 17 00:00:33,180 --> 00:00:35,460 about the certificate authority too. 18 00:00:35,460 --> 00:00:37,260 Now, as we explore digital certificates, 19 00:00:37,260 --> 00:00:39,210 you're going to learn about wildcard certificates, 20 00:00:39,210 --> 00:00:41,490 single-sided and dual-sided certificates, 21 00:00:41,490 --> 00:00:44,130 self-signed certificates, third-party certificates, 22 00:00:44,130 --> 00:00:46,410 the root of trust, the certificate authority, 23 00:00:46,410 --> 00:00:49,230 the registration authority, the certificate signing request, 24 00:00:49,230 --> 00:00:51,900 the certificate revocation list, key escrow agents, 25 00:00:51,900 --> 00:00:53,880 and key recovery agents. 26 00:00:53,880 --> 00:00:56,550 Now, normally, when a certificate is purchased for a server, 27 00:00:56,550 --> 00:00:59,250 it's going to be applied to only one server by default. 28 00:00:59,250 --> 00:01:01,290 So if you paid to get a digital certificate 29 00:01:01,290 --> 00:01:02,730 for diontraining.com, 30 00:01:02,730 --> 00:01:05,519 it's not going to be able to be used for diontraining.com, 31 00:01:05,519 --> 00:01:09,810 www.diontraining.com and courses.diontraining.com too. 32 00:01:09,810 --> 00:01:12,060 But if I use a wildcard certificate, 33 00:01:12,060 --> 00:01:14,400 I can use it for all of those websites. 34 00:01:14,400 --> 00:01:16,920 So this brings us to our first key term, 35 00:01:16,920 --> 00:01:18,630 a wildcard certificate. 36 00:01:18,630 --> 00:01:19,920 Now, a wildcard certificate 37 00:01:19,920 --> 00:01:21,600 is going to allow all the subdomains 38 00:01:21,600 --> 00:01:23,490 to use the same public key certificate 39 00:01:23,490 --> 00:01:25,410 and have it displayed as valid. 40 00:01:25,410 --> 00:01:27,450 Wildcard certificates are easy to manage, 41 00:01:27,450 --> 00:01:28,740 especially if all of your servers 42 00:01:28,740 --> 00:01:31,560 are going to be subdomains off your main web domain. 43 00:01:31,560 --> 00:01:33,750 Now, this is going to allow you to use one certificate. 44 00:01:33,750 --> 00:01:35,130 It'll allow you to save a little bit of money 45 00:01:35,130 --> 00:01:37,170 because you only have to buy one certificate, 46 00:01:37,170 --> 00:01:39,000 and it can make your life a bit easier 47 00:01:39,000 --> 00:01:41,460 because you only have one certificate to manage. 48 00:01:41,460 --> 00:01:43,440 In fact, most of my websites are going to use 49 00:01:43,440 --> 00:01:44,370 wildcard certificates 50 00:01:44,370 --> 00:01:46,620 because of the ease of maintainability, 51 00:01:46,620 --> 00:01:47,850 but with every advantage, 52 00:01:47,850 --> 00:01:50,220 there are some disadvantages you have to consider 53 00:01:50,220 --> 00:01:52,680 if you're going to be using a wildcard certificate. 54 00:01:52,680 --> 00:01:54,390 Now, the biggest one is that if your server 55 00:01:54,390 --> 00:01:56,670 is compromised and that certificate needs to be revoked, 56 00:01:56,670 --> 00:01:58,020 it's actually going to affect all 57 00:01:58,020 --> 00:01:59,910 of your other subdomain servers too. 58 00:01:59,910 --> 00:02:01,650 Luckily, reissuing a new certificate 59 00:02:01,650 --> 00:02:03,180 is a pretty quick process 60 00:02:03,180 --> 00:02:04,140 and you only have to have 61 00:02:04,140 --> 00:02:06,090 one single wildcard certificate to use. 62 00:02:06,090 --> 00:02:08,280 This will allow you to get back online pretty quickly, 63 00:02:08,280 --> 00:02:10,080 'cause you can reissue a new certificate 64 00:02:10,080 --> 00:02:11,940 and push it to all of your servers. 65 00:02:11,940 --> 00:02:13,890 But this is something you should be aware of 66 00:02:13,890 --> 00:02:15,330 when you're deciding whether or not 67 00:02:15,330 --> 00:02:19,110 to use a single-use certificate or a wildcard certificate. 68 00:02:19,110 --> 00:02:21,450 Now, some organizations have multiple websites 69 00:02:21,450 --> 00:02:23,310 that have different domain names too. 70 00:02:23,310 --> 00:02:26,310 For example, I personally have diontraining.com 71 00:02:26,310 --> 00:02:28,380 and jasondion.com. 72 00:02:28,380 --> 00:02:29,970 Now, if I wanted to use one certificate to cover 73 00:02:29,970 --> 00:02:31,230 both of those domains, 74 00:02:31,230 --> 00:02:33,030 and since they don't have the same root domain 75 00:02:33,030 --> 00:02:35,610 of diontraining.com, I would have to modify 76 00:02:35,610 --> 00:02:37,080 what's known as the SAN field, 77 00:02:37,080 --> 00:02:39,000 or the subject alternate name. 78 00:02:39,000 --> 00:02:41,460 Now, if you adjust this subject alternate name field 79 00:02:41,460 --> 00:02:43,050 inside of the digital certificate, 80 00:02:43,050 --> 00:02:44,880 you can use this one certificate 81 00:02:44,880 --> 00:02:46,410 to support both of those domains 82 00:02:46,410 --> 00:02:48,810 instead of using a wildcard certificate. 83 00:02:48,810 --> 00:02:51,270 Remember, if you're using two different domains, 84 00:02:51,270 --> 00:02:53,790 you're going to have to use a subject alternate name field 85 00:02:53,790 --> 00:02:55,560 instead of using a wildcard. 86 00:02:55,560 --> 00:02:57,390 But if everything is on the same domain, 87 00:02:57,390 --> 00:03:01,800 like www.diontraining.com and courses.diontraining.com, 88 00:03:01,800 --> 00:03:04,500 then you can use a wildcard certificate. 89 00:03:04,500 --> 00:03:06,660 Second, we need to cover single-sided 90 00:03:06,660 --> 00:03:08,430 and dual-sided certificates. 91 00:03:08,430 --> 00:03:09,750 Now, let's say for example, 92 00:03:09,750 --> 00:03:11,160 you want to connect to my website 93 00:03:11,160 --> 00:03:12,540 and create a secure session 94 00:03:12,540 --> 00:03:14,190 that can be established between my server 95 00:03:14,190 --> 00:03:16,290 who's going to identify itself to your web browser 96 00:03:16,290 --> 00:03:18,420 using my server's digital certificate. 97 00:03:18,420 --> 00:03:21,270 That would be considered a single-sided certificate. 98 00:03:21,270 --> 00:03:22,170 Now, you aren't required 99 00:03:22,170 --> 00:03:23,370 to have your own digital certificate 100 00:03:23,370 --> 00:03:25,020 to authenticate back to me, 101 00:03:25,020 --> 00:03:26,490 and so because of this, 102 00:03:26,490 --> 00:03:28,770 we only have one side of authentication happening 103 00:03:28,770 --> 00:03:31,260 and we call this a single-sided certificate. 104 00:03:31,260 --> 00:03:33,690 Now, some organizations require both the server 105 00:03:33,690 --> 00:03:36,720 and the user to validate each other using certificates. 106 00:03:36,720 --> 00:03:40,170 When this occurs, we call this a dual-sided certificate. 107 00:03:40,170 --> 00:03:41,670 Now, using dual-sided certificates 108 00:03:41,670 --> 00:03:43,200 is going to be better for security, 109 00:03:43,200 --> 00:03:45,180 but it does require twice the processing power 110 00:03:45,180 --> 00:03:47,040 on the server, so it's only going to be used 111 00:03:47,040 --> 00:03:49,410 in really high security environments. 112 00:03:49,410 --> 00:03:52,650 Third, we have something known as a self-signed certificate. 113 00:03:52,650 --> 00:03:54,900 Now, self-signed certificates are digital certificates 114 00:03:54,900 --> 00:03:56,550 that are signed by the same entity 115 00:03:56,550 --> 00:03:58,290 whose identity it's certifying, 116 00:03:58,290 --> 00:04:00,510 rather than by a trusted certificate authority 117 00:04:00,510 --> 00:04:02,040 or third party. 118 00:04:02,040 --> 00:04:03,900 In essence, the entity is claiming 119 00:04:03,900 --> 00:04:06,420 its own identity and vouches for itself. 120 00:04:06,420 --> 00:04:08,250 Now, these certificates can provide encryption 121 00:04:08,250 --> 00:04:09,480 just like other certificates, 122 00:04:09,480 --> 00:04:11,190 but they don't offer the same level 123 00:04:11,190 --> 00:04:13,830 of trust because there's no external verification 124 00:04:13,830 --> 00:04:15,480 of the user's identity. 125 00:04:15,480 --> 00:04:17,130 Now, there are commonly going to be used in things 126 00:04:17,130 --> 00:04:19,230 like testing environments and closed systems 127 00:04:19,230 --> 00:04:20,790 and non-production systems 128 00:04:20,790 --> 00:04:22,740 where trust is already established. 129 00:04:22,740 --> 00:04:24,720 But anytime you're accessing a site 130 00:04:24,720 --> 00:04:26,460 using one of these self-signed certificates, 131 00:04:26,460 --> 00:04:27,720 it will create a warning 132 00:04:27,720 --> 00:04:29,220 inside of your web browser, 133 00:04:29,220 --> 00:04:31,860 especially for you're using it on a publicly-facing website 134 00:04:31,860 --> 00:04:33,120 because it lacks the endorsement 135 00:04:33,120 --> 00:04:35,220 of that trusted third party. 136 00:04:35,220 --> 00:04:37,800 Now, fourth, we have third-party certificates. 137 00:04:37,800 --> 00:04:38,970 Third-party certificates, 138 00:04:38,970 --> 00:04:40,470 often just called certificates, 139 00:04:40,470 --> 00:04:42,780 are digital certificates issued and signed 140 00:04:42,780 --> 00:04:44,460 by a trusted certificate authority, 141 00:04:44,460 --> 00:04:46,350 which we call a CA. 142 00:04:46,350 --> 00:04:47,820 Now, these certificate authorities 143 00:04:47,820 --> 00:04:48,990 will have their root certificates 144 00:04:48,990 --> 00:04:50,640 embedded into major web browsers 145 00:04:50,640 --> 00:04:51,810 and operating systems, 146 00:04:51,810 --> 00:04:53,610 which means that any certificate they issue 147 00:04:53,610 --> 00:04:56,880 is inherently going to be trusted by that system or browser. 148 00:04:56,880 --> 00:04:59,520 When a user or system encounters a third-party certificate, 149 00:04:59,520 --> 00:05:01,200 they can actually trace its authenticity 150 00:05:01,200 --> 00:05:04,590 back to a known and trusted CA or certificate authority, 151 00:05:04,590 --> 00:05:06,930 and this level of external verification will ensure 152 00:05:06,930 --> 00:05:08,730 a higher degree of trust and security 153 00:05:08,730 --> 00:05:11,640 for online transactions or encrypted communications, 154 00:05:11,640 --> 00:05:14,070 and this makes third party certificates a preferred choice 155 00:05:14,070 --> 00:05:15,660 for any publicly-facing websites 156 00:05:15,660 --> 00:05:18,300 or applications you may be hosting. 157 00:05:18,300 --> 00:05:20,610 Fifth, we have the root of trust. 158 00:05:20,610 --> 00:05:21,960 Now, with digital certificates, 159 00:05:21,960 --> 00:05:23,310 each certificate is validated 160 00:05:23,310 --> 00:05:25,650 using a concept known as the root of trust 161 00:05:25,650 --> 00:05:26,940 or the chain of trust 162 00:05:26,940 --> 00:05:29,610 that moves from the bottom, all the way to the top. 163 00:05:29,610 --> 00:05:31,920 I like to think about this like a family tree. 164 00:05:31,920 --> 00:05:33,840 Let's assume your grandfather is the patriarch 165 00:05:33,840 --> 00:05:36,120 of your family and everybody trusts him. 166 00:05:36,120 --> 00:05:37,380 He then had your father, 167 00:05:37,380 --> 00:05:39,450 and so, since everybody trusted your grandfather 168 00:05:39,450 --> 00:05:41,400 and your grandfather trusted your father, 169 00:05:41,400 --> 00:05:43,440 they're now going to trust your father too. 170 00:05:43,440 --> 00:05:45,240 Then your father had us, 171 00:05:45,240 --> 00:05:46,290 and because nobody really knows 172 00:05:46,290 --> 00:05:47,550 that they should trust us or not, 173 00:05:47,550 --> 00:05:50,460 they look up and say, hmm, well, I trusted your father 174 00:05:50,460 --> 00:05:53,100 and I trusted your father's father who's your grandfather, 175 00:05:53,100 --> 00:05:55,020 and because we can go back up that chain, 176 00:05:55,020 --> 00:05:57,720 we're going to assume that you can be trusted here as well, 177 00:05:57,720 --> 00:05:58,830 and that's the idea. 178 00:05:58,830 --> 00:06:00,510 Your grandfather, in this example, 179 00:06:00,510 --> 00:06:01,980 is the root certificate authority 180 00:06:01,980 --> 00:06:03,360 because he is the highest level 181 00:06:03,360 --> 00:06:05,520 in this particular little family tree. 182 00:06:05,520 --> 00:06:07,080 The family tree is going to be known 183 00:06:07,080 --> 00:06:08,550 as our certification path 184 00:06:08,550 --> 00:06:10,410 in the world of digital certificates. 185 00:06:10,410 --> 00:06:12,240 Now, if I end up having a child, 186 00:06:12,240 --> 00:06:14,910 that child would have to go back up our family tree again 187 00:06:14,910 --> 00:06:17,940 and have our grandfather vouch for junior's trustworthiness 188 00:06:17,940 --> 00:06:20,580 and so on as we go down the family tree. 189 00:06:20,580 --> 00:06:22,260 The rooted trust for most certificates 190 00:06:22,260 --> 00:06:24,510 is going to be a trusted third-party provider 191 00:06:24,510 --> 00:06:26,580 like Verisign, Amazon, 192 00:06:26,580 --> 00:06:30,150 Google, CloudFlare, or some other large service provider. 193 00:06:30,150 --> 00:06:32,400 Sixth, we have the certificate authority. 194 00:06:32,400 --> 00:06:34,740 The certificate authority is the trusted third-party 195 00:06:34,740 --> 00:06:36,480 who's going to issue these digital certificates, 196 00:06:36,480 --> 00:06:38,850 and therefore, the certificate is also going to contain 197 00:06:38,850 --> 00:06:41,220 their name, their digital signature, the serial number 198 00:06:41,220 --> 00:06:43,950 for that certificate, the issue and expiration date, 199 00:06:43,950 --> 00:06:45,840 and the version of that certificate. 200 00:06:45,840 --> 00:06:47,970 To get a digital certificate for your web server, 201 00:06:47,970 --> 00:06:49,620 you do have to purchase that certificate 202 00:06:49,620 --> 00:06:50,940 from a certificate authority 203 00:06:50,940 --> 00:06:52,440 or registration authority, 204 00:06:52,440 --> 00:06:54,150 which brings us to our seventh term, 205 00:06:54,150 --> 00:06:55,890 the registration authority. 206 00:06:55,890 --> 00:06:57,630 For digital certificates to be issued, 207 00:06:57,630 --> 00:06:59,940 the user first has to request a digital certificate 208 00:06:59,940 --> 00:07:03,270 from a registration authority, which is known as an RA. 209 00:07:03,270 --> 00:07:05,220 The registration authority then will request 210 00:07:05,220 --> 00:07:07,140 the identifying information from the user 211 00:07:07,140 --> 00:07:08,850 and forward that certificate request 212 00:07:08,850 --> 00:07:10,320 up to the certificate authority 213 00:07:10,320 --> 00:07:12,810 who will create the digital certificate for the user. 214 00:07:12,810 --> 00:07:15,210 Now, there are many root certificate authorities out there, 215 00:07:15,210 --> 00:07:17,460 including companies like Verisign, Digisign, 216 00:07:17,460 --> 00:07:20,430 and numerous others who can act as trusted third parties 217 00:07:20,430 --> 00:07:21,810 to validate their certificates 218 00:07:21,810 --> 00:07:24,000 are being issued to the correct people. 219 00:07:24,000 --> 00:07:25,740 The certificate authority also maintains 220 00:07:25,740 --> 00:07:28,680 a publicly-accessible copy of that user's public key, 221 00:07:28,680 --> 00:07:30,330 and this allows them to have that for use 222 00:07:30,330 --> 00:07:32,070 by other users who wish to send them 223 00:07:32,070 --> 00:07:33,810 confidential information. 224 00:07:33,810 --> 00:07:35,850 So when you want to go to our web server 225 00:07:35,850 --> 00:07:38,730 for diontrain.com, your web browser is actually going 226 00:07:38,730 --> 00:07:41,340 to our trusted third-party and pulling our public key, 227 00:07:41,340 --> 00:07:43,590 and then using that to encrypt a long random series 228 00:07:43,590 --> 00:07:46,440 of numbers that we can then use as a shared secret key. 229 00:07:46,440 --> 00:07:47,820 But since you encrypted it using 230 00:07:47,820 --> 00:07:50,310 the diontraining.com server's public key, 231 00:07:50,310 --> 00:07:52,830 only that server will be able to decrypt your message, 232 00:07:52,830 --> 00:07:55,470 read that random long series of numbers your system chose, 233 00:07:55,470 --> 00:07:57,810 and then use that to create a bulk encryption tunnel 234 00:07:57,810 --> 00:07:59,550 using symmetric encryption algorithms 235 00:07:59,550 --> 00:08:03,060 like AES with that newly-chosen shared secret key. 236 00:08:03,060 --> 00:08:05,760 Eighth, we have the certificate signing request. 237 00:08:05,760 --> 00:08:07,260 A certificate signing request, 238 00:08:07,260 --> 00:08:10,260 known as a CSR, is a vital component in the process 239 00:08:10,260 --> 00:08:11,640 of obtaining your digital certificate 240 00:08:11,640 --> 00:08:13,830 for your server or other devices. 241 00:08:13,830 --> 00:08:16,350 Essentially, a certificate signing request is a block 242 00:08:16,350 --> 00:08:18,480 of encoded text that contains information 243 00:08:18,480 --> 00:08:20,700 about the entity that's requesting the certificate, 244 00:08:20,700 --> 00:08:22,440 including the organization's name, 245 00:08:22,440 --> 00:08:25,050 domain name, locality, and country. 246 00:08:25,050 --> 00:08:27,120 When an entity desires a digital certificate 247 00:08:27,120 --> 00:08:28,470 from a certificate authority, 248 00:08:28,470 --> 00:08:30,990 it first generates a certificate signing request, 249 00:08:30,990 --> 00:08:33,120 which includes the entity's public key. 250 00:08:33,120 --> 00:08:35,340 The certificate authority will then use the details 251 00:08:35,340 --> 00:08:36,870 in that certificate signing request 252 00:08:36,870 --> 00:08:38,549 to create the final digital certificate 253 00:08:38,549 --> 00:08:40,350 that will be issued back to you. 254 00:08:40,350 --> 00:08:42,450 It's important to note the private key associated 255 00:08:42,450 --> 00:08:45,090 with the request remain securely with the requester 256 00:08:45,090 --> 00:08:47,760 and is never sent out to the certificate authority 257 00:08:47,760 --> 00:08:49,770 because this ensures the confidentiality 258 00:08:49,770 --> 00:08:51,510 of that given key pair. 259 00:08:51,510 --> 00:08:53,100 Once the certificate authority validates 260 00:08:53,100 --> 00:08:54,690 the entity's credentials and processes 261 00:08:54,690 --> 00:08:56,250 the certificate signing request, 262 00:08:56,250 --> 00:08:58,800 the resulting certificate will be returned to the entity 263 00:08:58,800 --> 00:09:00,420 and can be installed on all of its servers 264 00:09:00,420 --> 00:09:02,820 to facilitate secure communications. 265 00:09:02,820 --> 00:09:05,460 Ninth, we have the certificate revocation list, 266 00:09:05,460 --> 00:09:07,500 known as the CRL. 267 00:09:07,500 --> 00:09:09,120 Now, each certificate authority is going 268 00:09:09,120 --> 00:09:11,670 to maintain its own certificate revocation list, 269 00:09:11,670 --> 00:09:13,260 known as the CRL. 270 00:09:13,260 --> 00:09:15,420 This CRL will serve as an online list 271 00:09:15,420 --> 00:09:17,400 of digital certificates that the certificate authority 272 00:09:17,400 --> 00:09:18,990 has already revoked. 273 00:09:18,990 --> 00:09:20,880 Usually this is because those certificates 274 00:09:20,880 --> 00:09:23,820 have become compromised by some kind of data breach. 275 00:09:23,820 --> 00:09:26,070 The certificate revocation list is the full list 276 00:09:26,070 --> 00:09:29,130 of every certificate that has ever, ever been revoked 277 00:09:29,130 --> 00:09:31,290 by that particular certificate authority. 278 00:09:31,290 --> 00:09:33,840 Whenever your computer tries to connect to a new web server, 279 00:09:33,840 --> 00:09:36,300 it's first going to request the current public key 280 00:09:36,300 --> 00:09:39,150 for that digital certificate from the certificate authority. 281 00:09:39,150 --> 00:09:41,130 Now, the certificate authority will first check 282 00:09:41,130 --> 00:09:42,510 the certificate revocation list 283 00:09:42,510 --> 00:09:43,980 before they send you that public key 284 00:09:43,980 --> 00:09:45,420 or digital certificate to ensure 285 00:09:45,420 --> 00:09:47,490 it hasn't already been revoked. 286 00:09:47,490 --> 00:09:49,740 10th, we have key escrow agents. 287 00:09:49,740 --> 00:09:52,050 Now, key escrow is going to occur when a secure copy 288 00:09:52,050 --> 00:09:53,970 of a user's private key is being held 289 00:09:53,970 --> 00:09:56,700 just in case the user accidentally loses their key. 290 00:09:56,700 --> 00:09:59,610 If your organization simply can't accept any data loss, 291 00:09:59,610 --> 00:10:02,220 then you need to ensure that key escrow has been set up, 292 00:10:02,220 --> 00:10:05,460 and you're going to do this by using a key escrow agent. 293 00:10:05,460 --> 00:10:07,410 Remember, whenever you use key escrow, 294 00:10:07,410 --> 00:10:09,870 you have to protect that key store from anybody who's trying 295 00:10:09,870 --> 00:10:10,950 to steal those keys, 296 00:10:10,950 --> 00:10:12,480 and it's recommended that you have at least 297 00:10:12,480 --> 00:10:13,890 two different administrators present 298 00:10:13,890 --> 00:10:16,710 anytime a key is being taken out of escrow. 299 00:10:16,710 --> 00:10:18,390 This is going to help you implement the concept 300 00:10:18,390 --> 00:10:20,160 of separation of duties as well. 301 00:10:20,160 --> 00:10:22,020 This brings us to the 11th thing we have, 302 00:10:22,020 --> 00:10:23,910 which is key recovery agents. 303 00:10:23,910 --> 00:10:26,700 Now, a key recovery agent is a specialized type of software 304 00:10:26,700 --> 00:10:28,320 that allows the restoration of a lost 305 00:10:28,320 --> 00:10:30,240 or corrupted key to be performed. 306 00:10:30,240 --> 00:10:31,800 Think of this as a backup of all 307 00:10:31,800 --> 00:10:33,330 of the certificate authority's keys, 308 00:10:33,330 --> 00:10:36,600 just in case a major incident or a disaster occurs. 309 00:10:36,600 --> 00:10:39,180 So remember, there is a lot going on in the world 310 00:10:39,180 --> 00:10:41,100 of digital certificates and everything in the world 311 00:10:41,100 --> 00:10:43,590 of digital certificates comes down to trust. 312 00:10:43,590 --> 00:10:45,390 If a root certificate authority is compromised 313 00:10:45,390 --> 00:10:47,790 by an attacker, for example, then every certificate 314 00:10:47,790 --> 00:10:50,100 that has ever been issued by that certificate authority 315 00:10:50,100 --> 00:10:51,870 is now considered to be compromised 316 00:10:51,870 --> 00:10:54,180 and they have to be revoked and reissued. 317 00:10:54,180 --> 00:10:56,400 Luckily, this is not a frequent occurrence, 318 00:10:56,400 --> 00:10:57,990 especially with commercially-trusted 319 00:10:57,990 --> 00:10:59,790 third-party certificate authorities, 320 00:10:59,790 --> 00:11:01,710 but if you're running your own certificate authority 321 00:11:01,710 --> 00:11:04,080 within your organization and it gets compromised, 322 00:11:04,080 --> 00:11:05,850 this is something you will need to be aware of, 323 00:11:05,850 --> 00:11:07,680 so you can revoke all of your digital certificates 324 00:11:07,680 --> 00:11:10,260 and then recreate new secure digital certificates 325 00:11:10,260 --> 00:11:12,783 for all of your servers, workstations, and users.