Name: How to Automate TLS Certificate Lifecycles for Every Organization
Uploaded: 2026-04-29T06:33:05.399Z
Duration: 1 h 32 min 12 s
Description: How to Automate TLS Certificate Lifecycles for Every Organization

Transcript for "How to Automate TLS Certificate Lifecycles for Every Organization": Hello, and welcome to today's webinar. My name is Vinay, and I will be helping support today's live session. Before we begin the session, a little bit of housekeeping. On the top right corner of your screen, you will see the live chat option that you can use to interact with your fellow attendees. We have also attached a Forrester TEI report on CloudFlare, a white paper on security compliance, and a buyer's guide in the docs section that is located next to the chat. On the extreme right, you will also find the q and a box. We encourage all of you to leave your questions in that q and a box as we progress through this webinar. We'll make sure to address all your questions towards the end of this presentation. Quick reminder, this session is being recorded, and we will share the recording with you within forty eight hours. Now please join me in welcoming today's speaker, Sivad Tantikul, senior solutions engineer at Cloudflip. Hello. Hello, everyone. Hi, Sivad. Hi. Good morning. Yeah. Good morning. Good afternoon. Good evening, wherever you are. Yeah. Welcome to the webinar on how to automate certificate life cycles for every organization. My name is Siwaad. I'm a solution engineer at, CloudFlare. And, I'm actually here with, my colleague, Emily, who's also a solution engineer who will help me on the answering the question along the session today. So, let's get started. Here, what we're going to talk about today, we'll talk about the TLS challenges that most of the enterprises have, what we should consider for TLS security, how we can automate the TLS processes. And, one of the probably the most talked about topics in the past year, the quantum challenges in cryptography. And then we're gonna see how Cloudflare TLS solutions can help simplify the TLS process by automating many of the tedious admin tasks securely. And finally, we're gonna have a q and a session at the end. So let's get started with the TLS challenges. Okay. So, TLS stands for transport security transport layer security, which, like the name say. Right? You think about think about it as a highway or your data to communicate securely. So, when it's working, we don't care about this layer much. It is a silent engine for our data, transmission. The s in the HTTPS actually tells the customer that they can trust us. But today, TLS management has become, more like a countdown game. You know? Don't don't let the time work get to zero. So the the challenge is that the our environments today have become so complex. We aren't just managing one or two certificates anymore. Right? We're managing thousands across multi cloud environments, containers, the, devices. When we have too much on our hands to manage, it can cause a big problem. And when TLS goes wrong, it doesn't just cause a minor glitch. Right? It causes a lot of problems for the enterprise. So first, let's talk about the SEO damage. We have been working so hard for the search engine like Google, right, to recognize our website, our services. Right? They but what they do is they also prioritize security. The moment your certificate expires or misconfigures, we we are not just down. We are flat as unsafe. So in an instant, right, you have done so so much of the search ranking optimization, and then it vanished in one day. Even after you fix the technical issue, the SEO reputation can last for, like, weeks or months. It's like putting, you know, the danger sign in front of your house. And then there's, internal issue. Right? The the IT, of course, we all have been there. When the cycle is down and suddenly the, IT and security teams are being seen as a blockers. Right? Marketing is screaming because their campaigns are failing. We have sales. He's trying to do the demo, and they cannot do it. Right? So when the TLS management is manual and reactive, the IT spends all the time just put away the fire instead of in a wedding and, leads to burn out and other stuff. But the most quantifiable pain is actually the revenues, the numbers. Of course. So for an ecommerce site or a SaaS platform, every minute of a TLS related outage is a direct hit to the bottom line. We have buyers maybe abandoning the card during the certificate error. And it's not just a customer bounce. Right? It's a customer that may never come back again later. Right? And it leads us to the final most, you know, kind of scar thing is a brand. A trust is the hardest thing to build and very easy to break. So when you have a user seeing that, you know, the message, the, connection, your connection is not private, They they don't think that, oh, probably their IT department forgot to renew a certificate. Right? They think that, is my data safe here? Is this company reliable? This, loss of digital integrity is a very stain in on your brand, and it it will take a lot of marketing budget to to fix that. Alright. So our primary goal is always business continuity. Right? We want to ensure that our services are reachable and secure. However, the in the reality, broken SSL, whether it's, expired certificates or, misconfiguration, is a direct it to that goal. So the like I said, the moment the user see the connection is not private thing, we lost their trust. Right? And it's not just a technical error. It's actually driving users away from our platform. So to prevent those outages, we aim to streamline the entire TLS life cycle, from the issuance, storage to serving to renewal. But here's the challenge. Many of our processes are still manual and driven by spreadsheets. I have seen many of my clients have have done that. You know? Hundreds of certificates we, managed by the spreadsheets, Excel, whatever. Right? And they set their calendar alarm to notify when the certificate is, ready to expire, that kind of thing. So it's a massive burden to the engineering and security team. Right? Manual tracking is is one, it's error prone. We have seen many times that, we put in the text record. Right? And we miss one character. We put a space, behind or whatever. Right? And the certificate validation or renewal becomes longer. And it it's actually not a very efficient use of our talent. Right? We are doing we are highly skilled people, but we're doing the data entry work kind of thing. Right? And the critical part of the life cycle life cycle is actually the domain control validation, the DCV, which, is a process when, that we need to prove, to the certificate authority that we actually own that domain that we're securing. So in the past, you might do this, once maybe once a year. Right? But the industry is moving towards a shorter certificate validity, periods. So what what used to be a yearly task is now happening every few months or even weeks. It means that our manual process are being stressed and broken more frequently than before. And, beyond just keep it running. Right? We have to stay with, in compliance with, you know, those, CA and browser forum. Their insurance equipments are getting stricter and changing faster. So to keep up, we need to constantly, update our infrastructure. Every time a rule certificate is deprecated or new encryption standard is mandated. We have to touch every server or maybe load balancer, and and it's, pretty tedious process and error prone. And finally, the the financial, of course, the bottom line, every business wants to keep the cost low. Right? But when you add up the manual labor, the emergency, you know, firefighting, during outage kind of thing, and the need for specialized knowledge. The the operation costs are settling. And, in many large organization, managing the certificate pipeline has become so complex that they need to have a separate group of people doing those kind of thing. Okay. Okay. I have a small poll for you all to, to do here. If you look at the poll, right, you you should see a question. I actually, it's more like a survey. What is your current average certificate lifetime? You know? I I used to have, like, a whole year for the certificate. Right? Lifetime before renewal. Right? But now it's getting shorter. Right? Just wanna see, you know, how you guys, doing on that. Okay? We have the, three hundred sixty five days, one hundred eighty days, ninety days, and thirty days. Okay. So I'm seeing oh, surprisingly, we still have, many people work for three hundred sixty five days. Oh, okay. That actually surprises me. Yes. From what I have seen lately, it came down to around half a year, one hundred eighty days on the average. Right? We have, several financial institution that try to put it down to around, three two, three months already. Got it. Okay. Thank you. Thank you so much for your your work your participation. Okay. So, if you feel like you are renewing certificates more often than you used to, right, you are not imagining it. This slide illustrates a a shift in the, you know, in the trust part of the Internet. If you look back at at the before 2012, right, managing SSL was actually just study that. Forget it. Certificates were often valid for, like, ten years. You could practically start and finish a career in IT department and only have to touch a course certificate once or twice. But as the threat landscape evolved, right, the industry realized that long lived certificates actually were a massive security liability. So starting from around 2012, you can see that the CA and browser forum began tightening this group. We saw validity drop from, the year ten years to five years, then three years. And by 2018, we were down by roughly two years. Right? And the real turning point was around 2020 when the industry standard dropped to three hundred ninety eight days. That was the moment SSL management shifted from an occasional kind of thing to an annual chore. It forced many of us to actually put certificate expiration dates on our calendar for the first time. And I look at where we are today. Right? In 2025, we hit two hundred day mark. And here in 2026, we are staring down a 100 lifetime. You know? Think about what it means for our manual workflow. Right? If your process for requesting, what else, validating, deploying a certificate, right, takes two weeks, you're now spending fifteen minutes of that certificate total life just getting it installed. Right? And by the time you finish the paperwork, the countdown to the net renewal has already begun. If you look ahead to 2027, the projection is, around forty five days. K? So we are moving towards, a world where certificates are ephemeral. The manual approach to the TLS management using spreadsheets, email, manual server locked in, It's officially not working anymore. Right? We can unmanage a forty five day cycle manually across hundreds of endpoints without an outage occurring. So we have to move toward short lived, automated and renewals because the window of crisis only keep shrinking from from day to day. Now let's consider, the TOS security for a moment here. Having a certificate installed is only, like, half of the task. Right? A certificate says, I am where I am, but the protocol configuration will determine how strong that handshake actually is. So very often, we see, settings that are, just for the compatibility. Right? But leave the door wide open for the attackers. So if we don't actively harden our TLS settings, we're actually we are not actually secure. Right? Here are some of the examples, on the slide that, misconfiguration can lead to vulnerabilities. So when we talk about misconfiguration, we often talk about, failing to disable legacy features. Okay? For example, like TLS downgrade attack. Right? It forces the server and browser to drop their secure modern connection like TLS 1.3, and use the old insecure one, like SSL three point o. Pluto, example, the attack that, target SSL three point o. Once you pause the downgrade and exploit, this happen when the server is configured to support to still support the outdated protocol just in case someone is still using an old browser. Right? And the same apply to the padding oracle attacks such as the Beast and Lucky 13. They focus on how data is headed, to fit the fixed size block encryption, the the old kind of way to do the encryption. Right? So if the server responds differently, the attacker can you, can see can use those, the clues to guess the content of the message. Right? This also target the old protocol version and weak encryption scheme. Then we have the man in the middle attacks that allow, weak cipher suites encryption methods that are now considered crackable with modern computing power like, RC four, DES. Right? Another common one that, is a technique that a popular security, way to do it in the old ways, we call it certificate pinning, where we where we pin the application. We we say the application is told to trust only one pin certificate rather than any certificate issued by the trusted authority. The attackers can use some tool to hook hook into the application, right, application code and tell it to just ignore the PIN. And this allows the attacker to present their own certificate and inspect the app, encrypted traffic. Kind of closely related to is, SSL stripping. This is where attacker transparently converted the, secure HTTPS connection into a insecure one. So without proper headers like, HSTS or secure certificate pinning, the user may never know that the securization has been downgrade to just a plain text. And finally, we have to look at the PFS. Right? Without PFS is, if a server's private key is ever compromised in the future, every past session that that was, recorded by an attacker can be decrypted. PFS ensures that, every single session has its own unique key. Without PFS, we just hope that our private key, never enable leads. Now oops. Okay. Now that we have seen how, easily things can go wrong with TLS and protocol setup, right, let's talk about the best practices for TLS today. Well, first and foremost, the protocol versions. In 2026, there's no excuse for supporting SSL three dot o or TLS one, TLS 1.1 anymore. Right? TLS 1.1 was formally deprecated around 2021. Okay? And many, many of the Windows system or operating system, Windows just stop supporting it already. Our environment should be locked down to TLS one point two and one point three. TLS 1.3, in particular, it removes the legacy, kind of handshake. So both of both of them make it more secure and faster for the end user. If we don't explicitly disable those kind of older version, we're still vulnerable to the downgrade attack. And next, we have to protect the privacy of the section itself. We do it by enabling the PFS, using the, the ephemeral deep pre element ciphers. This ensure that even for our long term private if our long term private key is compromised tomorrow, today's encrypted conversation is still secret. Right? And next, the HTTP strip transport security comes in. It tells the browser that never walk to me over a plain text HTTP again. Okay? It, effectively shuts it off on the SSL stripping and ensure that every single interaction is encrypted from every first from very first byte. And we also need to look at the Cypher suites. Okay? We need to prioritize strong modern algorithms like AES two fifty six. We must also purge deprecated algorithms like RC four and triple debts triple debts that, are not considered secure anymore. And finally, the most practical best practice on the list is try to automate things. You know? Automate certificate renewal. As we discussed earlier, right, with certificates lifetime shrinking towards forty five days, the human element is now, the created you know, the point of failure. Right? Automation is not just a convenience anymore. It's a security requirement by using protocol like Acme. By the way, that's not the the company in the Looney Tunes. Right? If you go up with the Looney Tunes, you heard hear the word Acme. You you think about the failed equipment. Okay? That's a protocol that you can do the automatic, certificate management. Right? You can use Acme to automate issuance and installation of the certificate. We remove the risk of, you know, the forgotten to renew and ensure that our infrastructure stay current without manual intervention. Okay. Other than that, we wanna make sure that you, rotate your private key quite often. Right? And if somehow you cannot do automatic, service certification management, what you need to do is you need to set up a notification for the you know, before the expiry. And, you wanna make sure that you have access control to whomever that have access to that certificate, repository. And, finally, you should have a backup plan in case of the CA revocation. Right? It's it's it's possible that, certificate authority key was compromised. That's also possible. They can remove all the certificates, and then if you don't have a backup, right, it means that you you're gonna get the you're gonna get the the the connection to the CTO four sometimes. Okay. Up to this point, we have talked about the TLS as the technical necessity and, RAM protect it. But for many of us, it's also a legal requirement. Right? Regulators are not just looking for at the weather you encrypt, but how you encrypt it. A single misconfiguration or an expired certificate is not, just a technical glitch. It can be a noncompliance event with, maybe some financial consequences. For example, under GDPR. Right? Personal data, PAI, must be protected against unauthorized access. That's what they say. And if an SSL certificate expires or use a weak encryption, the data being transmitted is not secure anymore. Right? If a website certificate is invalid, the browser warns a user, the user bypasses that warning, and their data is at the risk of interception. CDPR says that, a data breach in transit is a violation of article 32, which is a security of processing, which is subjected to be fine. K? Then we have a PCI DSS, specifically p PCI DSS four point o. It mandates that we must use the modern TLS version, like TLS 1.2, 1.3, and strong cryptography. If a new vulnerability is discovered in Cypher suite that we're using, we are no longer the PCI compliant until the suite is disabled. Automation becomes your best friend here, ensuring that you can, move your entire fleet to a new standard, the moment the requirements change. And finally, we are seeing a rise in regional key storage requirements. Many tradition, like, EU, India, or China have a data residency laws requiring the sensitive data and the keys used to decrypt it remain within their borders. So, the private key is a master key of our encryption. Right? If you use centralized cloud provider, for example, based in US, to manage all those, global SSL certificates, the private keys for the, let's say, German or Indian branch might be stored on The US servers. This could violate local sovereign sovereignty laws. It could also create a risk where a foreign government could theoretically subpoena those fees. Now let's move on to the best practices for automating, TLS. Right? In order to automate TLS process, usually, the slow part of the process is the DCV where we prove that we actually own the domain. So to automate the TLS process, we have to automate the validation, the domain validation itself. The first goal is to eliminate the manual work. Right? Every time a human has to log into a console to verify a domain, we introduce a risk of a human error. Right? And more importantly, we created a a delay. When we automate the verification process, we ensure that the moment a certificate is requested, the validation starts, completes, and moves to the issuance without a single ticket or approval button to be clicked. One of the most effective ways to do it is to use the leverage the CDN provider like Cloudplay. Right? Because we handle the HTTP token method for you. They we automatically place the required validation file at the edge of our our our computation nodes, right, of the network. This creates a, seamless renewal loop. So the certificate authority checks the path. Right? The CDN serve the token, and the certificate is renewed in the background. It is invisible. It's fast, and it requires no human intervention. If we have to manage hundreds and or thousands of subdomains, right, CNAME based DCV can be handy. So instead of manually add a new, text record for every single renewal. Right? It it is a nightmare for the DNS management people. Right? You set up a permanent CNAME record like, ACME challenge, that kind of thing, that points to the certificate management platform. Once that one time setup is done, the platform can handle all the future renewals through the, we call it delegation path. So you essentially set it and forget it, remove the need for your DNS admin team to be involved in the certificate life cycle network again. And finally, even with the best automation, right, you need visibility. You need proactive expiration alerts. Right? Those should not just be your certificate expire in thirty days email that could get lost in the inbox or put in the spam folder. So this should be an automated, notification integrated to your platform, to your whatever, operation path platform like Slack or Teams or soft dashboards. It serves as a trust but verify mechanism. So ensuring that if an automated renewal fail for some reason, like, maybe you have a DNS outage during that time or provide a glitch, you know about it long before your customers do. Okay. And, we spend a lot of time today, right, talking about renewals. But what happens when a certificate is still valid button but suddenly become, what's the word, become maybe toxic? I'm talking about the you have a key compromise or a mass revocation event. Well, in in the in reality, it's possible that, certificate authority can have some issue themselves. Right? In the event of the compromise, a certificate need to be rotated immediately. So if you are starting from scratch, it means that you have to generate a new certificate request. You have to wait for validation, deploy. You're looking for, like, at least, thirty minutes or hours, if not days. So you see the red screen on your website. Right? It's actually, bad for you. So, for the customer. And the best practice is to avoid this is to, ensure the continuity by you should have a backup certificate for your host name before you need it. Think about it as, analogy is bad tire. Right? You don't wanna when when you have a flat tire, you you should have it ready to replace. Right? You don't just produce a new tire. Right? But that's a that's a one cache. The backup itself is useful if it doesn't fail in the same reason as the primary. Right? I have seen some customer that have a backup CA that, I mean, backup certificate that, issue from the same CA as the primary one, that's not good. Right? So you your backup certificate should come from a different CA and use a unique private key. Alright. Okay. Let's move, here a little bit to the post quantum cryptography. Right? So as we look towards the future of computing, we have to talk about quantum. Right? The good thing, quantum computers are great. So they are miracle for the science. Like, unlike our old binary system. Right? The it it can perform the simulations of the nature at the molecular level. So this opened the door for the golden age of discovery. We're talking about, new material that could, revolutionize your EV battery, EV car battery, energy storage. You can create a precision medicine that, tailor for individual genetic codes. So from from a human progress standpoint, quantum is, is great. But it also comes with something that we unexpected. Okay. So while these machines are solving mystery of the universe, they also fundamentally built to solve the specific mathematical problems that, we use for the encryption for the security. Most of the cryptography that we talk about today, right, RSA or elliptic curve, the handshake, actually relies on the fact that the classical computers are really bad at factoring large prime numbers. Okay. For example, if you have a 15, right, in order to find that three times five is 15, it's it's easy because the number is short. Right? If you have a very big number and in order for classical computer to find that combination, it's very hard. But for quantum computer, it it's different because it can, open all the possibility at the same time. You don't have to do it one by one. You can just open all the possibility and just see which one is right. Right? So, when a cryptographically, computer, quantum computer arrives, right, it will break most of the cryptography that we use today. The the HTTPS is not secure anymore. Right? It's not a future problem because, we have something some terms called the harvest now and the the crypt later. It means that we keep all the lock. Right? We keep all the data. We need to do it for the compliance reason. The lock store in somewhere for a whole year, those kind of thing. Then it it is impossible to decrypt, to brute force it. But once the quantum computer comes in, it will it will be very easy for you to crack this code. Maybe those are financial information that I can wait for five years until the computer is ready, and I get it that information then. Could be, like, your Bitcoin secret key, those those kind of thing. Right? So that that's very dangerous. So, so when we build the TLS road map for now, we have to start thinking about post quantum cryptography. Right? We have to make sure make sure that, infrastructure that we are automating today is agile enough to swap in quantum resistant algorithm tomorrow. Now if you think quantum resistant security is just a theoretical concern, right, if you look at the slide, this is actually a memorandum issued by the White House during the Joe Biden era. Right? When you have a president of United States issue, directives, specifically targeting the cryptographic system, right, is something is a is a big threat. Right? And if you look at the goal, right, the goal is to mitigate as much of the quantum risk as is feasible by 2035. Now today is 2026. Right? You have nine years. That's fine. Okay? It should be a long way. But the world of infrastructure and enterprise security, that's just wing of an eye. Right? Think about how long ago that you have a very slow computer. Right? Go from one core, dual core, quad core, and to, like, today, 20 cores, 40 cores, it goes down very exponentially. Right? It's just a matter of time when you get a capable quantum computer that can crack this kind of thing. Right? So this, since the release of this memorandum, my NIST started working on the, the quantum recession algorithm and came up with, several of them. Right? We have to look at the public key cryptography like RSA or ECC elliptic curve, those kind of thing that are targeted by the, quantum computer. Right? Now there are two sides of the of the encryption. Right? If you if you know about technical behind the public key cryptography, right, there's one side that's called the key agreement. Right? We use a key agreement to encrypt and decrypt the transmission data between these two parties. And, the other side is signature. It's basically to verify that you actually who you are. Okay. We use it to verify the your that you are actually a website owner. Right? So let's take a look at the key agreement first. This is a part of the handshake where two party agree on how to encrypt that session. This is the most immediate concern because of the how is now decribulator threat that they talked about. So every bit of communication that we send across the wire today can be recorded. And so in data some I mean, data center somewhere. Right? Just waiting for a quantum computer to crack it in the future. So we need to update the key exchange as soon as possible. Then the good news is that it's it's it's not a hard problem. When you say it's not hard, you can see that, it took us five years to test and deploy to make sure that we support the TXN fully quantum resistant. Okay. So, this part is good. Then we also have the signature. Right? This is not less urgent, but it's a little bit, hard to do, harder to implement. It's not widely implemented yet. We have a limitation in terms of a hardware and, the delay. We don't wanna slow the Internet down due to this, this, signature post quantum verification. Right? So, the strategy is clear that we need to prioritize the upgrade of our key agreements to protect our data future privacy, while we have to prepare our infrastructure to be ready for the quantum resistance signature in the future. Okay. We come up with the poll number two. Okay. Let me explain a bit on on the poll here. CloudFlare has support, post quantum cryptography for many years now, and we have seen traffic coming from the from the Internet, right, going to the site in the behind the CloudFlare. And most of the browser nowadays support, post quantum cryptography already. We see the number of requests increase the support, post quantum cryptography. Right? I just want you to take a guess of, you know, how many requests you know, what are the percentage of the HTTPS request to the CloudFlare that, nowadays that support post quantum? Alright. We see 40%. We see 50%, 60%, 70%. Okay. That's nice. Okay. So most of the most of the answer, you get it at, 40%. Okay. Cool. Cool. Thank you. Thank you so much. Okay. Hold on. Let me show you this slide first. If you look at the 2025, right, we have about 65% of of the traffic coming to Cloudflare that support, post quantum cryptography. And as of yesterday that I checked, we got around sixty sixty nine to 70% of the traffic already. The reason behind this is that, most of the browser already support post quantum cryptography. Okay? It's a matter of when you initiate the TLS session. If the server is self support, when you have a server behind CloudFlare, CloudFlare already supported. So it means that, only the traffic that, does not support the postpartum cryptography on the browser side. Okay? So you can see that, out of 70%, maybe not not just the browser side, maybe they use a very old TLS version that's also possible. K. Now so you may think that, okay. I'm safe. I'll put my website, behind CloudFlare. I'm done. Okay. Almost. Okay. We we have a term called Q day. Okay? Q day or quantum day. Q day is a day where the the quantum computer start, cracking the encryption successfully, okay, we believe the q q day is beyond 2035 until last month. Okay. In March 2026, right, Google announced a a drastic improvement to the quantum algorithm to break elliptic curve cryptography. Now, let me go to the tech a little bit of technical on that. We have a public key popular public key cryptography is RSA and ECC. With RSA, usually, the key is very long, 2,048 bits. Right? But since the key is long, right, it's difficult to use that cryptography with the mobile phone, okay, because it has a limited resource here. So we have a new public key called ECC. And with the ECC, the key is actually shorter, which means it's it's actually easier to crack for the quantum computer than the longer key. Okay? So now they target the ECC, 256 bit. And, the same week, we have a company called Automic, published a resource estimate, that it requires only around 10,000 cubits to to break, the ECC two fifty six. It's shockingly known low number because before that, we predict that, usually, you would need around 1,000,000 qubit, you know, just like computer bit. Right? We have a zero and one bit. Right? But, the quantum, we have also be the third we call qubit. We need a a million qubit to be able to crack the those public key cryptography, but now it comes out to 10,000 qubit. The current, quantum computer already have support, like, thousands of qubits already. It doesn't take long to get to 10,000. K? So the bad news is that the queue date time, the the time that we need to to enhance our security has moved from 2035 down to 2029. Okay? So I have the, our our Cloudflare block that, address this issue right after we saw this, this research coming out. Right? So, this is the Cloudflare post quantum journey. Right? As you can see that we have involved this, development since the beginning. We tested with Google, and we, kind of, helped them build helped NIST release a standard called MLKEM, which is a de facto standard for the key exchange for post quantum. We thought we were done. Okay. But after that report came out, then we had to set up a plan, for the authorization. Because when you talk about authorization, right, some of the authorization or authentication use the digital signature for the authentication. Right? That is we need to ensure that that part can be post quantum resistant as well. So what we can do is we we plan the target to finish the entire authentication, to support post quantum cryptography by 2029. Alright. Now we talk about the technology. Right? Let's look at the Cloudflare TOS offering. Right? K. What do we offer? So with the Cloudflare managed TOS, it's fully managed. Right? Automatically renew, upon your settings. You can extend it further to, if if you have a if you are a SaaS provider. Right? Oh, hold on. Hold on. One moment. I put the wrong slide. This one. Oops. Okay. Let me talk about this one first. Right? It it does the automatic menu of your of your certification. Right? And we have a specific, offering if you are SaaS provider. For example, if you allow the SMB to set up their shops inside your SaaS platform and you want to be able to manage SSL for desktops, you can do SSL for SaaS to support this scenario. Right? You can customize to fit your needs, like, bring your own certificates. You can use a wild card host name, customize origin, and and many more. We support mTLS if you need to also validate the client using certificate. We support keyless SSL, where you hold your private key and CloudFlare will connect digitally to the key server when needed. Right? Okay. I seem that I need to speed up a little bit. Before, before I go to the feature, let me take you to a small demo first. Right? Oops. Okay. So this is, I'll give you a a demo on our certificate management. First of all, usually, certificate and DNS work together. Right? So cloud in CloudFlare, we have two deployment model. We have a DNS model, deployment model called full. It means that you manage DNS on CloudFlare. Okay? The other one is called partial. Partial mean you have a DNS somewhere else, but you use Cloudflare to manage certificate. Let's talk about the the full mode first. Full mode, it means that Cloudflare has access to the DNS and also the certificate management. Right? So it means that, everything can be automated inside the CloudFlare. If you look at the SSL certificate here, we call it edge certificate. The reason we call it edge certificates is if you look at this picture, right, we have two side of, certificate that we need to use. The first part is the between the browser to the CloudFlare and from CloudFlare to your origin server. Right? We talk about this certificate here. So in order to create a certificate certificate, you can do it just, click on, order a certificate. Right? You have a option to choose, which certificate authority, Google Trust Service, SSL, less encrypt. And you can just put in something like this. Do a subdomain. Okay? And you have option to do the text validation or HTTP validation validation. You have option to, for the renewal period. Right? Every three months, one month, two weeks, whatever it is. Right? And you could just save. And that'll be it. You can see that it initializing everything here, and it will do the validation and everything very easy. Okay? So this is a case where you have a a DNS managed at CloudFlare. Now on the other hand, if your DNS is managed somewhere else okay? I have another website, for example. Right? This is, my website that managed somewhere else. I have DNS manage somewhere. Right? It means that the CloudFlare cannot verify the owner of the website by themselves. What we can do is we can do the something called DCV delegation. Okay? So what we can do is we can put this information in your DNS server one time. Okay? And then CloudFlare, we verify the DNS server on this. And if whenever you then need to renew a certificate or whatever, right, it will check with the DNS server for this record. And if it's there, it will do automatic renew for you. Right? So I give you another example. Let's say, I put in the demo here. K. See that? It's the same process. Okay? You don't have to worry about anything here. It will do the verification, validation, and everything by I will automatically create a certificate for you. Now let me take you to see the, some of the features that, available here. See that? It take less than five minutes to come up with a certificate here. Right? Right. CalCare also offer you the universal certificate. K? If you look at this, whenever you have a a Cloud Fire service, right, we we we have a one universal and one backup certificates for you. I already mentioned about the backup, right, from the different, certificate authority. For example, this universal one is from Google Drive. Right? And the backup is from Let's Encrypt. K? Now let's go through the the option that you can use. One thing that is very, very useful for you is you can enable something called total TLS. Okay? So when you onboard a new website, right, you have to create a DNS record. You have to, create a certificate for those website. Right? We can combine those into one procedure. So if for example, let let's say I use, this Google trust and I enable TLS 1.3. I I mean, total TLS. It means that the button is not up. Maybe it's something wrong with this. Okay. Maybe you are glitch. Let me share with you on this instead. See that? This is I have a total ticket TLS enabled. Right? It means that whenever I create a new DNS right. I'll give you example here. Let me add a new record. Let's say, I call demo as well and, just some random IP. There you go. Once I do that, with the AutoTLS, it will start provisioning. See that? The certificate for you. You don't have to do it. Once you add a new DNS, it will be there. And once you delete the DNS record, it will be automatically deleted for you. Okay? So that's one of the option. Okay. Let's move on to the next one. The most important one is the Cypress suites customization. Okay? You wanna be able to select the encryption that you want to use. Right? We have a option for you to configure here. If you want the easiest way out, right, you can use the compliant. For example, if you need to be the PCI DSS compliant, right, you can choose the compliant here, and it show the Cypher suite in order to comply the PCI DSS. If you select this option, right, it will automatically automatically allow only this encryption, Cypress suites for you. Okay? And you will automatically be comply for this standard. K? Could be FIPF. But if you want to customize yourself, you can. K? You can choose this by security level. You can choose the modern one. This is a modern security level. You can choose a compatible one. Okay? Some, old encryption but still secure, or you can choose the legacy to support the insecure one. And I don't recommend this one, but if you need to do it, you can. Right? Or if you want to select your own Cypher suite, you can do that also as well. See that? There are many of them for you to choose from. Alright. And what else I need to show you? We have a SFTF. You can enable SSDS simply just one click. Okay? So it tells the browser that please connect back to me with HTTPS only. We don't allow, HTTP. You can select the minimum TLS version that you can use. Okay? By the way, this, TLS version and, Cypher suite can be customized per subdomain as well. You want this subdomain to support only this certain set of Cypher suites, that also possible. Okay? I think, that should be it for the demo. Let me go back to the slide. Okay. So as you can see that, the feature that, we have we have a standard certificate management, okay, that I show you already, the the universal one and, the backup one. That's actually for everybody. But we we also have option for the advanced certificate management or ACM. We add more customization option for your TLS management. If you need to customize the Cypress suites, allow for TLS, you need to include or exclude particular encryption in the handshake, you can do it with ACM. It's easier to manage, flexible, and customizable. So here are some of the features available for the SEM. With one certificate, you can have up to 50 host names. If you have a requirement to do more than one level of subdomain, for example, pet.shop.example.com, those kind of thing, ACM support this certificate generation and automatic renewal. You can customize the Cypher Suites, certificate validity period, and, you can choose certificate authority you want. Typically, like I show you there in the demo, right, CloudFlare provides a universal certificate for the domain that can be used as a wild card for all your subdomain. This certificate has a CloudFlare branding attached to it. But, with the SEM, this is going to be your domain brand. You have an option to upload your own root CA, if you want. Okay? We we have the service is called custom trust store. You upload your own CA instead of, using the list of public CA that call fair trusted. And finally, you can implement total TLS to, like I demonstrated, to automatically create a new certificate when you add a new proxy DNS record, which actually streamline the certificate life cycle management across all subdomains. You don't need manual issuance. You cause coverage gap, and you ensure every host name is encrypted without any per subdomain intervention. K. Demo's done. And finally, like I mentioned in the post quantum cryptography, right, once your origin is behind CloudFlare, you can guarantee that the connection from the user from the web browser to CloudFlare is secure against quantum, okay, attack. And CloudFlare infrastructure, the traffic goes from one Cloudflare node to another, also secure with post quantum cryptography. And if you use our service called Cloudflare, the tunnel that actually a service inside that allow the origin server to reach Cloud Fair on one way only. It means that yours, your security go down to at the at the infrastructure level of your site. The only thing that you need to, you know, improve is the post quantum library of the software in the origin server yourself. So this is a pure benefit. Alright. Which brings me to the end of the session. I think we have, several documentations for you to take a look at. Right? And we also have the white paper on the TLS management on the in the enterprise. Okay. Let's, look at the, some of the q and a. Okay. I have one question here. Can these certificates be used for development on a developer's local? Unfortunately, no. It's a edge certificate. Okay? So, basically, it's, let me share you this slide. So it's it's a certificate, between the browser and the Cloudflare itself. Cloudflare also has a certificate that you can download and put it in the origin server. Okay? That, you can verify that the connection comes from Cloudflare only. That's that's possible. But can you cannot download it and install and use on your local machine, unfortunately. Okay. What else? Oh, okay. I have a question on TLS and SSL that's same. Yeah. The new term is, TLS. We we don't use, SSL anymore pretty much. Right. Oh, one thing I forgot, on the on the advanced certificate management feature. We also allow you to upload your own certificate. We call it custom certificate. So, basically, you use Cloudflare Edge Network as a certificate, the TLS termination using your own certificate instead of having Cloudflare to automatically generate that. But, the the raw drawback is you have to to validate or renew those certificate yourself. Cloudflare will send you an email on the when the expiry is coming up. I think we should have an option to do that. Hold on. Ah, okay. Let me share my screen. There's one option here. Right. We have a certificate transparency, monitoring. Right. You can have this, notification. Right. Let me see. Are there any other question? Okay. We have a question. In the environment like Azure app service where we can only enforce minimum TLS version and not explicitly control cipher suites, what's the recommended approach to align the modern best practices? That is actually a great question, and I got this question from some customers also. So, basically, if you put CloudFlare in front and you put in the, you know, the Cypher suite based on the standard, for example, like PCI DSS. Right? So those list of Cypher suites will be updated automatically by CloudFlare. So you don't have to manually control the Cypher suites anymore. So that that's one way of doing it. I have we we we I have seen customer doing two two ways. One is to put the software in front of, the origin and migrate out of the app service. That's also possible. And, you or you can have a a CloudFlare, you know, in front of the app service as well, but, it seems to me that it's gonna increase the delay in your processing. I hope that that answers your question. Okay. I think I think that's all we have I have for you guys today, and hopefully the hopefully the session is, informative to everyone. Okay? Hey, Shiva. I think. there are a couple, more questions. So, actually has. had answer a lot of them. Thank you, Emily, for joining in and helping out. There are a couple more questions. I can take you through them if you if you will. The first one. that I see on top of the list right now, Oh, I see. from. Is asking, if a certificate is expired, will the encryption work? I understand browsers will not test a certificate after expiry, but encryption still work. Right? Encryption still works. No. No. Encryption will not work because you won't be able to I mean, the encryption itself will work, but you will not be able to do the TLS handshake, right, because the cert certification is not valid. So it means that you cannot generate a key to do the encryption. But, if, for example, you I'm not sure if it's to be honest with you, I I'm not sure if you can bypass the certificate expire with the normal browser nowadays. But if you if you can do that in the old days, it means that your encryption is still there. Yeah. Okay. The other one is by. They are asking I have to be in another call. Okay. I'm sorry. This is just, okay. a comment. Sorry. An Anugoon. Is this certificate support browser Oh, only, okay. or is it working for other client type, like, mobile app or IoT? Yeah. It will work for for everything, right, not only browser only. But, usually, when we see the, mobile client, usually, they use different kind of authentication. They use, client certificate or m t o s more to access the, you know, the internal, application. But if it's a it's a normal browser website or something, that that should work the same way. Okay. Perfect. Also, Anagun wants to get in touch with someone at Cloudplay. I I'll share a I'll share a direct, email with you, Anagun. You can send a line to. that. Peter, the next question from Peter is asking, is there a way to automate the renewal of the internal origin server certificates? Unfortunately, no. But we can, make it, very long, like, many years. Yeah. Okay. And then I think there is a question by Naresh. I think this is the second question by Naresh. Bit of a long one. So he's asking for organizations subject to external security assessments like ASE chips. How. do you recommend handling, finding related Okay. I think Emily just replied to him. But, I'll just repeat the question, Seward, if you want to add anything. So he's asking, how do you recommend handling findings related to PLS cipher suites and using PaaS platforms like as your app service that don't allow fine grain control. This enforcing stricter policies at the cloud layer edge considered sufficient as a compensating control. I think it's a similar question from Naresh. Right? I thought I addressed this already. Okay. Yeah. I see. I see. I think both the questions are asking the same thing, is it? Psycho Should be the same. Yeah. Okay. Alright. I think Emily has already responded. Harish, I hope that, resolves, you know, whatever you're asking. And, also, you know, replied to your question, so should be good. Let us know if that answers what. you're asking. I think that is it. I think we've answered everything. Yep. That brings us to the end of this webinar. Thank you, everyone. Thank you all the attendees for joining joining this session and making it so interactive while we while we were, presenting live. Thank you, Suvad, for the demo and the, extraordinarily well detailed presentation that you took us through. I hope everyone, you know, who joined the session found it as useful and valuable as I. The chat was quite, it was it was quite, fired up today. So glad to see all the activity. Glad to see all the action. And, Awesome. I hope hope everyone, you know, joins our upcoming sessions starting next week. Please check out, the CloudFlare website to sign up for our upcoming webinars, and we'll also be sending some promo emails. If anything catches your attention, please please feel free to register for the upcoming sessions. With that, thank you, Suwad. Thank you for your time, and thank you for doing this for everyone. And thank you, Emily, for supporting with the q and a. Thank you, everyone.