Name: Unpacking Certificate Changes: Live Expert Q&A
Uploaded: 2025-05-06T18:31:03.792Z
Duration: 56 min 16 s
Description: Unpacking Certificate Changes: Live Expert Q&A

Transcript for "Unpacking Certificate Changes: Live Expert Q&A": Hello, everyone. We're gonna get started in another minute or so. We have a lot of people joining, so stand by and we'll be with you in a few minutes. Super. Hi, everyone. Looks like we've got a good, amount of people here. So we're gonna get started in about thirty seconds. So just stand by. We'll be right back. Alright. Hello, everyone. And thank you for joining our webinar today called unpacking certificate changes, with a live q and a session to be followed by our very short, presentation to give you some background on this topic. I'm your host, Dean Coclin, senior director of industry strategy here at DigiCert, one of the largest public certificate authorities in the world, And I'm also chair of the CA/B Forum. And I'm joined by a very special guest today, a long time friend and an industry colleague, mister Dimitris Zacharopoulos from an organization called HARICA, which is a public CA in Greece. He is the PKI manager there, and he's also, the chair of the server certificate working group of the CAB forum, and he is joining us live from Thessaloniki, Greece. Hello, Dimitris. And as we say in Greek, kanispeta. Thank you, Dean. Looking forward to this conversation today on such an important topic. As am I, and I'm sure our audience is as well. So before we get started, Dimitris, tell our audience a little bit about, what HARICA is and what you do there. Sure. So HARICA was established in 02/2006. It is supported by a nonprofit company in Greece called the DuNet, Greek Universities Network. Well, over the years, it gained trust not only as a public CA offering TLS, SMIME, cosigning certificates, but also as a qualified trust service provider offering qualified certificates under the EIDAS trust framework. So my responsibilities include managing the trust services, the leading compliance. Yep. Basically, making sure changes to hard cost processes are made on time and according to industry rules and customer demands. That's mostly it. Fantastic. Well, thanks. It sounds like you have a really interesting organization and a great responsibility there, and I think you're very well qualified to join us to talk about this very important topic. So without further ado, let's get started because we have hundreds, maybe even a thousand participants, on the call right now that are very interested in this. So why don't we start with some background? So why don't you start by telling us what happened at the cap forum meeting last October, that precipitated all this news? What did Apple announce? Well, okay. I guess people in this industry expected the certificate of validity period issue to be picked up by either Chrome or Apple at some point following the first reduction taking place in 2019. So during the, recent CA/B Forum face to face meeting in Seattle, number 63, if I remember, Apple presented a plan to reduce the public TLS certificate lifetimes from the current three hundred ninety eight days to forty seven days. Prior to this, Chrome, the Chrome, browser team had suggested a movement down to 90. And this is what the industry kind of, was kind of expecting. Okay. So it was a bit of a surprise to hear an even further reduction in the certificate validity. And the proposal didn't stop just at the reduction of the certificate validity period. It also reduced the allowed reuse period of validated information, both for domain names and identity. This means that organizations that were validated every eight hundred and twenty five days would have to be re vetted every three hundred ninety eight days, so twice as, as much. And domain names would be allowed to be reused up to ten days from three hundred ninety eight days, which is today. So that's, that that was the announcement from Apple. I I remember that meeting very well. Why there's a lot of questions coming in about this exact topic. Why are browsers pushing for shorter validity periods for public TLS certificates? Okay. So although the this ballot was mainly supported by browsers, there were also some CAs in favor of those changes. And it was a very interesting and long six month conversation about the security benefits and trade offs in terms of costs, in terms of, convenience, subscriber learning curve for automation, you know, TLS certificates being used for many different use cases that they should not be used at and so on. So there was a lot of conversation, very spirited conversations in some cases. But, you know and people, of course, can find these discussions publicly as the CA/B Forum keeps its mailing list archive open for transparency reasons. So the supporters of this ballot focused on several reasons, but probably the biggest one was the security risk of people transferring or purchasing a domain name, and the previous owner would still have control of a valid certificate that could be used to intercept traffic and decrypt communications. And similarly, it's not just for the transfer of domains, but also for hosting and cloud providers when the domain owner decided to move to another provider. Okay? The previous provider would still have access to, private keys associated with valid TLS certificates and, again, would be able to intercept traffic. That is what the main arguments from the, supporters of the ballot. And I I think the ballot preamble has a very long list of reasons explaining, you know, why it just tries to justify, you know, why the the reduction of certificate is is so important. But, also, another important factor that was, discussed was that, the support of the ballot believe revocation doesn't work at the Internet scale. We had a lot of incidents with, OCSP issues, across different CAs. And, specifically, the two revocation technologies, OCSP and CRL, they both have drawbacks. Okay. That's too big of a topic, of course, to expand. But all the trade offs were discussed in the during the ballot preparation. So the only way to effectively contain these security threats from, longer lived certificates was to reduce their lifetimes. So I think the, the one threat you mentioned, with domain names, with certificates being reacquired and being reused is an attack called bygone SSL. If folks wanna read about that, it's, b y g o n e SSL. And then, of course, those OCSP and CRLs, as you said, do have their drawbacks which, browsers decided to shorten certificate validities and and actually also some CAs were involved in this as well to, mitigate some of those issues. So with these shorter lifetimes, it's going to be virtually impossible to manually manage these types of certificates. The days of Outlook calendar reminders and Excel spreadsheets and maybe even, you know, pagers going off to remind you to replace certificates, those days are gone. I mean, there's just absolutely no way, you're gonna be able to do with it, that method anymore. But there are technologies available to help automate these certificates. One of them is called ACME. Dimitris, can you explain a little bit about what ACME is? Sure. So ACME stands for, automatic certificate management environment. It is, described in RFC, eighty five fifty five. And it is one of many ways in which certificate life cycle management can be achieved in an automated fashion. But I would like to emphasize that a lot of subscribers incorrectly consider that ACME is the only method for which they can automate their certificate management processes. CAs had implemented APIs and automation long before ACME was standardized. Okay? But, of course, each CA had its own API implementation, and it was targeted to their own customers. So ACME just made it easier and, of course, more robust in terms of consistency among CAs. So instead of integrating with a specific set of custom APIs provided by one CA, making it harder to move to another CA, Acme helps subscribers to switch from one CA to another very easily. Now Acme also has a lot of community support, with many extensions, some of which are very important to WebPTC ecosystem. Okay. Of of course, one of the drawbacks is these standards take time for CAs and subscribers to adopt, and implement securely, which is why the pilot also has phased in approach. Doesn't go to forty seven days immediately. So it's spread out in, until 2029, allowing CAs and subscribers prepare their systems for automation. And when we talk about CAs, it would also have to include CA software vendors, and and other, tools that are, linked to the certificate life cycle management. Right. So I think, the keyword for certificate management is gonna be, three keywords, automate, automate, and automate. Those are words that organizations are gonna need to adopt, or embrace as they tackle this issue. So we we talked a little bit about the timeline. Let's talk about this right now so everybody has a clear idea of what's going on here. So as Dimitris said, last October was the discussion starting from Apple. It took a long time to discuss and and change this ballot a little bit to accommodate everyone. But the first milestone is gonna happen in March fifteenth of twenty twenty six. That's when the maximum certificate lifetime is going to change from the current three hundred ninety eight days to two hundred days. In addition, data reuse for domains is going to reduce to two hundred days, and subject information is gonna reduce from eight hundred and twenty five days to three hundred ninety eight days. Now in March of twenty twenty seven, this max certificate validity will go down to one hundred days with the domain information dropping to one hundred days as well. And then finally, in March of twenty twenty nine, the maximum validity of the certificate will drop to the forty seven day number that you've all been hearing about, and the domain validation information is only gonna be valid for ten days. So there's a lot of changes going on here. And it looks like when you look at this timeline, it looks like they skipped a year from 2027 to to 2029. Dimitris, do you know why that happened? Right. So, you know, during the discussion period of this ballot, Apple received feedback from many users and some pushback from CAs, that the original timeline, for 2028 was too aggressive and that, you know, the the ecosystem the the industry needed more time. So the, you know, Apple moved the final milestone to 2029, and I think it's it's pretty reasonable. But just to add a little bit more to that, 2029 is is four years away. And the browsers supporting this ballot were also very, let's say, easy to hear feedback, about this, you know, how the industry adopts this, this sort of lifetimes. So they are willing to reassess, if more concrete, feedback and any of the evidence is, presented to them. I I'm just gonna pause for a second because I see some bunch of questions asking what does maximum data reuse mean. So for example, when you get down to March of twenty twenty nine and it says domain data is only good for ten days, that means that after ten days, we need to refresh that data. It doesn't mean you have to issue a new certificate. It just means that that data is expired and the c will have to generate that data or get that data again. Same goes for subject data information. Subject data will be down to one year, and that would have to be refreshed the next time a certificate is requested. So hopefully that clears that up. Let me let me stress something that I think there's some confusion, especially just looking at some of the questions here. These rules apply to publicly trusted TLS website certificates. Now we've heard a lot from organizations that are using publicly trusted certificates in use cases that don't require this. Publicly trusted website certificates are basically used for browser to server interaction. You know, people going to their bank, going to any website, they need to have their browser to do that, they're connecting to a server resource, They need to have a publicly trusted certificate for that. But if it's something in the back end that's doing server to server communication or internal to the company that does not require a publicly trusted certificate, then you should move to a privately trusted certificate or an internal certificate, that is not regulated by the CA/B Forum rules. In that case, you can do whatever you want. You can set up your own rules for validity periods and length of time. So, this is a misunderstanding. Don't you agree, Dimitris? Yeah. Definitely. And we've seen that in, in several public incidents, so in mass revocation, issues that, see, you had to revoke a a large number of certificates. They found they found it very difficult to change because some of the certificates were used in firewalls or in, in in in non browser, use cases. So, yeah, definitely, this is a common misunderstanding in our industry. If you don't need a certificate to interact with the browser, definitely consider a private PKI. Also, if you have a website that is not accessible to the public Internet, consider switching to a private PKI. In the recent years, okay, we've seen a lot of subscribers using public certificates for domain names that resolve in, IP networks behind firewalls, accessible only by certain IP addresses. You know, even we we've used that before, in in HARICA, in in other, in other setups as well. You know? So using and, also, we've seen use cases, with private DNS servers, okay, that cannot even be reachable for domain validation CAA checks and so on. Okay? This problem, of course, became worse and more amplified when multi perspective issuance cooperation, MPIC, became effective in, on 03/15/2025, very recently, which means that, you know, multiple perspectives of the network need to connect to the browse to the to the web server and and or the DNS server, behind the the website. So thank you. I I'm still seeing people asking questions about the data reuse. So, apparently, I didn't do a good job explaining it. So you wanna give it a shot? Sure. So today's practice is that, domain owner, can do a domain validation, process and basically demonstrate that, they control a domain name space. And then they can issue as many certificates ending with the domain name they have validated for up to a year. They don't need to do the domain validation challenge response type of, thing every day or on every certificate issues. We the CAAs reuse that validation, Okay? As long as the request is authenticated and so and so on and so forth. So that process now will have to go down from one year to first two hundred days, one hundred days, and finally, every ten days. It's making it practical to reuse domain validation. So it's best to automate the domain validation process as you go along the way. That's that's my assessment. And, again, this does not apply to privately or internal certificates. It only applies to publicly trusted certificates that chain up to a root that's in the browser. So I see a lot of confusion coming in about that as well. So let me just pivot for a moment. So unrelated to this change, there are also some Chrome policy changes that were just announced that I don't think many of our listeners are aware of. Can you describe a couple of the new restrictions around public CAs in Chrome? Yeah. Well, I can remember two things, for sure. One is, that, you know, the browsers are mandating that the root hierarchies are, from from known some time ago, single purpose. Meaning that the hierarchy must only issue TLS certificates or SMIME certificates or client authentication certificates and so on. They don't want to have multipurpose hierarchies like we used to have in the, you know, decades ago. And this means, that CAs will have to, that are only using multipurpose hierarchies. They need to apply to the browsers with single purpose hierarchies. So they have to follow this process. I think DigiCert and HARICA, have have already done that, so we're we're good there. And number two, browsers are limiting the maximum lifetime of roots. So, effectively, they will require CAs to rollover root certificates more frequently. Right? So as as you see, this is this is above, push for more agility. Right. I think we'll talk about that a little later. But, of course, they will allow cross signing previous hierarchies. The browsers allow the cross signing process to work, so that that will support the transition and ubiquity problems. But, you know, it's another area that subscribers will need to be prepared and, not rely on specific hard coded issuing CA certificates because the CA may change the issuer at any time and for no reason. So there needs to be agility there. Yeah. And I think one of the use cases that, people may not be aware of going away is client authentication, for Chrome. So that is not gonna be a use case that's gonna be tolerated for public TLS certificates. So those organizations, especially we see it a lot in financial organizations, that use client TLS are gonna need to use a private CA/B Forum hierarchy if they wanna continue using client authentication. So a lot of, a lot of questions coming in. Just again, let me clarify a couple things because, back to the data reuse thing. This is done by the CA/B Forum. It is not done by you, the end user. The CA/B Forum is the one that does all the validation. So all this data reuse stuff applies to the CA/B Forum, which means that we will have to do the domain validation every ten days. So let's say the certificate is good for forty seven days. Yes. We have to validate the domain every ten days. It does not mean you have to come back in and get a new certificate every ten days. Your certificate is good for whatever the validity period is that it was issued for. And when you come back to renew it, it just means that we have to go back and check, the domain validation every as according according to the schedule that's here. This does not apply to BIMI certificates. It only applies to web certificates from the public TLS hierarchy. Alright. We'll get to more of those questions later. So we have four polling questions that we're gonna put up and start asking you before we get to the live q and a. So I'm gonna ask our team to help me, oh, actually, no. I can do it here. So let's see. Okay. Here's the first polling question. And you can answer this live and we'll see the live results as you answer them. What is your biggest concern regarding the new certificate lifetimes? Is it increased operational cost? That means admin overhead. More frequent outages from expired certificates. Inability to automatically renew all TLS or something else. I hope everyone can see those questions. Dimitris, can you see those? I can see those on the right coming, coming in. Yeah. And oh, sorry. You mean the poll? Yes. I can see it. Yep. Okay. Good. I see people are starting to answer that. So, we'll start getting, some results here. And actually, a lot of answers are coming in very quickly here. So, looks like, inability to automatically renew the TLSs are more than half of the responses so far, and it looks like it's equally split. On the second place between increased operational cost and more frequent outages. And then other is getting a very few votes so far. It's definitely a scary, topic, but I think the community and the industry has, has enough time to work on this problem. And we worked on similar problems in the past, when deprecated, when we deprecated SHA-one. I think we also need to, include some more agility when it's, when we're approaching the PQC era. So I don't know if, we have time to to talk a little bit. Yeah. Well, it's interesting because the PQC time frame and this forty seven day time frame in 2029 could actually collide at that time. So having, agile crypto could actually be a benefit for both reasons. Yep. Let's go to another question. Yeah. I'm sorry. Go ahead. No. I I was just thinking that, you know, implementing automation in the certificate management systems is, in the long run, it it does, sort of reduce the costs for maintaining, and managing those certificates, especially when you have hundreds and hundreds of, servers and certificates to manage. And there's no way to do it even even today. And we had one of the basically, a large subscriber, I'm not gonna to to to tell the name, which had, thousands of servers deployed. And they they were very supportive of the automation of the reduction of validity in certificates. Okay. Let's go to the next question. So do you think that shortened certificate lifetimes will improve overall security? Yes, maybe, or no, not really. You know, while people are answering this, Dimitris, I saw a question that came in and said, has there been actually a security incident related to the problems that you mentioned around bygone SSL and, certificate revocation not working? So the researchers mentioned some, some incidents according to their study. You know, these are academic papers. They're, publicly available. People can take a look. But, of course, the the the the main argument here is that, we don't need to wait for something bad to happen, before we take measures to prevent the threats that are, have been documented and they are substantiated. So the the there is a real threat in in some in some cases. And, you know, imagine, in order to intercept communication, between a browser and a server, you need to be able to position yourself in, you know, the proper network layer and all of that. It is they are skillful attacks. Okay? But still, the, the data privacy of, of relying parties and simple users is is is super important. That was the trade off. Yeah. And we've seen, like, in revocation cases when certificates have long lifetimes, they need to be revoked. And if the revocation technologies are not working the way they should be, then you've got an exposure out there of a certificate that is, improperly issued or, revoked for another reason that is now out there for a fairly lengthy time before, it can be, used it might be used for another purpose. So I think this vote is done and we've got, a good amount of people that think, it's no, not really or maybe. That's almost tied, and, less people saying yes, definitely. So that's interesting. Let's go to the next question. Who in your organization will be most impacted by this change? Is it the CISOs? Is it security architects and engineers, IT directors and managers, or a DevOps and platform engineering teams? I think you can only vote for one. So just pick the best answer that, you think would be the right right one here. Definitely looks like security architects and engineers are winning the vote so far, but things are rapidly changing. K. Security architects are still, in the lead here with looks like DevOps and platform number two, IT directors third and and last but not least the CISOs with a very small number of votes there. So you can keep voting while we move on. We have one more question then we're gonna dive right into the q and a. Alright. Let's see. So what type of support would be most helpful for your organization during this transition? Do you wanna see detailed documentation? Do you wanna have training sessions, technical support people, community forums, or a video demo demos of automation setup? This is valuable to us, I think both to HARICA and DigiCert, so we can understand better what kinds of things we can do to help you prepare for this ballot. Now look, this ballot was ratified and is moving forward. This train has left the station, and we have to figure out ways to adapt within our organizations to this rule. And so what do you think is gonna be the best way to help you with this? Please put your voting here. Looks like, video demos is, probably the most popular one followed by detailed documentation, tech support training, and community forums, not so much. Hey, because there's already a lot of those out there. Okay. Very good. So now we're gonna get to the meat of this, webinar. We have about a half hour left. And so we're gonna go to, some of the q and a. And I think I've gone I've been watching these as they've been coming through, and I'm think we've answered some of them, but certainly there's a lot more here. So I'm gonna try to, go through and try to be not repetitive. Let's see. Okay. So I'm just wanna make sure I do this right. Just a question about pricing. Will we get charged each time we update a cert? I mean, I'm gonna answer on behalf of Digicert here. I think and probably most CAs will be basing this on a subscription model where you subscribe for a certain period of time and you can get as many certificates as you need. I don't know. Dimitris, do you wanna answer that or you wanna skip that one? Yeah. I think every CA will have their own, approaches and strategies. But, yeah, definitely, you know, things will start moving from, certificate based, to, subscription based models. Okay. Makes sense. Okay. Let's see what else here. I'm trying to get ones that are not, like, specific to the CA. Here's one. Can you explain how enforcement of this will be done? Are are these changes simply from the issuance perspective while browsers and other language tools will not change? Yes. It will be from the CA side. Basically, the browsers will, do will require CAs to issue certificates that are, up to this, time valid, and they will be monitoring and supervising that. So if a CA issues a certificate even with one second larger than forty seven days, they will be in violation of the rules and, It'll be blocked. They have to file an instant. Yep. Okay. Some people are saying, you know, automating cert updates on our web servers and our own services is very doable, but getting all software vendors to automate for our on prem hosted applications and appliances is scary. Dean, can we put those questions, you know, up on screen, so that we can see how this is settled? Figure out how to do that. Maybe our team in the backstage can help me. If you go to the left in the q q and a, there's a share button, I think. I don't see a oh, I do see a share button. Okay. Here we go. Let's try that. Here we go. There we go. So, yeah. I mean, I think, you know, there's a lot of automation solutions out there for the current web servers, you know, and this is why we recommended earlier that if it's a non web application or it's a back end application that does not require public web server, you really should not be using public web search for that application and switching to internal CAs. But, I also, as Dimitris said, think that CAs have their own automation tools that you can get comfortable with that may be integrated with some of those applications. K. Let's see. I have one. I mean, I sorted it with the the the most upvotes. I think that's it. I will click share, see if it, comes up. Do you see it? Mhmm. Not yet. No? Let me try that. There we go. Okay. There it is. So, 19 different applications that they manually load certificates to. Okay. Not not web servers, but, you know, all these, exotic, nice devices here, you know, just to name a few. And this is the the typical issue we talked, at the beginning where, publicly trusted TLS certificates are used in in use cases that are not browser to server, public Internet server, to browser communication related. So these are the perfect use cases to switch to a private PKI where you control the devices, you manage the the trust stores, and you will have to push the your your private CA routes inside those devices from this controlled environment. The reason why these devices don't work with, they just are not designed to work for public, for the public TLS ecosystem is because the CA must always be in a position to reach these devices from the Internet and do any challenge response, you know, domain validation that is necessary to prove that this that you control this this web server, or they need to access the DNS servers behind those servers, to check for certain CAA records. So if these are not visible to the public Internet, then they should not be using, public TLS certificates. Exactly. Here's another one. Let's see. Will o v and e v validation be impacted as well? Yes. All Dean? Is it me or we've lost Dean? Can you can you hear me? Yep. Okay. I can hear you now. Okay. Sorry. Sounds like I don't know what happened with the audio. Yes. Everyone is impacted by this change. All all certificates, all different types of certificates information, freshness, and domain validation fresh freshness, those are all impacted by this. And so the CA is going to have to, revalidate that information for the timelines that we mentioned. But there is automation for all of these things. The the ACME protocol is a way to automate the the certificate and domain validation practices, but most CAs are linking identity information in that ACME process. So there are a lot of automation already in place. Hey. Here's one for you that, we covered a little bit. Any insights on how to tackle automation for mTLS authentication? So we just, go ahead. You wanna talk about that one? It's a it's a tough issue and the can you hear me, Dean? Yeah. Okay. So it's a tough issue because it is a case by case, issue. So you talked about the banking sector. In the the the PSD two world, banks need to communicate with payment service providers. They have their own processes and their own infrastructure to to do this mutual TLS. They are, in in Europe, they're even required to use qualified web authentication certificates, to do that. And there are tools to tackle that and and, and provision those certificates, but I they don't work very, easily with, with public certificates. So we have separate hierarchies at least in HARICA. We have separate qualified web application certificates to to handle these issues. Right. So here's an interesting question. Will there be any way around this to just skip over it? And the answer is no. You these rules are passed by the CA/B Forum, not enforced by the CA/B Forum. There's a there's a big misconception out there. People say, well, can I go to the CA/B Forum and get an exception? Cap form doesn't grant exceptions. We are a standards organization. We issue standards. Enforcement of rules is done by the browsers through the audit regimes. You know, most use either web trust or Etsy audits, and that enforcement is monitored by the browsers through various means. So, issuing certificates for longer lifetimes of public TLS certificates will be a violation of those rules and will be treated accordingly, according to the rules of, the different browser root programs. And that's not something that certificate authorities, want to try. As I said, for private certificates, it's okay. So and then there's a lot of questions coming in about is Chrome gonna block private CAs from this, Dimitris? Yes. I will I was gonna just bring that question because I I think it's important. So let me just share it here. Does change only impact public TLS certs? So browsers are not gonna block any private certificates, from from being trusted or from being longer, have a longer validity periods. So you have a private a private CA that is included in your browser as a in a trust anchor, and that certificate is valid for one year or for two years, no browser is gonna, block it. Right. I, I'm laughing because somebody said, hey. Ask Symantec how how well violating the rules did. Yeah. Symantec and Entrust and and others. So you do not wanna violate those rules. Okay. Let's see. How does a browser know I share that one. How does a browser know if the certificate is from a public or a private CA? Well, browsers have a trusted root list. Any browser, you can look in that trusted root list and see which root certificates they trust. So based on that list, they know whether it's coming from a private CA or a public CA. Okay. Let's see. There there's thousands of people on this webinar right now and there are literally hundreds of questions coming in. And I'm I'm trying to, we're both trying to look at these and see which ones haven't we answered and and which ones are pretty obvious and others that are sort of new and novel. Let's see. Here's one I think we can help people understand that a private local CA is not self signed. This is misunderstood. Well, I mean, the only comment I would make is that, when you're using a private CA, it's typically using a private route, a route that is not trusted by the browsers. It could be a route of your company name, and that all routes are just self signed, but then, the intermediate CA that's underneath that is chained to that route. Okay. I see people saying that I froze for a while. Sorry about that. I don't know what happened to the connection. You know, a lot of questions about what DigiCert is providing here. I I'm gonna answer that and after we do the q and a, we'll have a just a quick slide on that. I mean, I'll put this one up. Dimitris, maybe you can help with this one. This feels like a push to make companies pull applications or systems behind their firewalls and force VPNs. Are they trying to issue less overall public certificates? I I don't think that's the goal here. No. That's not the goal. But if you are I mean, I I know many, many companies that have internal networks that are more sensitive, you know, management networks and things like that, and that they're only accessible through VPNs. So with a VPN, you get an IP address that will allow you to connect to those servers. And those servers are using, like, using publicly trusted certificates. They don't need to. They have to switch to private certificates and be able to distribute the the the the trust anchors accordingly to their, employees and, people that need to access it. But, yeah, definitely, the push is not to issue less public certificates because reducing the life cycle will quadruple the number of public interest certificates. So this one says we have public eight facing applications like secure FTP that are not accessed by web browsers. Do we really expect the entire industry to change all their non browser TLS applications to forty seven days? No. And this is where, things like the private certificates come into that we talked about. So look at automation is the way to go. No question about it. You cannot do manual certificate renewals in forty seven days. Maybe even a hundred days or two hundred days is gonna be too strenuous. So you gotta automate. If you can't automate, you gotta move on to a different, certificate hierarchy that is not browser based because then you can do whatever you want. Well, I'd say whatever you want, but in in most cases, you can have much more flexibility. I think there are many applications like that, Dean, like Secure FTP, LDAP. You would've seen we've seen it all. And, you know, there are ways to to, let's say, go around the problem by using the still using an Acme web server to complete the, you know, the challenge response things, and then you have specific scripts that take that certificate and, you know, install it, deploy it somewhere in your FTP server, LDAP server, and all of that. So there are ways to bypass and and and, solve these problems if you really, really need to, but you still need to invest in automation. Okay? And if, those that don't want to invest in automation for supporting their FTP servers, VPN servers, and and and that non browser, use cases. They have to switch to a private PKI, and maybe they will have less automation to worry about. Yeah. I see some other quick questions. Is this being proposed by companies that sell auto TLS automation tools? Well, Google and Apple do not sell TLS automation tools, and they were the pro prime proposers of this ballot. So the answer there is no. Let's see what else. You know, our, here's one. Are private certificates going to weaken everything, defeating the purpose of this change? No. That is not, the purpose of this that that is not going to weaken everything here. Private certificates have and public certificates have different use cases. So public certificates are used to authenticate unknown people that are on the web that are coming to your website to make a transaction or do some sort of, checking of your inventory or your systems, versus something that's internal where you have trust amongst, people within your organization. I don't know. Dimitris, anything else you wanna say about that? Yeah. I mean yeah. Just don't put public certificates in pacemakers. Okay. Yeah. Like Okay. So there's a lot of questions about automation, and how we're gonna do automation, how our organization's going to do automation. Let me just say that, there are tools available to do this today and Acme is one of those tools. There are a lot of other tools out there. Talk to your CA, talk to your vendors about this. There are other third party tools that are not related to CA's that do this. So this is not a brand new topic. This is something that's been going on for a while and the timeline for this change takes that into account and knows that some organizations are not ready to change today. They might have applications that may not be automatable today, so they need to look at alternatives and look at automation tools. Look. This is not gonna be an easy transition for everyone. For some people, I've already talked to many banks where they say, we're already automated, and so we're ready for this. And you can make it down to one day. It doesn't matter. Let me just say something else too. You know, forty seven days is the end state for this ballot. But I guarantee, after 2029, once the industry gets to much more automation, I can pretty much tell you that I think Apple and Google and other organizations are going to push for even shorter validity periods. We said that CRL and OCSP is not working at scale on the Internet or has other weaknesses. So the only solution to revoke certificates or the bygone SSL attack is shorter and shorter certificate lifetimes. So don't be surprised if 2030, '20 '30 '1, we see ballots reducing this to even things like ten days or six days. And that's why that automate automate automate mantra that I mentioned earlier is extremely important. Well Exactly. Just to just to add to what to to the ten days, Dean, according to the current rules, the, certificates that are valid up to ten days, they don't even need to have revocation information in there. They are basically unrevocable. Doesn't make sense to to include it. Of course, this will make things faster and and more resilient for the ecosystem because OCSP service is a very flaky and, difficult unstable service to maintain. And I think, it it will happen, Dean. I think we're we're gonna be seeing less than forty seven days certificate, valid fees. Someone asked, does this mean, EV search need a phone call to an authorized person every ten days? No. The ten days is for domain validation, not subject information. Subject information is still good for one year. Even when we get down to the forty seven day certificate lifetime, the subject information is still good for one year. Yep. And especially for EV, nothing changes because today, today's reduced period is, three hundred ninety eight days. So where can people learn, more get more information? There is some information on the DigiCert website. I'm gonna ask, one of the staff to put that link in there, because nobody can click on it here. And, also, Dimitris pointed out that this is, if you wanted to read the background on this, the ballot that was originally issued here and it was voted on, can be resourced, can be reached from this resource. So again, I'm gonna ask our staff to put it in the chat window, so that our, listeners can can grab that. And lastly, just from a DigiCert perspective, I wanna mention that we have a full identity management platform that allows for automation and not just for TLS certificates, but where their certificates might be used for signing software, machine identity or other devices, IoT devices, or even signing content. This is all part of our platform. And now, with the acquisition of a company called Verkara, we have a direct connection into a DNS provider, a product called UltraDNS. So this will help our customers with the domain validation that we have to do in the background when we reissue certificates. And this is all available on this single platform called DigiCert one. So, I I still see questions coming in. I I think a lot of these have been answered. You know, there's, certainly some people that are upset with this decision, and I I understand where you're coming from there. We're hoping that, a lot of the questions that you had and we can get you a little bit more comfortable with what's going on here. I don't think this is the the last webinar we're gonna have on this topic because I'm gonna go through these questions, and I'm sure Dimitris is as well, and see what are some of the issues that, are really sticking out as sore points for you. And we'll try to get together again, at another webinar, in the near future to help address some of these. We still have a couple more minutes, so I think let me just Dimitris, if you, see anything on the q and a that, you want to address, we can certainly, Yes. I think I have a good, a good question here Okay. To share. So, yeah, we have a lot of hardware that does not have the means to automate certificate updates, so it has to be done manually. So people, I get that that question a lot, and our support team is also receiving a lot of, concerns with devices that basically are, legacy devices that cannot be updated, old operating systems or whatever. There are ways to, automate this, the certificate, the certificate life cycle management through the use of proxies. So, this is something that happened also, in this industry when browsers stopped supporting TLS one dot o and one dot one. And there were a lot of devices out there that just could not serve those protocols. These were independent of the certificates, by the way. Okay. The they were just insecure connection algorithms. The the solution to these problems is, installing a reverse proxy. So the reverse proxy takes care of all the certificate management life cycle. All t n TLS connection terminates on those proxies. And then in the back end, you have your your local hardware old device, but it's gonna be in under your control. It's con that's gonna be interceptable on the public Internet. Right. That makes sense. Now another question we're hearing is, around the ACME protocol. I know you're very much more familiar with this is, you know, what is there a way that you can switch providers of of the certificates using the Acme protocol? The answer is it depends, because you need depending on the type of certificate you use, you might need to have a special authorization token, authorization key, to create an Acme account and start issuing certificates with the the the next provider. But, this is usually part of the onboarding process. So you connect to, you know, you you arrange your connections with the CA, the new CA, you get that key, and then you just replace it in your script. And that's it. You don't need to change anything else. Your Acme client should be able to behave the same way as the previous one. Right. And you also might need to make some changes to your DNS. Another question came in about, SSL pinning, and this is, something that we recommend that people do not do. And the browsers also recommend that people do not do. Yeah. So if you're if you're using pinning, please, stop. Yeah. Why can't you fix OCSP is another question. Sorry about OCSP. Yep. That was gonna say. So the reason the browsers don't really like OCSP is because of privacy issues. So when your client makes a request to the CA to check is the certificate valid, your IP address and the location that you're trying to reach is transmitted to the CA. And so even though there's been no, abuse of that to our knowledge, that information from privacy perspective is leaked out to the CA, and therefore, that's the problem with that technology. Questions about is this timeline realistic, you know, from a RC RCA perspective. Look, I think the browsers and most of the CAs voted in favor of this ballot. There were, I think, three or four CAs that abstained from voting, mostly from Asia who said that the timelines were still a little tight. But in general, most CAs were in favor of this along with the browsers, and I think because, Apple did listen to feedback about extending that final deadline out to 2029. And I think that, we believe that it's realistic, given the technologies that are going to be available or are available today and the help that is available to make sure that you can get there. Yeah. I think our first good milestone is the one hundred days, which should be doable even with manual some manual processes. But, companies and IT departments need to start the journey now sooner than later, because they will definitely find some, some challenges along the way. But, seeing ourselves, three years from now, Dean, I'm I bet you that we were gonna have so many different tools and processes and, tutorials, and helping information in place that the last step, the last milestone to forty seven days should be a a a good accomplishable goal. I see a question that says, what about domain validation? How will that be handled? Look, that's up to the CA. I mean, really, quite frankly, the only way to handle it is automatically. And, with the Digicert platform, as I mentioned, we have connect direct connection into the DNS provider, and I I'm sure that, you know, this is going to be something that has to be automated. Otherwise, it's gonna be a a a tenuous process. So I think we've we've certainly answered a lot of these. As there's still more coming in, it's unbelievable. But I'm I'm glad that we're coming in because that means people are interested and this is a topic that, goes right to the heart of of your business and your work that you do every day. This presentation is being recorded and will be made available to you, afterwards. So look for an email from our team. I wanna really thank a big thank you to my guest today, Dimitris Zacharopoulos from HARICA, joining us late in the evening there in Thessaloniki, Greece, and also, chair of the service certificate working group where this ballot took place and who has the most knowledge of this whole area. Big, big thank you to you, Dimitris, tonight. Thank you, Dean. Thank you for the invite and, I'm glad we were able to share all this nice information to, to the subscribers all all over the world. Well, I think you and I will be getting together after this to review the thousands of questions that we've had, try to consolidate them, possibly provide answers to organizations, and maybe even do, another event like this in the near future to to focus directly on those issues. Sounds good. Thanks again, everyone. Have a great day. Speak to you later. Bye bye.