 My talk is about Certificate and the PKI, which is public key infrastructure. It's usually hard. And from kind of anecdotal, like, evidence, I know a lot of smart people who've avoided this particular rabbit hole for a long time. And prior to my current role, I've avoided this as well, you know, and felt there's some shame for not knowing more. The obvious result was this vicious cycle. I was too embarrassed to ask questions. So I never learned. Eventually, I was forced to learn the stuff because I joined, well, a PKI open core company called Small Step. Check us out, you know, open source stuff on github, github.com, small step.com. But, you know, I really wish I'd learned all this stuff sooner. What would help my career when I was working heavily in the service mesh base and network connectivity with proxies. So let's dive into the how and the why for PKI's. So, Jeff, if you could do next slide for me please. Yeah, so, you know, before I get started, here's a brief intro. My name is Kevin. I work as a developer advocate at Small Step and focusing primarily on building out our open source toolkit and community. I really like to nap. So this photo really captures me in my natural state. So, you know, if you saw me at DEF CON in person over these past three days, you know, I was probably the one passed out in the corner. I meant to say hi, but I'm sorry. All right, next slide here. What? Okay, more problems. All right, we're just going to, Jeff, do you want to just, let's just, yeah, we'll just use my face as the main screen. So PKI's, I can make this fun without slides because honestly slides make things more boring anyways, right? So back to PKI. Fundamentally, the math is complicated in my, I'm terrible at math, but the core concepts are really, really simple. And I'm going to try to make them as simple as possible to simplify things, right? Certificates are a way we identify code and devices. And identity is super useful, especially in this kind of distributed architecture age for stuff like security, monitoring metrics, million other things. And using certificates is not hard, but before we can even talk about the certificate we want to use, we have to talk about signatures. Signatures as in digital signatures are really a lot like the physical world signatures that, you know, we use. They are used to verify who sent the message, and they use in the digital space public key cartography or asymmetric cartography. We don't do that in real life. Thank God it would be a pain in the butt. So what it's, it lets you do is that you can prove that someone knows their private key, the private key without knowing the private key yourself. How does this work? Let's kind of use example, right? You can use a public key to prove someone knows their private key. And that becomes really important for authentication, you know, which is really what most people are using certificates for, proving who sent a message. Because, you know, to you to generate a certificate, you need a private key, but to verify a signature, you only need the public key. And you can't generate a signature using the public key, only the private key, right? Keep that in mind. There's two set of keys and this key pair is really, really important for signatures. So I might be the only person who knows a particular private key. And all of you, my audience, if you all knew my publicly, I can sign something and you all can verify the signature. And you can know that the only way the signature was produced is because me is by me because I'm the only one who holds the private key. Another example we talked about, you know, from another perspective, let's say there's an audience member called Cindy, right? I know Cindy's public key. I can know if I'm actually talking to Cindy by using this kind of key pair. The way I might do that is just to generate, let's say, random big, big number and say, and tell Cindy, hey, Cindy, please sign this for me. If the number is big enough, it's very, very unlikely that anyone has produced a signature over this random number that I generated. So if I get a signature over that random number back that verifies, I basically challenged Cindy and got a response for her knowing that, okay, I'm talking to the right person. This is, you know, the core of how certificate based authentication works. I'm using this kind of key pair signing protocol. The math is complicated. We're not going to dive into it. You can easily search on your own if you're more interested. But, you know, if you want to use certificates, that's really all you have to know. Let's see. So that's the easiest way I can boil down certificate based authentication with asymmetric photography to authenticate a person device or whatnot. But there is a problem that we need to address. So authenticate someone, you need to know their public key. So if you're talking to a lot of people, you're going to need to know the public key of every single person. And the second problem that kind of follows that is the way you learn their public key has to be secure. Okay, if we go back to the Cindy example, if someone lied to me, right, and they say, tell me that Cindy's public key is XYZ. But instead of telling their public key, they actually use their own public key, right. They can pretend to be Cindy, because now I'm confused about what Cindy's public key actually is. So if you have a lot of people, like if you have to talk to a lot of people, or more commonly, you know, as you know, architects of big systems, we're talking about like big systems. We have a lot of components talking to each other, right, not necessarily people. Every component needs to know every other components publicly public key. And that can be really challenging and we have to do that in a secure manner. And this is where certificates enter the picture, and certificates can be intimidating but fundamentally also really simple. And here's my kind of Eli five, like explain like I'm five definition certificates are like driver's license right we all have them. They are driver's license or passports, you know, for your computer and code. If you never met me before, and you trust the DMV, you can use my license for authentication. You can verify that license is valid. You can look at my photo here, read my name, you know, it says Kevin computers use certificates do the exact same thing. If you've never met some computer before, you can trust the same certificate authority, aka, you know, the DMV. And you can use this certificate for authentication, verifying that the certificate is valid based on their signature, look at their public key, reading their names, etc. Right. So, essentially a certificate is a data structure, much like our ID that binds a name to a public key purpose is to learn someone's public key. If you don't already know it. And then we have to go back and right how does this solve the whole secure problem of learning people's public key. Well this is where the DMV or in the digital space our certificate authority comes into play. You can trust the certificate authority, which is what signs certificates. You can trust what Cindy is and who she says she is. And we can dive a little deeper into our certificate, you'll see it's you know represented by bits and bytes. This part is actually you know annoyingly complicated. I suspect that the poorly defined manner in which certificates and keys are encoded is probably the source of most confusion. At least, I can say most of my confusion and frustration when I approach PKI's at the start. But just know that when people talk about certificates usually without any additional qualifications, they're referring to the X509B3 certificate. And to make this more relatable, they're referring to some the sort of certificate that browsers understand and use for HTTPS which is HTTP over TLS. There are obviously other certificate formats notably SSH and GPG both have their own, but we're going to focus on the X509 for the remainder of the talk. If you can understand X509, you'll figure out you'll be able to figure out everything else by yourself. And since these certificates are X509s are so broadly supported they have you know you can trust that there's a good amount of libraries that you know support them and they use in a lot of different contexts. Alright, let me check on time. I'm here, I'm the timekeeper and guess what you've got two minutes my friend. Alright, let's let's let's speak things through right okay so X509 was actually blah blah blah I'm going to skip through this little fun tidbit it was created back in like the 1980s for phone books, you know, we need to know that. But what I want getting to is that PKI is really the umbrella term for all the stuff right to issue distribute store use and verify revoke and interact with certain beginning keys. It's a big like database infrastructure because it will encompasses a lot and you know, stuff like the jobs and protocols conventions clients and servers, cron jobs, whatnot, but just know that PKI kind of encompasses this kind of signature to tip kit signing kind of space. So the build your own versus I would advocate for using open source for to start and blah blah blah sorry to skip a bunch. Alright, so let's let's get back here to web PKI. Okay, so what PKI uses, you know, X509 and the beauty of about the you know there's two kind of PKI is that there is the web PKI which is what you're commonly familiar with. But there's also something that I want to advocate for what my talk is really about is internal PKI internal PKI is what you run for your own stuff production infrastructure like services to containers and VMs corporate endpoints stuff that you know you don't want to rely on a web PKI for because you're running internal PKI gives you a lot more control flexibility it allows you to authenticate and established panels on your own stuff to run like secure communications anywhere. And you know, the problem is that the web PKI was not designed to support internal use cases right the last thing I want to mention is that even with a CA like let's encrypt which offer free certificates and automated provisioning you'll still have to deal with stuff like rate limit and availability. Additionally, Web PKI by default have a lot of trusted CAs. So do you really want your, you know, your sort of your internal like services and devices to be authenticated based off external CAs are run by other orgs and located perhaps in countries that you don't trust as much or just outside your own like infrastructure. So what I want to kind of sum up is use your own like run your own internal PKI sorry for not getting screen share to work and having to brush through this check out GitHub you know there is a lot of open source scenarios small step is a great one. If you can hear let me write I think I read that yet. If you have any questions go to Kevin you can email me at Kevin at small step.com, or you can find me on Twitter at devadvocado which is you know, right there. I'll put this in like the comment section. Jeff back to you.