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