The essential guide to SSL/TLS security & certificate automation (2026)

Hey, everybody. We are going to get started. Thanks everybody for joining us today. This is "Stay secure with SSL and TLS," part of the urllo expert series, which is a series of webinars our team here at urllo is putting on in the spring. We'll be taking a quick break over the summer and then back in the fall once everybody is back in their seats and thinking about their OKRs and KPIs for the year. We're really excited for this one. This is a conversation with Wesley Kirkland, who is a long time kind of a collaborator and partner of ours. Wesley is senior cloud development and DevOps engineer, and has been a a partner of urllo for a little while. I'm going to do a little bit of housekeeping just before we get into the presentation. First order of business, everybody here will get a copy of the slides and a copy of the recording after this. So watch your email inbox. The email that you used to register for the webinar is where you will receive that. We have a couple of other pieces here just to go through. If we have time, we will do a little bit of Q&A at the end. So if you happen to have a question, feel free to drop it into the chat. You'll also see that over on the right-hand side of the chat window there's a little bubble with a question mark in it. You can also submit a question directly there, and then those will be published into the chat. And we can bring them up on screen so Wesley can can take a swing at answering those towards the end. Last little bit of business, I'm just gonna talk a little bit about urllo here. I see that we have a couple existing customers in the chat already. But if you don't know, urllo is the complete URL redirect manager for all your websites and domains. We help you consolidate, manage redirects. Use cases like rebrands, mergers and acquisitions, migrations, content changes, sort of end of life of systems, that sort of thing. We are trusted by over a thousand organizations globally, working with IT, marketing and SEO teams across the globe. And I can see in the chat we have people joining in from Indianapolis, from Knoxville, from the Philippines, from Belgium. It's great to see so much global presence here in the chat. Last little thing I'll talk about before we introduce Wesley, is we are offering, exclusively for webinar attendees, a free link audit. If you have a website and you want to see how many broken links, redirect chains, redirect loops, see if any of that is affecting your traffic, your user experience, your search equity. Feel free to click that button at the top. It says "free link audit." And from there you can request an urllo expert come take a look at your website. We can set up a meeting and talk through if there are any opportunities there. With all of that said, I'm gonna introduce Wesley. Wesley has been safeguarding organizations' critical infrastructure for more than fifteen years. He leads a team of ten across infrastructure and cloud functions. He is a public speaker speaker and educator, and is very well known in the Knoxville community where he lives. And you can go to his personal website, wesleyk.me, to see some of his research and case studies over there. Wesley, welcome to the urllo expert series. It's great to have you. Thanks for having me, Matt. It's great to be here. Is there anything else you'd like to just say to introduce yourself? I think you all have about covered it here, and I'm super thrilled to be here. And I love the audience that we have going on today. I'd also like to mention with anyone if you have any follow-up questions both during or especially during the webinar, please post them in the questions. If you have anything personal, feel free to connect with me on my website or find me on LinkedIn. Pretty easy to find me there as well. Terrific. Well, Wesley, I'm gonna pop myself off of the screen here and turn it over to you. Thanks so much. Take it away. Thank you very much, sir. So as Matt was saying, my name is Wesley Kirkland, and today, we're gonna be talking about SSL and TLS. So for a little bit of start on here, what is SSL and TLS anyways? So SSL and TLS is the foundation of what is protecting you and your websites and users online. It's verifying your website's identity against fraud. It is encrypting all your traffic between the browser and the website. And historically, we've always seen it as little green padlock up in the upper left hand side of your browser. Your browser's not gonna have that padlock anymore. That was deprecated quite a few years ago. We also used to see kind of the EV, and you also used to see, like, Bank of America in there. That's also been deprecated out. But the biggest thing, and we'll be talking a lot about this today as well, is the standards for SSL in here. They're set forth by the CA/Browser Forum. You'll commonly hear that referred to as the CAB Forum. For all public certificate authorities. So your certificate authority is going to issue your certificate... Sorry. Issue your certificate, and that's gonna be your Let's Encrypts, your DigiCerts, your Sectigos, and all the other CAs out there. They have a mandatory membership to the CAB Forum to be able to issue the certificate in here. But what I also want to talk about in here is we hear certificate a lot, and we can think of certificates kind of in the consumer context as you get a gift certificate for a holiday or a birthday party or something like that. But what we're actually talking about in here is certificates as in their X.509 context in here. That is the international standards set forth by the International Telecommunication Union or the ITU for short, and they are what are defining the public key standard. And that's defining all the attributes in there such as the common name, the public key interchange. But more specifically too, when we're talking about certificates, we're talking about the public key hash of the private key. And more specific, on the certificate, the server is only presenting in its public key to the end user out there. And we can talk more about private keys later if time allows us to. So let's go ahead and go on to our next slide. So understanding SSL versus TLS. So one thing, there's a big misconception out there is we say SSL certificate. There's a weird nomenclature out there. It's actually a TLS certificate, but a lot of the nomenclature and terminology out there uses SSL and TLS interchangeably. SSL as a protocol was actually deprecated in 2015, and this is another thing too. There's the certificate layer of it for SSL and TLS certificates Then there's the protocol layer of it for SSL versus TLS protocol. And that is how the data interchange between your client, commonly known as your browser. Or if you're on, like, Android or iOS and your application's communicating, that would be the client there is communicating to the server as well. But you'll also note in here too is TLS was originally defined in 1999, So they are very, very old as a whole. And I forget exactly when SSL was defined, but it was defined, I believe, in the late 80s, early 90s as a whole too. So there's kind of a big common misunderstanding that TLS and SSL were commonly compatible specifically on SSL v3 and TLS v1, but they weren't. That's not really something we're gonna be talking about too much today, but I'm always happy to answer questions on there as well. But one thing too I wanna talk about in here, and there's more information later on in today's webinar, is not all SSL or TLS certificates are created equal. And it matters a whole lot where you're getting them from. Specifically, when we're talking about websites, this isn't as much as an issue when we're talking about more modern day websites. And if all of your clients are very modern, say, all of your users are accessing your website or your application from a modern day device, like the latest up to date macOS, latest up to date Android, iOS, Windows PC, etcetera. Because all of those roots are going to be very commonly trusted out there, and all those trust stores are out there as well. And this additional data will be later published on with with urllo or in a blog post published in coordination with this webinar on urllo's website as well. But when we start talking about legacy versions of iOS and Android versions, even Windows, the previous ISRG X1 root CA isn't necessarily... Sorry. Their current one, ISRG X2 CA, isn't necessarily going to be ported backwards compatible to Windows XP because that's the end of life operating system. But older root CAs would be on there. So you always have to kind of think about where do I sit, who will my clients be when I'm actually issuing this? Is it all gonna be highly modern clients? Am I gonna have some older clients in here? But also too for the purposes of this webinar today, we're only gonna be talking about publicly trusted CAs. And that's going to be our public PKI. PKI being "Public Key Infrastructure." There's another form of PKI out there of private PKI. When you run a private PKI, there's a lot of helpers out there. You can run this through, like, active directory certificate services. AWS has a PKI through ACM. Digicert also has a private PKI solution as well. But none of those PKIs have rules enforced by the CAB form. But let's go ahead and head on over in here. So when we have our SSL certificates. And I hope everyone's kinda getting a good chuckle out of this one right now. But we have our chain of trust. So we're not explicitly trusting our web server at the end of the day, but we can kinda think about our chain of trust in here. So if we think about this more in Star Trek terms, we trust Picard. Picard trusts Geordi. And Geordi trusts Ensign Tony. So we can think of our web server as Ensign Tony at the end of the day. So while we are not directly trusting Geordi or Ensign Tony at the end of the day. Because we trust Picard, he is the certificate authority in this matter, we automatically trust him down the chain. And a great technical detail I always love to add, this one particular slide here is... Say Picard, the Root CA, his self-signed certificate is valid till December 31st 2050. Geordi's is valid till December 31st 2025. Geordi can only issue certificates good till his expiration date in here, and this is a really good thing to note. This is kinda more towards on enterprise as some certificate management. But the intermediate CA or even just the CA on top that is the issuing CA for your certificate can never issue a certificate longer than it is valid for. That's always one really good note to think of when you're trying to do, like, scanning and if you have one that is expiring. There's only really been one historical issue with this, and this was the most relevant common one in history was when Let's Encrypt, I believe, their X1 route was cross signed, and that cross signed route did expire even though they still had a valid chain of trust coming up in there. But I wanna talk about too, when you actually go visit a website. So we're gonna visit Ensign Tony's website right now. The server is gonna present its server certificate, also known as a lead certificate, and you can kinda think of this as a visual aid here. So think of our certificate structure as a literal tree. So Picard is gonna be the trunk of the tree. Geordie is going to be the tree branches, and Ensign Tony is going to be the leaf on the tree, which is why it's known as a leaf certificate. So we have to validate that all of those paths are good up into our tree, which is how we're going to validate it. This gets into our certificate chains later too. Because when we navigate to the website, what's gonna happen is our browser is going to validate that whole certificate chain. And even more specifically, which I wasn't able to touch on, but it is here on the slide too, for you to validate the authority here, the root certificate is always going to be on your local computer. It has to be. That is the only way that is gonna be validated. And I'll use Microsoft Windows as a great example here. You'll have the system root store, but when you're using browsers such as Chromium based browsers or Firefox, they actually use their own certificate stores, which is why I was talking about it matters where you get your certificate from. Because they're not necessarily going to use the Microsoft Windows certificate store. So let's let's talk a little bit about our certificates as a whole. So we've got about four primary certificates that we can go in and issue. So we've got our single single domain certificates, multi domain certificates, wildcard with SAN certificates, and multi wildcard certificates. So I wanna talk about these primarily from a security and a price perspective in here. So with our single domain certificates, this is what we're always going to primarily be issuing, and this is what we like to issue here at urllo as well. And the reasoning for this is with automated infrastructure... And this isn't specific to urllo on this next bit this is just general certificate and security guidance. With a single domain certificate, it could be example dot com. It could be mail dot example dot com. It could be my super cool application dot example dot com. With that single domain certificate, your key material is unique to that certificate cycle. There are exceptions to this if you go out and buy a certificate. You can just renew the certificate without changing the key material. I recommend that you don't do that for security reasons. But your key material is only unique to that domain slash record, specifically the record on there. And with certificate automation, this is incredibly scalable. And there's a lot of other advantages too, which we can talk about when we get into wildcards. Where you're not gonna have to figure out where is my certificate installed with my additional wildcards. The cons of this is, if you're doing manual certificate automation, that becomes more and more ineffective with our certificate life spans going down in the coming years. You have to have automation to utilize single domain certificates. Now we also have other certificate options out there such as multi domain certificates. These are called multi SAN, and they have a historical name called UCC or Unified Communication Certificates. You saw the UCC name a lot with Exchange. With kinda like on premise Exchange servers or you have mail, SMTP and web mail. And because you would buy that multi SAN certificate... and SAN stands for Subject Alternative Name. When you issue a certificate, there's a field in there called CN or Common Name, and that's gonna be example dot com in this case. And when you had a SAN or a UCC on it, you can issue it for multiple records or subdomains as they're commonly called on there. We can notate that with our example, mail, FTP, etcetera. Now these are always going to generally cost money. There are ways of issuing these through Let's Encrypt or other CAs as well. And, keep in mind, Let's Encrypt is always going to utilize ACME protocol or Automated Certificate Management Endpoint in here. Now there are a couple cons in here. You can only have two hundred and fifty SANs in a certificate. I don't really consider that a con myself. If you have that many endpoints being managed on a singular certificate, you really need to start breaking up your endpoints and your certificates to start rotating out your key material. And the reason for rotating out your key material is you want to make sure that you have different key material out there in case your key gets compromised. Now we can also start talking about wildcards. These come with some complexity issues, and they also start coming with significant costs with them. This will cover star dot example dot com, but by contrast it won't cover example dot com. But they will always come with the default SAN, generally speaking, so you can get the apex of your domain of example dot com. They're really cost effective for subdomain slash subrecord heavy environments. So say if you have a singular IS server and your customers access it for customer dot example dot com, and you're not using utilizing a F5 BIG-IP or other load balancer to terminate there, and that load balancer doesn't do SSL termination for some reason, those wildcards are very cost effective for you at that point. They also make multi wildcards in there too where you can cover, like, six domains or something in there. But the downside with wildcards is, if you don't have great audibility or a CMDB or just an automated certificate tracking system, you'll start to lose where that certificate is going on. And when you start bringing this into manual certificate management, the whole process breaks apart, and I've seen this firsthand. And I've had to develop processes around this, and it's not something that you necessarily wanna do. My advice is always stick with single domain certificates. Cloud providers especially make this incredibly easy to do nowadays. Now the big thing that we really wanna talk about today too is the CAB Forum is shortening certificate lifespans. So 2011, you used to be able to have a certificate that was valid for ten years as a whole. When I started managing certificates, they were valid for three years, and that was in about 2015, 2017 era. And then they brought them down. It's currently 398 days. We just like to say it's one year because most CAs will typically only issue it for about one year. Coming up in in 2026, bringing it down to a solid 200 days. 2027's down to a hundred days, and in March 2029, they're bringing it down to an incredibly strict 47 days. And now there's a caveat on this with our DCV validations. We're gonna talk about DCVs more here in a minute, but it's domain control validations. That is only going to be good for ten days. Now there's three different types of DCVs, and specifically when we're talking about just kind of our generic in certificates... And then we shouldn't even think about generic certificates as being any less secure because they're fundamentally not less secure. They're just as secure as any other certificate. They're still perfectly secure in here. But before we start talking about that more, I wanna talk a little bit more about the CAB Forum. They are founded in 2005, and as I described earlier, your membership for being a public CA is mandatory in here. And the CAB Forum is comprised of browsers, supplier of any certificate-based application, and some interested parties. You don't necessarily have to be a member to to be to... Sorry. You don't have to necessarily be a member to have to use their rules, but being a member is optional in there, and that means you get an influence and a vote at the end of the day. And what I'll also note too is sometimes, especially if you go to websites like SSL dot com or something, you'll see that they're still off selling five year certificates or something like that. They're not really selling you a five year certificate. They're selling you a certificate on auto renewal, and then you can go in and utilize the same key material or even rotate out your key material. They're selling you a certificate at a reduced cost. So with this, what certificate authority or CA should you use? You might recognize some of these logos out there. GoDaddy. Everyone's familiar with them. They typically generally operate in the consumer space. There's also GoDaddy's business registry. That's more in the domain space out there. There probably is a CA portion of that. They're not as widely trusted out there, but you're typically not gonna run into any trust issues for day to day operations. Let's Encrypt. This is what powers urllo at the core of it. They honestly power about forty, fifty percent of the Internet, if not more. You use a Let's Encrypt certificate every day of your life, and you're not even realizing it at this point. There's also Sectigo. They're very heavy in the enterprise space. They're incredibly well respected, very trusted as well. AWS ACM, great choice as well. They actually run their own CA. They're cross signed, I believe, with other CAs is how they started out. And the reason why I say AWS ACM... So if you're running on public cloud infrastructure, specifically within AWS or Amazon Web Services, with your load balancers, instead of them bringing your own key material and managing it out there, you can just utilize their own CA. It integrates perfectly with, like, AWS Route 53 and maintain your certificates through them. But we also have other options such as Digicert. Same reputation as Sectigo, in my opinion. I think their reputation's better. I've seen a lot of the research that they're doing into post quantum computing. They have the ability to issue certificates that are both secure for pre quantum computing and post quantum computing. So those certificates, their cryptography can't be broken once the quantum computing age comes. They hire some wicked smart PhD researchers that they just spend all their time doing that. And then we've also got Entrust. And Entrust used to be very heavy into the enterprise space. They kinda got an outdated interface, but I also want to talk about them in here because last year, Chrome by Google, they initiated a distrust event of nine of the root CAs. And this starts to speak to, just because you were trusted at some point doesn't mean that you will continue to be trusted throughout the end of time. So the bottom line now is certificate management and automatic renewal is mandatory. The risk of a certificate expiring to your brand is too high. So with urllo and Let's Encrypt, we utilize Let's Encrypt to secure your domains and redirects. Let's Encrypt is a highly trusted and and flexible CA. All of our plans right now automatically provision and maintain your certificate. We also allow you to bring your own key material to us if you so desire. And, apparently, with Let's Encrypt offering nine day certificates, we automatically we automatically start renewing your certificates thirty days before. And with the upcoming CAB Forum changes that I was just talking about a few minutes ago, we're adjusting to those as those plans come through there. And all this is done with the ACME protocol coming in here. I do wanna talk about Let's Encrypt for a moment too. So Let's Encrypt, they were founded with five founding principles to be automatic, secure, transparent, open and cooperative. They're not just a self-contained organization. While they are not-for-profit, they have many partners out there. And a lot of these partners come from really big organizations that you actually have heard of in here. But I'm not necessarily gonna talk a whole lot about them today. So I do wanna talk about some really good tools to leave you with some nice material today. So a few in here is my personal favorite, crt.sh. So you may or may not have heard of Certificate Transparency logs, also known as CT logs. So crt.sh, it's a website by Sectigo the CA. You can go in there, type in a website or even just a host name, figure out its entire certificate issuance log over time. And figure out like, basically, all the metadata of it in here. And a little fun fact in here starting with Google Chrome 68 and above. When you visit it, for that certificate to validate, not even just their OCSP, which is also going away, but CRL logs, that certificate has to be in CT logs in here. Otherwise, it is not going to validate. There's also SSL Mates tools out there for What's My Chain Cert to help with your certificate chain like we were talking about earlier. They also offer a CA record generator so you can help secure your website an additional layer. Say, only Digicert or Let's Encrypt can issue certificates, but they can only issue nonwildcards. Or Digicert can only issue wildcards but nonwildcards. SSL Shopper, they offer a lot of great tools such as CSR decoders, certificate decoders, certificate conversion. And then the open SSL binary. We've probably all heard of it at some point in time to help generate CSRs, convert certain key material on disk. All these are local. And I did wanna add a little fun fact for everyone, so you can go and tell everyone. OpenSSL was almost called OpenTLS back before it was released one day. So about DCV methods. So these are going to be the methods of how you validate for your certificate in here. So with our DCV methods, we have four methods that are really gonna be seen on the Internet, but only two of these are realistically going to be used. So with bigger CAs, you'll see a lot of email based methods out there. And one of these was actually just deprecated last month, and that was the Who Is based one. And that one's kinda been deprecated for quite a few years, but it was officially deprecated last year, and it became significantly harder once GDPR came into play with European domains. But US based domains and other ccTLDs started to take note of it as well. There is a you can still construct the email, so, like, administrator, admin, webmaster, postmaster do a lot of those. But these can't be used to validate out wildcards because all you're doing is verifying you can verify the email of it, not necessarily that you can verify DNS on top of the domain. You can also do a DNS text record for that record on the domain that you're doing. Then there's just straight up DNS text record. Not every CA supports this. I've seen Digicert do it a lot where you can add in a DNS validation string on top of your text record on the apex of it. So the, say, example dot com's main text record. But what you'll see a lot in here is DNS01 and HTTP-01, and these are practical demonstrations specifically on HTTP-01. And what you'll see a lot too when you're utilizing tools such as certbot with the ACME protocol in here is they're going to use the DNS01. So they'll create the underscore ACME dash challenge on the domain or the record that you're generating. They'll do a tie-in to your DNS. Say if you're utilizing Cloudflare or other well-known DNS providers, you can simulate this in a home lab environment very quickly or even in your enterprise environment very quickly as well. They'll create it. The CA, such as Let's Encrypt, will come out and validate it because it's on public DNS. Once the ACME protocol basically sends a 200 response, it will go in and delete that DNS record so you're not creating mass DNS records that are just going to be trash at the end of the day. Issue your certificate. You can also do HTTP-01 practical demonstration. Have your server up on port 80. This is only good for one server, basically, one domain in here. And in the .well-known directory on the server, it'll have that same unique string. CA such as Let's Encrypt will come out, read it, make sure it's there, and then issue out your certificate. So we were talking earlier kind of about our validations too. So I like to call this the 3V's of certificates. We have DV, OV and EV in here. So specifically with Let's Encrypt, and this is where I was talking about too... Just because we're utilizing a lower validation level does not inherently make the certificate less secure. The certificate is still fundamentally the same encryption. But Let's Encrypt is going to utilize domain validation or DV in here. It's the same amount of encryption. All we're doing is just validating that we have control over the domain. Specifically, Let's Encrypt mainly utilizes DNS01 and HTTP-01. There's TLS-ALPN-01, but it's not widely used, as out there. But there's also additional validation levels in here such as organizational validation or extended validation. You'll see these utilized a lot by businesses, specifically EV validation for financial institutions such as banks. PayPal is a great example. Bank of America, where they really want these due to certificate warranties. And these certificate warranties are very valuable to these organizations. For if there is ever an audit failure and a duplicate certificate is issued for these organizations. They have all the legal paperwork in play, to where they will be paid out at the end of the day. But for most use cases, when you're protecting your blog, your personal website, your business' WordPress site or something, DV validation is perfectly fine for ninety nine percent of the Internet use cases. And with the upcoming DCV validation changes going down to ten days in 2029 there, your DV certificates make it even better. CAs are automating OV and EV certificate issuance with their ACME protocol as well. How they do this with the OV and EV is still yet to be fully determined. So we wanna make sure too. Just to send it home. You're gonna have to automate or you're gonna fall behind in here. There are companies, I've met these companies before, and you send money through these companies. They have full certificate management teams that are out there, and they have a lot of automated processes. But then they also still have humans that are rotating out certificates. Every organization has that one process that has to rotate out a certificate manually. And a lot of times, it's, hey. This came up. How do we do this every it was three years. Now it's one year. Now it's going down and down, and you gotta figure out how to do it through automation because the manual renewal just is not sustainable. So our priorities right now for everyone. Automate certificate issuance and renewal across all of our services. Make sure you test and validate in your lower environments, particularly in your staging environment before shortening your renewal periods in production. Particularly in Let's Encrypt, they have API rate limits. You want to make sure that you actually, in a containerized environment, you want to make sure that you're not gonna run into any rate limits if your entire containerized environment has, like, disaster recovery event, and you're not gonna slam it there. And one thing I really wanna touch, and I touched on this earlier... Particularly with your wildcards, but this is just a great IT security in here. You wanna audit all of your assets, but also your web endpoints. This is critical information security control number one. Used to be called your SANS Top Ten, I believe, but it was number one in there. This is how you make sure that you know everything that your organization has. This is your number one critical information security control point in here. And educate all stakeholders in your organization of this. And my particular client right now, recently I had to go in and do an education event on the implications of certificate expiration. And that education was invaluable to the entire organization. So with that, I just wanna say thank you for joining us today. I had an absolute blast presenting on this to everyone. Great. Thanks so much, Wesley. It's been definitely a pleasure having you. Really appreciate it. Thanks everybody for joining. We do have a question in the chat. So we'll just pull that up on screen and make sure that we get a chance to answer that. And then I'll do a little bit of housekeeping, and we'll let everybody go back to their lunch hour, breakfast. It's quite quite late for a few of you. I see we have some people in from the Philippines. So This is a question from Karl. Wesley, I'll just read it out quickly. The question is very straightforward. What is Certbot? You referenced it a little bit earlier. Do you mind just giving us the the ten second, thirty second explanation of that one? So first, Karl, I went ahead and dropped a link in the main chat for for you there. But Certbot, it is some is part of the EFF, the Electronic Frontier Foundation in there. Certbot is the primary tool that everyone is utilizing to interface with the ACME-based protocol. You can load this on your servers such as if you have a Ubuntu, Linux server, or even Windows server. And it is what is gonna interface with the ACME-based protocol to go in and pull down your certificates and auto load them. It also has a lot of integrations with, like, Windows, IaaS server, NGINX, Apache, Tomcat, etcetera, to go ahead and reload those servers or reload the server services to make sure that the new certificate is loaded in there. Basically, it's your end to end automation platform between ACME and your web server. Great. Thanks so much, Wesley. Really appreciate it. Everyone who's joined, this has been "Stay secure with SSL and TLS" with our expert guest, Wesley Kirkland, longtime partner here at urllo. And part of the urllo expert series, which is a series of webinars that we have been doing over the spring, to bring in different perspectives from thought leaders and experts in IT and marketing and in SEO. We are going to be taking a break for the summer, but then we'll be back in the fall with more expert guests. If you're interested in seeing some of the other webinars and audio in the series, you can see other expert sessions at urllo.com/resources. You can, of course, follow us online. We're on LinkedIn for future events and recordings. You'll be able to see some clips from this, up there. If you have any questions or feedback about this one, don't hesitate to reach out to us. You can always reach a human at team@urllo.com. And if you missed anything or wanted to rewatch, the on-demand recording will be in your inbox shortly as well as a copy of slides. Wesley, where can people find you if they want to get in touch? You can find me at wesleyk.me, or you can find me on LinkedIn. It should be at LinkedIn dot com slash Wesley Kirkland on there. Or reach out to urllo. They know how to contact me all the time as well. Like Matt was saying, I've been a long time partner of urllo for well, I think we're coming up close to a decade now, Matt. I think so. Yeah. Well, thank you so much, Wesley. Thanks everybody for joining, and we'll see you all again very soon, I hope. Take care. Bye for now.