1 00:00:00,301 --> 00:00:02,400 Digital Certificates. 2 00:00:02,400 --> 00:00:04,210 A certificate is a digitally-signed 3 00:00:04,210 --> 00:00:06,810 electronic document that binds a public key 4 00:00:06,810 --> 00:00:08,340 with a user's identity. 5 00:00:08,340 --> 00:00:10,060 Now, when I talk about a user here, 6 00:00:10,060 --> 00:00:12,650 the user can be a real live person like you and I 7 00:00:12,650 --> 00:00:13,950 or it can be a server, 8 00:00:13,950 --> 00:00:15,710 a work station or another device 9 00:00:15,710 --> 00:00:17,770 for the purposes of a digital certificate. 10 00:00:17,770 --> 00:00:19,360 These certificates commonly use 11 00:00:19,360 --> 00:00:22,127 the X.509 standard for digital certificates. 12 00:00:22,127 --> 00:00:25,170 This is the common standard used inside of PKI 13 00:00:25,170 --> 00:00:26,880 and the certificates contain the owner's 14 00:00:26,880 --> 00:00:29,180 or user's information like their name, 15 00:00:29,180 --> 00:00:31,590 their organization or even their public key 16 00:00:31,590 --> 00:00:33,010 and it also is going to contain 17 00:00:33,010 --> 00:00:34,900 the certificate authority's information. 18 00:00:34,900 --> 00:00:37,210 The certificate authority is the trusted third party 19 00:00:37,210 --> 00:00:39,150 who is going to issue these digital certificates, 20 00:00:39,150 --> 00:00:41,500 and therefore the certificate's also going to contain 21 00:00:41,500 --> 00:00:43,770 their name, their digital signature, 22 00:00:43,770 --> 00:00:45,730 their serial number for that certificate, 23 00:00:45,730 --> 00:00:47,650 the issue date and the expiration dates 24 00:00:47,650 --> 00:00:49,317 and the version of the certificate. 25 00:00:49,317 --> 00:00:51,620 In the next video we're actually going to explore 26 00:00:51,620 --> 00:00:53,170 the digital certificates for Google 27 00:00:53,170 --> 00:00:55,010 and Apple's web servers and you're going to see 28 00:00:55,010 --> 00:00:57,150 exactly the kind of information that's contained 29 00:00:57,150 --> 00:00:59,534 in an X.509 digital certificate. 30 00:00:59,534 --> 00:01:02,180 To get a digital certificate for your web server 31 00:01:02,180 --> 00:01:03,950 you have to purchase that certificate 32 00:01:03,950 --> 00:01:05,240 from a certificate authority 33 00:01:05,240 --> 00:01:07,050 or a registration authority. 34 00:01:07,050 --> 00:01:08,730 Normally when a certificate is purchased 35 00:01:08,730 --> 00:01:10,390 for a server it's only applied 36 00:01:10,390 --> 00:01:11,910 to one server by default. 37 00:01:11,910 --> 00:01:13,650 So if you're going to purchase a certificate 38 00:01:13,650 --> 00:01:16,040 for diontraining.com it would not be able 39 00:01:16,040 --> 00:01:19,059 to be used for both www.diontraining.com 40 00:01:19,059 --> 00:01:22,000 and courses.diontraining.com. 41 00:01:22,000 --> 00:01:23,871 But if I use a wildcard Certificate 42 00:01:23,871 --> 00:01:25,544 I can use it for both. 43 00:01:25,544 --> 00:01:28,040 A wildcard certificate is going to allow all 44 00:01:28,040 --> 00:01:29,730 of the subdomains to use the same 45 00:01:29,730 --> 00:01:32,900 public key certificate and have it displayed as valid. 46 00:01:32,900 --> 00:01:35,100 Wildcard certificates are easier to manage, 47 00:01:35,100 --> 00:01:37,530 especially if all of your servers will be subdomains 48 00:01:37,530 --> 00:01:38,890 off your main web domain. 49 00:01:38,890 --> 00:01:41,610 And so this will allow you to use one certificate, 50 00:01:41,610 --> 00:01:42,820 save a little bit of money 51 00:01:42,820 --> 00:01:44,770 and make your life a little bit easier. 52 00:01:44,770 --> 00:01:46,550 In fact, all of my websites, 53 00:01:46,550 --> 00:01:48,110 we use wildcard certificates 54 00:01:48,110 --> 00:01:50,340 because of the ease of maintainability. 55 00:01:50,340 --> 00:01:51,830 But with every advantage 56 00:01:51,830 --> 00:01:53,230 there are some disadvantages 57 00:01:53,230 --> 00:01:54,400 that you have to consider 58 00:01:54,400 --> 00:01:56,600 if you're going to use wildcard certificates. 59 00:01:56,600 --> 00:01:57,640 The biggest one is that 60 00:01:57,640 --> 00:01:59,020 if your server is compromised 61 00:01:59,020 --> 00:02:00,810 and that certificate needs to be revoked 62 00:02:00,810 --> 00:02:01,980 it's going to affect all 63 00:02:01,980 --> 00:02:03,870 of your other subdomain servers. 64 00:02:03,870 --> 00:02:06,610 Luckily, reissuing a new certificate's fairly quick 65 00:02:06,610 --> 00:02:07,443 and since you only 66 00:02:07,443 --> 00:02:09,500 have a single wildcard certificate to use, 67 00:02:09,500 --> 00:02:12,320 you're going to be able to get that back online fairly quickly. 68 00:02:12,320 --> 00:02:14,190 But this is something you need to be aware of 69 00:02:14,190 --> 00:02:15,023 when you're deciding whether 70 00:02:15,023 --> 00:02:17,146 or not you should choose single use certificates 71 00:02:17,146 --> 00:02:19,450 or a wildcard certificate? 72 00:02:19,450 --> 00:02:21,400 Some organizations have multiple websites 73 00:02:21,400 --> 00:02:23,240 with different domain names as well. 74 00:02:23,240 --> 00:02:25,760 For example, I own diontraining.com 75 00:02:25,760 --> 00:02:28,005 but I also own jasondion.com. 76 00:02:28,005 --> 00:02:30,450 Now, if I wanted to use one certificate 77 00:02:30,450 --> 00:02:32,190 to cover both of those domains 78 00:02:32,190 --> 00:02:34,340 because they don't have the same root domain, 79 00:02:34,340 --> 00:02:37,090 I would have to modify the Subject Alternate Name 80 00:02:37,090 --> 00:02:38,310 or the SAN field. 81 00:02:38,310 --> 00:02:40,760 Now, the SAN field in a certificate specifies 82 00:02:40,760 --> 00:02:43,060 what additional domains and IP addresses 83 00:02:43,060 --> 00:02:45,430 are going to be supported by that certificate. 84 00:02:45,430 --> 00:02:46,680 Two other types of certificates 85 00:02:46,680 --> 00:02:48,510 that we have to think about are single-sided 86 00:02:48,510 --> 00:02:50,420 and dual-sided certificates. 87 00:02:50,420 --> 00:02:51,320 Now for example, 88 00:02:51,320 --> 00:02:52,930 when you connect on my website 89 00:02:52,930 --> 00:02:54,880 there's a secure session that's established 90 00:02:54,880 --> 00:02:56,840 and my server's going to identify itself 91 00:02:56,840 --> 00:02:57,960 to your web browser 92 00:02:57,960 --> 00:03:00,110 using my server's digital certificate. 93 00:03:00,110 --> 00:03:01,760 Now, you aren't required to have your own 94 00:03:01,760 --> 00:03:03,210 digital certificate to be authenticated 95 00:03:03,210 --> 00:03:04,280 back to me though. 96 00:03:04,280 --> 00:03:06,810 This is known as a single-sided certificate 97 00:03:06,810 --> 00:03:09,130 because only one side of this authentication 98 00:03:09,130 --> 00:03:11,260 is happening with the certificate. 99 00:03:11,260 --> 00:03:12,880 Now, some organizations require 100 00:03:12,880 --> 00:03:14,550 both the server and the user 101 00:03:14,550 --> 00:03:17,030 to validate each other using certificates. 102 00:03:17,030 --> 00:03:18,470 When this occurs this is called 103 00:03:18,470 --> 00:03:19,954 a dual-sided certificate. 104 00:03:19,954 --> 00:03:22,220 Now, using dual-sided certificates, 105 00:03:22,220 --> 00:03:24,490 it's better for security but it does require 106 00:03:24,490 --> 00:03:26,380 twice the processing power on the server, 107 00:03:26,380 --> 00:03:27,440 so it's usually only used 108 00:03:27,440 --> 00:03:29,370 in high security environments. 109 00:03:29,370 --> 00:03:31,790 Now, with digital certificates each certificate 110 00:03:31,790 --> 00:03:34,610 is validated using the concept of a chain of trust, 111 00:03:34,610 --> 00:03:36,610 moving from the bottom upward. 112 00:03:36,610 --> 00:03:39,010 Now, I like to think of this like a family tree. 113 00:03:39,010 --> 00:03:40,750 Let's assume your grandfather's the patriarch 114 00:03:40,750 --> 00:03:43,110 of your family and everyone trusts him. 115 00:03:43,110 --> 00:03:44,370 He then had your father 116 00:03:44,370 --> 00:03:46,637 and so since our grandfather trusts our father, 117 00:03:46,637 --> 00:03:48,475 we also are going to trust our father. 118 00:03:48,475 --> 00:03:50,500 Then our father had us. 119 00:03:50,500 --> 00:03:52,120 And no one is really sure if they should trust us 120 00:03:52,120 --> 00:03:52,953 or not, right? 121 00:03:52,953 --> 00:03:54,560 But if they trusted our father 122 00:03:54,560 --> 00:03:55,440 and our father is trusted 123 00:03:55,440 --> 00:03:56,630 because of our grandfather, 124 00:03:56,630 --> 00:03:57,840 it can go up that chain 125 00:03:57,840 --> 00:03:59,530 and we can be trusted as well. 126 00:03:59,530 --> 00:04:01,070 That's the same idea here. 127 00:04:01,070 --> 00:04:03,480 Your grandfather is the root certificate authority 128 00:04:03,480 --> 00:04:04,930 because he is the highest level 129 00:04:04,930 --> 00:04:06,960 in this particular little family tree. 130 00:04:06,960 --> 00:04:09,970 The family tree is known as a certification path. 131 00:04:09,970 --> 00:04:11,830 Now, if I had a child, 132 00:04:11,830 --> 00:04:13,290 that child would then have to go back 133 00:04:13,290 --> 00:04:15,630 up our family tree again and have our grandfather 134 00:04:15,630 --> 00:04:17,440 vouch for Junior's trustworthiness 135 00:04:17,440 --> 00:04:19,718 and so on down our family tree. 136 00:04:19,718 --> 00:04:21,230 As I said before, 137 00:04:21,230 --> 00:04:22,950 digital certificates are usually based 138 00:04:22,950 --> 00:04:26,100 on the X.509 standard but the certificate itself 139 00:04:26,100 --> 00:04:28,310 must be encoded before it can be used. 140 00:04:28,310 --> 00:04:30,480 Now, there are three different encoding methods 141 00:04:30,480 --> 00:04:33,930 that are classified under the X.690 standard. 142 00:04:33,930 --> 00:04:36,680 They're known as BER, CER and DER. 143 00:04:36,680 --> 00:04:38,650 BER is the Basic Encoding Rules 144 00:04:38,650 --> 00:04:40,370 and it's the original ruleset governing 145 00:04:40,370 --> 00:04:42,750 the encoding of data structures for certificates. 146 00:04:42,750 --> 00:04:44,820 But there are several different encoding types 147 00:04:44,820 --> 00:04:46,680 that can be used as part of BER. 148 00:04:46,680 --> 00:04:48,750 Now, for the Security+ exam you don't need 149 00:04:48,750 --> 00:04:51,330 to know the specific encoding types underneath BER. 150 00:04:51,330 --> 00:04:52,820 So we're not even going to cover them here 151 00:04:52,820 --> 00:04:54,640 but just realize that BER has the ability 152 00:04:54,640 --> 00:04:56,450 to have multiple encoding types. 153 00:04:56,450 --> 00:04:58,310 And that makes it different than CER. 154 00:04:58,310 --> 00:05:00,580 CER is the Canonical Encoding Rules 155 00:05:00,580 --> 00:05:02,140 which is a restricted version of BER 156 00:05:02,140 --> 00:05:04,920 that only allows the use of one encoding type. 157 00:05:04,920 --> 00:05:07,170 DER is the Distinguished Encoding Rules. 158 00:05:07,170 --> 00:05:09,290 And this is another restricted version of BER, 159 00:05:09,290 --> 00:05:11,570 and it only allows one encoding type as well 160 00:05:11,570 --> 00:05:13,830 but it has more restrictive rules for length, 161 00:05:13,830 --> 00:05:15,930 character strings and how a particular element 162 00:05:15,930 --> 00:05:17,880 of a digital certificate is stored. 163 00:05:17,880 --> 00:05:20,170 In fact, DER is what is used commonly 164 00:05:20,170 --> 00:05:22,950 for X.509 encoding of certificates. 165 00:05:22,950 --> 00:05:24,610 When dealing with digital certificates 166 00:05:24,610 --> 00:05:26,720 you may come across a few different file types 167 00:05:26,720 --> 00:05:27,610 on your machine, 168 00:05:27,610 --> 00:05:29,050 including the PEM, 169 00:05:29,050 --> 00:05:30,117 CER, 170 00:05:30,117 --> 00:05:31,180 CRT, 171 00:05:31,180 --> 00:05:32,106 KEY, 172 00:05:32,106 --> 00:05:33,316 P12, 173 00:05:33,316 --> 00:05:34,149 PFX 174 00:05:34,149 --> 00:05:35,820 and P7B. 175 00:05:35,820 --> 00:05:37,370 The .pem format is used 176 00:05:37,370 --> 00:05:39,500 for Privacy-enhanced Electronic Mail 177 00:05:39,500 --> 00:05:41,810 and it uses the DER encoding method. 178 00:05:41,810 --> 00:05:44,876 Sometimes it also stores itself as a .cer, 179 00:05:44,876 --> 00:05:47,300 .crt or .key file. 180 00:05:47,300 --> 00:05:49,320 The .p12 file is going to be used 181 00:05:49,320 --> 00:05:50,900 to store a server certificate, 182 00:05:50,900 --> 00:05:53,110 an intermediate certificate and a private key 183 00:05:53,110 --> 00:05:54,810 in one encrypted file. 184 00:05:54,810 --> 00:05:57,710 It's called the .p12 because it's a binary format 185 00:05:57,710 --> 00:06:00,470 of the Public Key Cryptographic System #12 186 00:06:00,470 --> 00:06:03,015 or PKCS#12 certificate. 187 00:06:03,015 --> 00:06:05,290 Now, the .pfx file is called 188 00:06:05,290 --> 00:06:07,100 the Personal Information Exchange 189 00:06:07,100 --> 00:06:09,630 and it's used by Microsoft for release signing. 190 00:06:09,630 --> 00:06:11,630 This file is going to contain both the private 191 00:06:11,630 --> 00:06:12,813 and public keys in it. 192 00:06:12,813 --> 00:06:16,380 The .p7b file is used as the basis for S/MIME, 193 00:06:16,380 --> 00:06:18,200 the secure email protocol. 194 00:06:18,200 --> 00:06:20,710 And this is also going to be used for single sign-on. 195 00:06:20,710 --> 00:06:22,920 It's called the .p7b because it's based 196 00:06:22,920 --> 00:06:25,170 on the PKCS#7. 197 00:06:25,170 --> 00:06:27,380 Now, I know that was a lot of information. 198 00:06:27,380 --> 00:06:29,710 For the exam I doubt you're going to get a question 199 00:06:29,710 --> 00:06:32,410 on any of the details of these particular file types 200 00:06:32,410 --> 00:06:34,140 but if you see a file type listed 201 00:06:34,140 --> 00:06:37,550 on the exam like .p12 you should remember 202 00:06:37,550 --> 00:06:39,550 that it has to do with PKI in general. 203 00:06:39,550 --> 00:06:40,950 And then you'll be able to choose an answer 204 00:06:40,950 --> 00:06:42,600 that's appropriate based on that.