WEBVTT 00:00.000 --> 00:17.000 We have started with our next tool. 00:17.000 --> 00:37.000 Hello. Welcome to Agnes Certificates with Free IPA. 00:37.000 --> 00:44.000 I am Senior Technical Account Manager in Dreadhat. 00:44.000 --> 00:50.000 My colleague is José Ángel de Ustos. He is Senior Specialist Solutions Architect. 00:50.000 --> 00:52.000 Also at Dreadhat. 00:52.000 --> 00:55.000 Here is the summary of what we will see. 00:55.000 --> 00:58.000 We will start with another video of Agnes Certificates with the data. 00:58.000 --> 01:00.000 We will see the features of the protocol. 01:00.000 --> 01:06.000 We continue with Motem Deklayan. We will see how to do this client, the limitations, 01:06.000 --> 01:10.000 how system D can help us to manage all this process. 01:10.000 --> 01:14.000 We continue with Ademo with Motem D. 01:14.000 --> 01:17.000 An José Ángel will continue with Sermanager. 01:17.000 --> 01:22.000 The demonstration of Sermanager and finish with Conclusions. 01:23.000 --> 01:30.000 In 2024, Digital PKI and Tras reported approximately 38% of organizations 01:30.000 --> 01:36.000 are using manual procedures to track and manage certificates 01:36.000 --> 01:39.000 and updated on legacy methods. 01:39.000 --> 01:43.000 In this case, a lot of limitations that we already know 01:43.000 --> 01:47.000 like is an efficient process. It is also so much complex, 01:47.000 --> 01:51.000 and time demanding, and they depend on the human error. 01:51.000 --> 01:55.000 This can lead us to a significant impact, 01:55.000 --> 01:58.000 and painful of that, as we know. 01:58.000 --> 02:01.000 For example, we can discuss a lot of trials, 02:01.000 --> 02:04.000 but reputation or availability of services. 02:04.000 --> 02:07.000 Experts or locations are hard-significant impact, 02:07.000 --> 02:12.000 and Agmecon to help to solve all these problems. 02:12.000 --> 02:15.000 And it was designed by Internet Security Research Group, 02:15.000 --> 02:21.000 for their free CA, that it's in clip, 02:21.000 --> 02:23.000 and it's enabling the automation of issuance 02:23.000 --> 02:26.000 and running well of certificates. 02:26.000 --> 02:29.000 It has removed any kind of human interaction 02:29.000 --> 02:33.000 and all the human errors that can be introduced. 02:33.000 --> 02:38.000 Okay, traditional process to manage certificates. 02:38.000 --> 02:42.000 It's a very tedious one, and involves a lot of steps, 02:42.000 --> 02:46.000 rights and rights CSRs, who meet the same two trusted CA, 02:46.000 --> 02:49.000 through phone issues, via manual domain validation, 02:49.000 --> 02:54.000 waiting time for the CA, copies, or to server, install, validate, 02:54.000 --> 02:58.000 monitor and track, bring you, and start again, all the process. 02:58.000 --> 03:03.000 And the Agmecon price by two parties, at either server and client, 03:03.000 --> 03:06.000 and will perform all the steps completely automatically, 03:06.000 --> 03:11.000 and these are avoiding all the manual and processes 03:11.000 --> 03:13.000 that it's really a role-prone. 03:13.000 --> 03:17.000 With Agmecon free path of taxier, you can deploy an automated pay-kai 03:17.000 --> 03:22.000 with low cost and let it be a very little effort. 03:22.000 --> 03:25.000 Free-bound with Agmecon provides in short life-time certificates, 03:25.000 --> 03:28.000 that by default are three months, but are configurable. 03:28.000 --> 03:32.000 And this is to be in line with the free open source, 03:32.000 --> 03:34.000 let's include profile. 03:34.000 --> 03:37.000 And I'm now using a challenge on response authentication mechanisms. 03:37.000 --> 03:41.000 Mechanics to prove that the client has the ownership of the domain, 03:41.000 --> 03:45.000 is can be done via production of HTTP resources on the origin, 03:45.000 --> 03:47.000 or via creation of a DNS record, 03:47.000 --> 03:51.000 which is to prove that the origin is legit. 03:51.000 --> 03:56.000 Now, José Agé, we'll continue with overview of protocol. 03:56.000 --> 03:57.000 Yeah. 03:57.000 --> 03:58.000 Thank you. 03:58.000 --> 04:02.000 So, request must be authenticated. 04:02.000 --> 04:05.000 Because who has taught me for requests of certificate 04:05.000 --> 04:08.000 for a first-end.org organization? 04:08.000 --> 04:10.000 An impersonate that organization? 04:10.000 --> 04:12.000 How this is done? 04:12.000 --> 04:16.000 AACM protocol incorporates two challenges, 04:16.000 --> 04:19.000 one-basin dinners and the other in STTBS. 04:19.000 --> 04:22.000 We're going to see the STTBS, 04:22.000 --> 04:24.000 which is what's similar to the DBS. 04:24.000 --> 04:29.000 So, the entity using the certificate is the ACM server. 04:29.000 --> 04:33.000 And the one requesting for the certificate is the ACM client. 04:33.000 --> 04:37.000 So, when they talk together, they interchange the public keys. 04:37.000 --> 04:40.000 So, the server creates an ounce, 04:40.000 --> 04:43.000 a specific information who sends to the client, 04:43.000 --> 04:48.000 then the client encrypts this ounce using its private key 04:48.000 --> 04:54.000 and exposes this specific entity file at the domain. 04:54.000 --> 04:56.000 For instance, a sample.com here, 04:56.000 --> 05:01.000 then the server gets this entity file. 05:01.000 --> 05:04.000 They keep this using the public key for the client 05:04.000 --> 05:08.000 and compares with the notes he sends to the client. 05:08.000 --> 05:13.000 If both are the same, the chance is solved. 05:13.000 --> 05:18.000 So, the public key for the client is authenticated and validated 05:18.000 --> 05:21.000 to ask for certificates for the domain. 05:21.000 --> 05:26.000 To ask to renew and even to remove them. 05:26.000 --> 05:28.000 The revocation is the same, 05:28.000 --> 05:32.000 because the key is the public key for the client has been authenticated. 05:32.000 --> 05:36.000 So, he performs a request for revocation 05:36.000 --> 05:39.000 and sends to the server. 05:39.000 --> 05:42.000 The server validates the key and then revops the certificate 05:42.000 --> 05:45.000 and includes this certificate in the serial 05:45.000 --> 05:48.000 just all the clients for the site can check 05:48.000 --> 05:51.000 if the certificate is valid or not. 05:51.000 --> 05:54.000 So, now my colleagues will introduce you 05:54.000 --> 05:58.000 about the FIPA implementation. 05:58.000 --> 06:02.000 Okay, Agma by default is developed on free path of taxiA 06:02.000 --> 06:05.000 and then every gate is a deployment wide operation 06:05.000 --> 06:07.000 because it is the project automatically 06:07.000 --> 06:11.000 in all the servers that have the serial installed. 06:11.000 --> 06:14.000 And this happens because it is in the LWL replicated database 06:15.000 --> 06:18.000 and this can be managed with EPA by managed command. 06:18.000 --> 06:21.000 It is important to remember that a lot of certificates 06:21.000 --> 06:23.000 can accommodate over time. 06:23.000 --> 06:27.000 So, you need a process to automatically pull 06:27.000 --> 06:31.000 or pull or push certificates. 06:31.000 --> 06:35.000 This is implemented with random serial numbers version 3. 06:35.000 --> 06:37.000 This can be done automatically, 06:37.000 --> 06:41.000 but the same can be enabled in installations 06:42.000 --> 06:45.000 with the sequential serial numbers certificates. 06:45.000 --> 06:48.000 That is pruning mechanisms need to be done manually, 06:48.000 --> 06:50.000 but it is also possible. 06:50.000 --> 06:52.000 And switch is expected to come from 06:52.000 --> 06:54.000 installations with sequential serial numbers 06:54.000 --> 06:59.000 to random serial numbers in the near future. 06:59.000 --> 07:01.000 Okay, modern this, 07:01.000 --> 07:03.000 the Apache module that are providing 07:03.000 --> 07:06.000 as a self-certificates from your domains, 07:06.000 --> 07:09.000 gathered from NSEA that are supporting them protocol. 07:09.000 --> 07:13.000 It implements a robust OCSP protocol stumbling, 07:13.000 --> 07:16.000 stumbling is the method by which it is not the browser 07:16.000 --> 07:17.000 who contact the CA. 07:17.000 --> 07:19.000 It is the web server instead. 07:19.000 --> 07:22.000 And it enables a fast-page loading. 07:22.000 --> 07:25.000 In this way, Apache are checking status of certificates 07:25.000 --> 07:27.000 regular in the background. 07:27.000 --> 07:29.000 And this is a process that is needed to found 07:29.000 --> 07:30.000 in the locations. 07:30.000 --> 07:33.000 The modern features, the main features are 07:33.000 --> 07:34.000 certificate requests. 07:34.000 --> 07:36.000 In terms of protocol, as we say, 07:37.000 --> 07:39.000 automatic certificate renewal for 07:39.000 --> 07:42.000 expediting also for revocated certificates. 07:42.000 --> 07:44.000 Revocated is a really new feature in 07:44.000 --> 07:46.000 the last release of modern D. 07:46.000 --> 07:48.000 While cartetificate support, 07:48.000 --> 07:51.000 you can also monitor certificate status, 07:51.000 --> 07:53.000 OCSP stumbling and denotification 07:53.000 --> 07:57.000 when cells are about to expire or being revocated. 07:59.000 --> 08:01.000 As a fact, well, a state 08:01.000 --> 08:04.000 the new version of modern D will enable 08:04.000 --> 08:07.000 an annual WNR, BoquetoStatus, is observed. 08:07.000 --> 08:09.000 But you need a graceful reload for the 08:09.000 --> 08:12.000 HTTP server to put the certificates in place 08:12.000 --> 08:14.000 in the running configuration. 08:14.000 --> 08:17.000 It's great full, so it does not interrupt 08:17.000 --> 08:19.000 the ongoing request. 08:19.000 --> 08:23.000 And this are the main parameters that you can configure. 08:23.000 --> 08:24.000 Then it's stumbling, it's to enable 08:24.000 --> 08:27.000 us to be stumbling at the level of the patch server. 08:27.000 --> 08:30.000 And it's checking terval is the interval by which 08:30.000 --> 08:32.000 HTTP will refresh the HTTP response 08:32.000 --> 08:35.640 be response from any certificates that are installed. 08:35.640 --> 08:37.840 It's the minimum time for the stipulate to notice 08:37.840 --> 08:40.760 if there are any change in the certificates. 08:40.760 --> 08:43.720 Then the renew window is the percentage of time 08:43.720 --> 08:46.320 before the expiration date that the certificate 08:46.320 --> 08:48.360 is able to be renewed. 08:48.360 --> 08:52.880 If we put 1%, it's 1%, before the expiration date. 08:52.880 --> 08:55.960 That is, in this case, in the example of 20 minutes. 08:55.960 --> 08:57.440 And then the stop-dent renewal window 08:57.440 --> 09:01.680 is the minimum time to retrieve an OCSP fresh response 09:01.680 --> 09:03.680 that is subtracted to the default time 09:03.680 --> 09:05.080 that it's 12 hours. 09:05.080 --> 09:09.520 If we set this to 99%, the substrate to 12,000, 09:09.520 --> 09:12.480 this 99%, gives us approximately 7 minutes. 09:16.320 --> 09:21.320 OK, I say previously, you need to reload the HTTP service 09:21.320 --> 09:24.560 to be able to put the certificates in the running configuration, 09:24.560 --> 09:29.520 but it will be nice to not have to do this periodically, 09:29.520 --> 09:32.680 instead to this only when it is reneeded 09:32.680 --> 09:35.680 and your absence of certificates to be enabled. 09:35.680 --> 09:37.080 You can do that with systemD. 09:37.080 --> 09:38.400 With systemD, you can manage 09:38.400 --> 09:42.880 each specific file exists in your server. 09:42.880 --> 09:46.120 And if this file exists, the system detects that this file exists, 09:46.120 --> 09:48.240 you can trigger some actions. 09:48.240 --> 09:51.720 In this case, you can trigger a reload of the service. 09:51.720 --> 09:53.640 This can be combined with our archives, 09:53.640 --> 09:57.440 also, so you can check multiple paths in your server. 09:57.440 --> 10:00.160 And you can also multiple manage domains. 10:00.160 --> 10:03.120 So you can have a multi-site web server 10:03.120 --> 10:06.400 that are completely automated and scalable. 10:06.400 --> 10:08.880 In with that, you can have all the complete lifecycle 10:08.880 --> 10:11.800 covered. 10:11.800 --> 10:14.760 OK, this is a demonstration about how to how 10:14.760 --> 10:16.880 is going to run a one-expired certificate. 10:27.540 --> 10:30.440 You can just navigate it too, 10:31.640 --> 10:34.440 and then that means we can go here. 10:39.020 --> 10:42.320 We will do this for sure. 10:51.440 --> 10:54.080 We can do the same. 10:54.080 --> 10:56.800 On the other hand. 10:57.440 --> 11:09.240 I think they left. 11:09.240 --> 11:30.920 Okay fine. 11:30.920 --> 11:32.920 Thank you. 11:32.920 --> 11:34.920 Thank you. 12:00.920 --> 12:12.920 Thank you. 12:12.920 --> 12:16.920 Sorry for this. 12:16.920 --> 12:26.920 Okay. 12:26.920 --> 12:34.920 Here you can see that the certificate is being renewed in 30 seconds. 12:34.920 --> 12:36.920 The certificate will be expired. 12:36.920 --> 12:40.920 You've got the certificates of your website. 12:40.920 --> 12:48.920 The certificate is configured on the website. 12:48.920 --> 12:50.920 You can also see the expiration date. 12:50.920 --> 13:02.920 If it's one. 13:02.920 --> 13:08.920 So the certificate is market to be renewed in a few minutes, a few seconds. 13:08.920 --> 13:19.920 If you return to empty status, the renewal time has been passed. 13:19.920 --> 13:21.920 Right now, it's being renewed. 13:21.920 --> 13:25.920 And you have the certificates put in place. 13:25.920 --> 13:29.920 The certificate has been raised by the. 13:29.920 --> 13:33.920 And you have that configured in your Apache server. 13:33.920 --> 13:47.920 And the expiration date is being updated. 13:47.920 --> 13:49.920 Okay. 13:49.920 --> 13:51.920 For the rocket certificate, it's more or less the same. 13:51.920 --> 13:55.920 You can see down the latest pistachios for both. 13:55.920 --> 13:57.920 The target. 13:57.920 --> 13:59.920 In 40 seconds. 13:59.920 --> 14:01.920 This will be refreshed. 14:01.920 --> 14:03.920 You are going to robot one certificate. 14:03.920 --> 14:05.920 You give it a reason. 14:05.920 --> 14:09.920 You can see one of them is the rocket. 14:09.920 --> 14:11.920 Osis pistachios still not refreshing the response. 14:11.920 --> 14:13.920 So you can see the ticket is good. 14:13.920 --> 14:15.920 But you can call the osis response. 14:15.920 --> 14:19.920 And you can check that this is the rocket. 14:19.920 --> 14:21.920 This is the expiration date. 14:21.920 --> 14:27.920 Also. 14:27.920 --> 14:33.920 And in 10 seconds, the certificate will be automatically. 14:33.920 --> 14:35.920 The detected as a rocket. 14:35.920 --> 14:37.920 You can see the osis pistachios down. 14:37.920 --> 14:39.920 That will be changed. 14:39.920 --> 14:41.920 This is now a rocket. 14:41.920 --> 14:45.920 Information in the STP error lock. 14:45.920 --> 14:49.920 And now the taxi A is running when the. 14:49.920 --> 14:53.920 The certificate. 14:53.920 --> 14:57.920 The patient takes a little few seconds. 14:57.920 --> 15:07.920 Okay. 15:07.920 --> 15:09.920 The certificate has status is good. 15:09.920 --> 15:13.920 The new one has ratio by the taxi A. 15:13.920 --> 15:15.920 And you can see it in the entity management. 15:15.920 --> 15:17.920 The new certificate is. 15:17.920 --> 15:19.920 Is generated. 15:19.920 --> 15:25.920 And you can see the new expression date has been updated. 15:25.920 --> 15:31.920 And now it's marketers. 15:31.920 --> 15:35.920 So they get status is good. 15:35.920 --> 15:37.920 Okay. 15:37.920 --> 15:43.920 Continue this. 15:43.920 --> 15:47.920 So we have seen the. 15:47.920 --> 15:51.920 How free IPA is working with. 15:51.920 --> 15:53.920 Client for traditional applications. 15:53.920 --> 15:57.920 Because we can use this with our applications running on Kubernetes. 15:57.920 --> 16:01.920 For that, we are going to use the thermal operator. 16:01.920 --> 16:02.920 Okay. 16:02.920 --> 16:05.920 This is a project for the CloudNet information. 16:05.920 --> 16:07.920 And was initiated in 2020. 16:07.920 --> 16:09.920 And it reaches its maturity level. 16:09.920 --> 16:11.920 Last year on September. 16:11.920 --> 16:13.920 Okay. 16:13.920 --> 16:15.920 We can use different issuers. 16:15.920 --> 16:19.920 To get certificate is front with a thermal operator. 16:19.920 --> 16:23.920 Did you see the matrix for the use as you can see free IPA. 16:23.920 --> 16:24.920 Okay. 16:24.920 --> 16:26.920 But in this case, the use it. 16:26.920 --> 16:28.920 Although where is free. 16:28.920 --> 16:32.920 IPA is at my protocol. 16:32.920 --> 16:36.920 Because free IPA can use the at my protocol. 16:36.920 --> 16:38.920 So we got. 16:38.920 --> 16:42.920 We are going to use the issue from third mana. 16:42.920 --> 16:46.920 We can incorporate our private server. 16:46.920 --> 16:48.920 Our private. 16:48.920 --> 16:50.920 And. 16:50.920 --> 16:52.920 To use the certificate. 16:52.920 --> 16:56.920 And the root of the trust chain for the certificate. 16:56.920 --> 16:58.920 For that, we need to use the trust. 16:58.920 --> 17:00.920 To get it with third mana. 17:00.920 --> 17:02.920 Okay. 17:02.920 --> 17:06.920 Just to track the certificate for our PKI. 17:06.920 --> 17:10.920 So a few things about the third mana. 17:10.920 --> 17:14.920 By default, the certificates are used for 90 days. 17:14.920 --> 17:18.920 The default is standard in the asset grid and the. 17:19.920 --> 17:22.920 Unless the renew before field. 17:22.920 --> 17:24.920 Has not been said. 17:24.920 --> 17:26.920 Okay. 17:26.920 --> 17:30.920 The minimum life for a certificate was one hour. 17:30.920 --> 17:32.920 Okay. 17:32.920 --> 17:34.920 Other certificates by default will be renew after. 17:34.920 --> 17:36.920 Two of the. 17:36.920 --> 17:37.920 The few times. 17:37.920 --> 17:38.920 Uh, the third time. 17:38.920 --> 17:39.920 I was. 17:39.920 --> 17:41.920 Uh, past. 17:41.920 --> 17:45.920 So at that moment, so a mana operator will try to renew the certificate. 17:45.920 --> 17:46.920 Okay. 17:46.920 --> 17:48.920 I'm going to to renew. 17:48.920 --> 17:50.920 If some problem arises. 17:50.920 --> 17:51.920 In that. 17:51.920 --> 17:54.920 We can reuse the certificate on the same cost. 17:54.920 --> 17:56.920 The certificate is going to spire. 17:56.920 --> 17:58.920 It's one of them. 17:58.920 --> 18:00.920 The data between the certificate and the certificate. 18:00.920 --> 18:01.920 Specifications. 18:01.920 --> 18:03.920 Is third mana are not much in so in the case. 18:03.920 --> 18:04.920 And in certificate. 18:04.920 --> 18:05.920 We'll be requested. 18:05.920 --> 18:06.920 And if the sec. 18:06.920 --> 18:09.920 The secret in which the certificate is kept. 18:09.920 --> 18:11.920 Incubinetic is missing automatically. 18:11.920 --> 18:14.920 Third mana operator will ask for an certificate. 18:14.920 --> 18:18.920 But we cannot send a replication request from third mana. 18:18.920 --> 18:22.920 Okay. 18:22.920 --> 18:24.920 So we are see. 18:24.920 --> 18:27.920 Uh, the demonstration about how to use. 18:27.920 --> 18:28.920 Uh, to issue. 18:28.920 --> 18:29.920 Sorry. 18:29.920 --> 18:31.920 Certificates from. 18:31.920 --> 18:33.920 Third mana operator. 18:33.920 --> 18:36.920 Okay. 18:36.920 --> 18:38.920 A start from the beginning. 18:38.920 --> 18:39.920 Sorry. 18:39.920 --> 18:42.920 Okay. 18:43.920 --> 18:45.920 Now this is the operator. 18:45.920 --> 18:46.920 This is the cluster issue. 18:46.920 --> 18:48.920 It's the frame IPA server. 18:48.920 --> 18:52.920 Now we're going to lock into free IPA server. 19:00.920 --> 19:03.920 That's as the certificate is issued. 19:03.920 --> 19:06.920 Now we're going to deploy a simple application. 19:06.920 --> 19:14.920 I see the one. 19:14.920 --> 19:16.920 Now we're going to check that the application is running. 19:16.920 --> 19:21.920 In the Kubernetes. 19:21.920 --> 19:22.920 Okay. 19:22.920 --> 19:24.920 And now we're going to deploy an English resource. 19:24.920 --> 19:31.920 Just to suppose the application to the outside world. 19:31.920 --> 19:38.920 This triggers a certificate request to free IPA. 19:38.920 --> 19:41.920 So as you see, it's there in the very field. 19:41.920 --> 19:42.920 It's false. 19:42.920 --> 19:45.920 This is requesting the certificate and solid challenge. 19:45.920 --> 19:46.920 One is true. 19:46.920 --> 19:48.920 The certificate will be issued. 19:48.920 --> 19:51.920 I'm put into the application just to be used. 19:51.920 --> 19:52.920 Okay. 19:52.920 --> 19:54.920 That just means true. 19:54.920 --> 19:55.920 We'll refresh. 19:55.920 --> 19:59.920 And now we see a new certificate in the free IPA server. 19:59.920 --> 20:02.920 That one. 20:02.920 --> 20:06.920 This is all the information we have about the certificate. 20:06.920 --> 20:09.920 And now we're going to connect to the application. 20:09.920 --> 20:11.920 This is the external road. 20:11.920 --> 20:13.920 This is a silly one. 20:13.920 --> 20:17.920 And we can see the new certificate. 20:17.920 --> 20:19.920 You see by free API. 20:19.920 --> 20:22.920 This was all done automatically. 20:22.920 --> 20:31.920 Okay. 20:31.920 --> 20:36.920 As we say that the minimum time for the certificate is one hour. 20:36.920 --> 20:39.920 We can't test it here for one hour. 20:39.920 --> 20:41.920 Just to see how it inspires. 20:41.920 --> 20:49.920 We're going to see how to reuse an certificate when we delete the certificate. 20:49.920 --> 20:51.920 Okay. 20:51.920 --> 21:06.920 This is the certificate in the terminal operator. 21:06.920 --> 21:07.920 This is the application. 21:07.920 --> 21:17.920 With the product certificate we have created. 21:17.920 --> 21:18.920 Free API. 21:18.920 --> 21:23.920 They have the certificates. 21:23.920 --> 21:28.920 Only one. 21:28.920 --> 21:34.920 Now we're going to get the secrets from the application to delete it. 21:34.920 --> 21:36.920 Now we're going to delete the ticket. 21:36.920 --> 21:37.920 That triggers an event. 21:37.920 --> 21:39.920 The terminal operator. 21:39.920 --> 21:40.920 Checked the secret is missing. 21:40.920 --> 21:45.920 So he's going to request an certificate for the application. 21:45.920 --> 21:48.920 So I'm going to delete the secret. 21:48.920 --> 21:49.920 By mistake. 21:49.920 --> 21:51.920 This is no problem. 21:51.920 --> 21:53.920 Automatically we renew it. 21:53.920 --> 21:56.920 You see that this is the enforce. 21:56.920 --> 21:57.920 The state. 21:57.920 --> 21:58.920 So there's no. 21:58.920 --> 21:59.920 Now it's true. 21:59.920 --> 22:03.920 The new certificate has been issued. 22:03.920 --> 22:05.920 Now we're going to revoke the old one. 22:05.920 --> 22:07.920 Because it's no longer valid. 22:07.920 --> 22:09.920 We don't have it. 22:09.920 --> 22:17.920 As you can see here, there are two certificates. 22:17.920 --> 22:18.920 One goes to revoke. 22:18.920 --> 22:19.920 This is the old one. 22:19.920 --> 22:20.920 Ah. 22:20.920 --> 22:23.920 The new one. 22:23.920 --> 22:25.920 This is all information we have. 22:25.920 --> 22:30.920 At the API. 22:30.920 --> 22:34.920 And now we can check that this is a new certificate. 22:34.920 --> 22:40.920 We're checking the dates. 22:40.920 --> 23:01.920 And we have all the information again in the thermanage operator. 23:02.920 --> 23:04.920 So we have here some resources. 23:04.920 --> 23:07.920 There are all in the slides in the platform. 23:07.920 --> 23:10.920 In case you want to look for more information. 23:10.920 --> 23:11.920 Okay. 23:11.920 --> 23:15.920 So we have seen how using free API. 23:15.920 --> 23:16.920 At my protocol. 23:16.920 --> 23:19.920 We can easily manage the lifecycle of our certificates. 23:19.920 --> 23:22.920 We don't need any human. 23:22.920 --> 23:24.920 Or hardly any human integration. 23:24.920 --> 23:27.920 We must only to create the application. 23:27.920 --> 23:31.920 And other certificates will be issued on renewables. 23:31.920 --> 23:32.920 There is a fire. 23:32.920 --> 23:34.920 We have seen two examples. 23:34.920 --> 23:36.920 One about traditional application. 23:36.920 --> 23:37.920 Running in Apache. 23:37.920 --> 23:38.920 But for instance. 23:38.920 --> 23:41.920 Or for application including in Kubernetes. 23:41.920 --> 23:42.920 It doesn't matter. 23:42.920 --> 23:43.920 What can application we have. 23:43.920 --> 23:47.920 If we have an ACM client. 23:47.920 --> 23:50.920 Because we can use our application. 23:50.920 --> 23:52.920 Together with free IPA. 23:53.920 --> 23:56.920 To keep our certificates updated. 23:56.920 --> 23:57.920 Okay. 23:57.920 --> 24:01.920 And what's more important that we can have our. 24:01.920 --> 24:02.920 Uh. 24:02.920 --> 24:03.920 Uh. 24:03.920 --> 24:04.920 Uh. 24:04.920 --> 24:05.920 Uh. 24:05.920 --> 24:06.920 Uh. 24:06.920 --> 24:07.920 Uh. 24:07.920 --> 24:08.920 Uh. 24:08.920 --> 24:09.920 Uh. 24:09.920 --> 24:10.920 Uh. 24:10.920 --> 24:11.920 Uh. 24:11.920 --> 24:12.920 Uh. 24:12.920 --> 24:13.920 Uh. 24:13.920 --> 24:14.920 Uh. 24:14.920 --> 24:15.920 Uh. 24:15.920 --> 24:17.920 Uh. 24:17.920 --> 24:18.920 Uh. 24:18.920 --> 24:19.920 Uh. 24:19.920 --> 24:20.920 Uh. 24:20.920 --> 24:21.920 Uh. 24:21.920 --> 24:22.920 Uh. 24:22.920 --> 24:23.920 Uh. 24:23.920 --> 24:24.920 Uh. 24:24.920 --> 24:25.920 Uh. 24:25.920 --> 24:27.420 Uh. 24:27.420 --> 24:28.420 Uh. 24:28.420 --> 24:29.920 Uh. 24:29.920 --> 24:30.920 Uh. 24:30.920 --> 24:32.920 Uh. 24:32.920 --> 24:34.920 Uh. 24:34.920 --> 24:35.920 Uh. 24:35.920 --> 24:36.920 Here. 24:36.920 --> 24:37.920 What up? 24:37.920 --> 24:39.920 Uh. 24:39.920 --> 24:40.920 Uh. 24:40.920 --> 24:41.920 Uh. 24:41.920 --> 24:43.920 Uh. 24:43.920 --> 24:45.920 Hello. 24:45.920 --> 24:47.920 Yeah. 24:47.920 --> 24:56.920 Can we use this workflow with other global CAs instead of Let's Angry? 25:00.920 --> 25:08.920 So what the question was, can we use this workflow with other global CAs instead of Let's Angry? 25:08.920 --> 25:14.920 This is not Let's Angry. This is your deployment of free IDEA CAs. 25:14.920 --> 25:20.920 This is like your stuff. You can get it in just use the same standard at now. 25:20.920 --> 25:24.920 That Let's Angry implemented for the public.