1 00:00:01,100 --> 00:00:06,620 In the hierarchical model that will now focus on the certificate from the root certification authority 2 00:00:06,740 --> 00:00:10,800 is the basis of our trust relationship above. 3 00:00:10,800 --> 00:00:16,430 We see a few certificates which for the moment we don't trust. 4 00:00:16,440 --> 00:00:18,930 Let's take a look at a sample certificate. 5 00:00:18,930 --> 00:00:22,070 It can be seen that this is a certificate that is not trusted. 6 00:00:23,740 --> 00:00:28,030 It was issued to someone who was presented as the administrator. 7 00:00:28,060 --> 00:00:31,890 We can see that it was issued by a certification authority called subkey. 8 00:00:32,230 --> 00:00:38,300 We can also see that the certificate is valid for two years from the date of issue. 9 00:00:38,310 --> 00:00:42,110 Let's look now at the details of the certificate. 10 00:00:42,140 --> 00:00:49,100 We have information that this is the third version of the x 5 0 9 protocol. 11 00:00:49,140 --> 00:00:55,470 We see the serial number of our certificate the algorithm that is used for the signature. 12 00:00:55,510 --> 00:01:00,730 In other words confirmation of the authenticity of the certificate and the date of the organization 13 00:01:00,730 --> 00:01:01,540 that issued it. 14 00:01:03,450 --> 00:01:06,160 We already saw the expiration date. 15 00:01:06,210 --> 00:01:10,260 We can also see to whom the certificate was issued in this case. 16 00:01:10,260 --> 00:01:17,130 It turns out that this is the administrator of the domain M-S that P.L.. 17 00:01:17,290 --> 00:01:26,020 We also find here the public key in this case the RSA key with the length of two kilobytes in each certificate 18 00:01:26,020 --> 00:01:30,500 is a public key from the earlier module. 19 00:01:30,500 --> 00:01:34,980 We know that public kids should be publicly known. 20 00:01:35,060 --> 00:01:40,520 There must be some method of distribution or automatic submission of requests to view and download public 21 00:01:40,520 --> 00:01:42,070 keys of various people. 22 00:01:44,360 --> 00:01:48,660 That can be recorded in the certificates. 23 00:01:48,680 --> 00:01:54,060 We also find out about the template that was used for the basis for issuing this certificate. 24 00:01:54,230 --> 00:01:57,890 Here it's the ESFS recovery. 25 00:01:57,920 --> 00:02:02,540 We suspect that this is a certificate which allows the administrator to recover files encrypted with 26 00:02:02,570 --> 00:02:07,190 FS technology on behalf of users who for some reason lost their keys. 27 00:02:10,210 --> 00:02:18,240 The purpose of the certificate confirms this in this case the purpose of the certificate is file recovery. 28 00:02:18,250 --> 00:02:25,420 This is what the certificate is used for and it can only be used for this so that this would be unequivocal 29 00:02:25,860 --> 00:02:29,310 and operation code is attached to the certificate. 30 00:02:29,320 --> 00:02:37,460 This is a universal operation code which a certificate may be used we also mentioned that we must identify 31 00:02:37,460 --> 00:02:46,110 the supplier and the information about the key we find such data. 32 00:02:46,180 --> 00:02:50,170 We also need to be able to check whether the certificate has been withdrawn or not. 33 00:02:53,670 --> 00:03:00,090 Each certificate must contain at least one location of the certificate revoked and list. 34 00:03:00,200 --> 00:03:04,370 There is also at least one piece of information where you can download the certificate issued by the 35 00:03:04,370 --> 00:03:06,850 certification authority. 36 00:03:06,900 --> 00:03:13,410 We check in this way if in fact a given certification authority issued this is actually although we 37 00:03:13,410 --> 00:03:15,800 have a chance to see the details of each certificate 38 00:03:19,380 --> 00:03:23,120 here the Certification Path is not yet shown. 39 00:03:23,360 --> 00:03:26,750 In that case let's see what the root certification authority looks like. 40 00:03:28,730 --> 00:03:34,730 The curious thing here is that the issuer and recipient of the certificate are the same somewhere. 41 00:03:34,740 --> 00:03:37,350 This relationship of trust must begin. 42 00:03:37,350 --> 00:03:39,040 Someone must trust himself. 43 00:03:40,280 --> 00:03:42,610 For now this someone trusts only himself. 44 00:03:44,650 --> 00:03:49,880 Now let's look at the certificate of the subordinate's certification authority. 45 00:03:49,920 --> 00:03:56,340 This is a certificate issued by root for subcounty to certification authorities are building a relationship 46 00:03:56,340 --> 00:04:00,130 of trust what changes in the certificates. 47 00:04:00,130 --> 00:04:06,570 If we try to install one of them what will happen if we receive a certificate from some certification 48 00:04:06,570 --> 00:04:10,440 authority and we have decided to trust him. 49 00:04:10,600 --> 00:04:13,110 Let's check. 50 00:04:13,200 --> 00:04:19,200 We should trust the root certification authority after installation of the certificate on our computer 51 00:04:19,650 --> 00:04:24,260 we now trust that certificate. 52 00:04:24,270 --> 00:04:30,150 Let's see what's changed in this certificate issued by the certification authority to someone else someone 53 00:04:30,150 --> 00:04:39,360 who didn't want to trust it turns out that we also trusted the relationship of trust as trans.. 54 00:04:39,580 --> 00:04:45,660 This is the basis of the hierarchical structure trusting the root cause certificate means that we use 55 00:04:45,660 --> 00:04:52,840 trust all certificates issued by this authority in the case of the administrator certificate we don't 56 00:04:52,840 --> 00:04:59,920 have full access because we're not able to verify his certificate for our demonstration purposes we 57 00:04:59,920 --> 00:05:06,700 use certificates issued by certification authorities which are currently not available from our computer 58 00:05:08,660 --> 00:05:09,940 as we can see. 59 00:05:10,250 --> 00:05:15,170 We have a warning that although the certificate is issued by someone whom we know we're not able to 60 00:05:15,170 --> 00:05:21,470 verify this the certificate could have been revoked in the meantime. 61 00:05:21,530 --> 00:05:26,390 We did not have this problem in the case of the subordinate's certification authority but we'll talk 62 00:05:26,390 --> 00:05:27,630 about that later. 63 00:05:34,380 --> 00:05:41,030 We already know what certificates in accordance with the x 5 0 9 standard contain. 64 00:05:41,210 --> 00:05:52,060 We had an opportunity to very accurately investigate all files recorded in this certificate. 65 00:05:52,060 --> 00:05:58,430 We have also seen that certificates are digitally signed by the certification authorities issuing them. 66 00:05:58,450 --> 00:06:04,680 We know that changing a digitally signed document will automatically invalidate the signature. 67 00:06:04,690 --> 00:06:07,130 We know how to verify digital signatures. 68 00:06:08,830 --> 00:06:14,140 The contents read from the details of the certificate are reliable. 69 00:06:14,240 --> 00:06:16,930 No one could alter them on their own. 70 00:06:16,950 --> 00:06:22,500 The recipient of the certificate cannot for example change the purpose of or extend the period of its 71 00:06:22,500 --> 00:06:23,380 validity. 72 00:06:24,290 --> 00:06:30,050 Before we analyze the lifecycle of a certificate Let's go back for a moment to the root certification 73 00:06:30,050 --> 00:06:31,000 authority. 74 00:06:33,400 --> 00:06:39,580 We don't need to have some certificates installed when for example we connect to a bank's website for 75 00:06:39,580 --> 00:06:42,820 some reason we already trust them. 76 00:06:42,880 --> 00:06:45,560 The relationship of trust started somewhere. 77 00:06:45,790 --> 00:06:46,900 Let's think about where 78 00:06:49,660 --> 00:06:54,430 if we had components which are called certificates to the administrative console and they will even 79 00:06:54,430 --> 00:06:57,320 be certificates from our own account. 80 00:06:57,330 --> 00:07:05,140 It turns out that we as a user of a given computer trust quite a large number of certification authorities. 81 00:07:05,240 --> 00:07:06,570 Where did this come from. 82 00:07:07,790 --> 00:07:14,950 This is in trust every computer during installation automatically starts to trust specific certification 83 00:07:14,950 --> 00:07:18,690 authorities. 84 00:07:18,900 --> 00:07:25,290 These are trusted root certification authorities their certificates are on the list in the stores which 85 00:07:25,290 --> 00:07:30,650 are created during installation of an operating system. 86 00:07:30,660 --> 00:07:37,040 Here we have for example certificates associated with Microsoft for example permits authenticating the 87 00:07:37,040 --> 00:07:40,840 code signed by Microsoft here. 88 00:07:40,850 --> 00:07:48,710 Also certificates from the company such as thoughts and assign these are corporations which operate 89 00:07:48,710 --> 00:07:50,470 on the certificate market. 90 00:07:50,650 --> 00:07:53,180 There are publicly available certification authorities 91 00:07:56,000 --> 00:08:02,810 if any company buys now a certificate from Verisign we will trust it because a certificate from the 92 00:08:02,810 --> 00:08:07,340 various signed certification authority is on the list of certificates which our computer automatically 93 00:08:07,340 --> 00:08:17,200 trusts and interesting fact is that a vast majority of the certificates shown are really unnecessary. 94 00:08:17,320 --> 00:08:24,990 If we let 4 or 5 certificates everything would still work in the same way as to date all other certificates 95 00:08:24,990 --> 00:08:28,220 or for maintaining backwards compatibility. 96 00:08:28,360 --> 00:08:33,070 Just in case some of these certificates have even expired some time ago.