Understanding valid HTTPS certificates with Linda Ikechukwu === [00:00:00] Hi there. And welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try LogRocket. com today. My name is Paul and joined with me is Linda Ikechukwu. She is a developer advocate over at Smallstep Labs and is an active educator in the space, spreading knowledge of infrastructure and security. So we're here to talk about her latest talk from this year's React Summit called Bring Development Closer to Production with Valid HTTPS Certificates. Welcome to the show, Linda. Thank you. Hi. I'm happy to be here. Yeah we're excited to have you. Cause this is a topic that I'm sure you've seen Linda. It gets glossed over all the time. It's like HTTP and HTTPS. It's one of those things in the back of our minds. And it could be slowing us down or hindering the way we are [00:01:00] mentally modeling the way we're developing. Stuff, but I'm going to leave you the expert to really talk to us a little bit about that before we step into talking about, security, HTTP and HTTPS, could you just tell us a little bit about what you do in the space and what you're working on right now? Yeah, sure. Hi everyone. My name is Linda Ikechukwu. And like Paul mentioned, I'm a developer advocate at SmallStep Labs. And SmallStep is in a nutshell in the business of making it easy. For teams to secure distributor systems with TLS certificates and as a developer advocate, my duty is to try to right now I'm very much active in the which stands for public key infrastructure ecosystem and just trying to educate about how certificates can be used. To secure systems and just help developers because PKI is a very strange and quite [00:02:00] complicated them and like fields. So we're just trying to. Yeah, abstract that layer for developers and so they can focus on what they do best, which is building stuff while we take care of things behind. So that's where I am at the moment. I'm just doing a lot of education and outreach. Yeah. Well, Thank you for joining us. I'm sure there's going to be some folks listening that maybe it's their. First time even considering throwing HTTPS on localhost, which I know is something we're going to be talking about. If somebody were to say, Hey, okay, I know HTTP, HTTPS, and TLS have worked with this before. Maybe they've deployed a server or reverse proxy. What would you say to those folks when you say PKI? What is PKI That sort of that previous mental model is missing. So if you've ever deployed. Anything on HTTPS, then in a sense, you [00:03:00] have made use of PKI because PKI is the term used to define like the totality of everything that goes into managing digital certificates and renewing them. And digital certificates are like the bedrock of HTTPS. So in this sense, you've interfaced with PKI. Yeah, it's one of the ways I guess we could interface with PKI if I'm, if I'm understanding correctly. Are there other things that go into your considerations when you're educating folks about PKI that go beyond what we just mentioned. Usually it's considering the knowledge level of folks that I am my audience and a major audience are usually DevOps engineers and IT infrastructure guys. They have much more knowledge about PKI because they have to interface with servers and devices a lot. But when my audience are front end [00:04:00] developers, I try to keep it down a notch and simplify everything because I know that for front end developers, it's just to build stuff that people get to see and they don't have to interact with servers and devices that much. So PKI, it's really not something that I would expect a front end developer to be very versed in. for this podcast, I would just try to make sure that I simplify everything so that anybody with any knowledge level can follow along. Gotcha. So when we're talking about maybe, you know, developing something, if you're a front end developer and you want to throw something up into production, there's this concept that you mentioned of dev productivity parity. Can you talk to me a little bit about what you mean by that term and its significance in the development lifecycle? Yeah. So one of the main principles of software development is to maintain dev prod parity, and that's basically means to keep [00:05:00] production staging and development as similar as possible. To avoid running into undetected bugs, because, if your development environment or your staging environment is far off different from production environment, then it will be difficult for you to replicate errors that you come across on production in staging or development to fix it. uh, this talk is just based on the premise that. If your production website runs on HTTPS, then it makes sense that your development environment and your site should also run on HTTPS so that you can easily replicate bugs that arise due to, HTTPS complications on production and replicate it in development. So that's the whole idea. What's an example of. Maybe something you've seen in the wild of the difference in the, the HTTPS security between local and production come [00:06:00] into play and hinder a team. for, um, majority of instances and use cases, local host does actually behave like HTTPS. But there are some cases in which it doesn't. And you have cases where there's like miscontent. Uh, A couple of frontend developers might have run into, mis content errors where your page is composed of content delivered through HTT p s and content delivered through H T T P. , Because you probably use like a JavaScript library from a http based c d n or it could be, , you need to locally test third party APIs or libraries that require he c P S. Now, you can't do that on localhost. , Other scenarios where localhost does not behave like HTTPS when you need to test secure, cookies across browsers. And secure cookies only run on HTTPS, but don't run on localhost for all browsers. So if [00:07:00] you're dealing with special situations like this or use cases like this, then you definitely need to set up HTTPS on your local development because , you wouldn't be able to identify and resolve these issues with just local host. Gotcha. So it seems like there's two angles here that we're talking about where it's productivity for the developer, you know, parity between your local and production environment, but there's also some tangible setup that needs to happen in order for some of this development that you're describing to actually take place on the local host, whether that be interfacing with CDNs, APIs, et cetera. Yeah. If folks wanted to experiment with HTTPS on local host, what are some of the barriers to setting that up and running with it? So I think one barrier is that, usually , for production and like for staging um, , most developers would usually use a public web, certificate authority, and the most popular one is less encrypts [00:08:00] that automates like. Certificate issuance and renews every 90 days. But then the problem is that you can't use, something like less encrypt for your local dev environments the World Wide Web Consortium, which is like the body in charge of, that makes decisions on how the web runs and all that prohibits public web CAs from issuing certificates to. , Local environments. So you can't make use of a public see like, less encrypt. So I think that will be one challenge because it's setting up a production site to run on HTTPS. HTTPS using less encrypt is quite straightforward and very easy, , but if you want to do that for your local environment, then that becomes a bit impossible and you have to find alternatives, which is what I'm here to talk about. Awesome. So before we hop into [00:09:00] talking about those alternatives and that which is offered by small step to make it easier could we run through the example of like what let's encrypt looks like if folks like haven't gone through the process of doing an HTTPS the way it's traditionally done, and that can maybe help us orient HTTP. where small stuff comes and fills us in to bridge that gap. , so usually if you want to deploy a site yourself most web server services like, um, Netlify Ghost or even GitHub pages all have , LessEncrypt embedded. So you don't need to even interface with LessEncrypt directly. It's like just click a button and, that happens. Behind the scenes, so it's usually not something that most people give a lot of thoughts because less encrypts kind of automates the entire process. And most web server services already have this embedded into their process. So it just happens [00:10:00] seamlessly. And just to outline sort of the parties at play when we for example, issue assert, cause there's going to be some differences in the governing bodies and the consortiums and, how they interact with maybe a production server and how they interact with the local host. And. The difference between that , I would hope to highlight. So if we were setting it up on, you know, let's encrypt on a production server, there would be some steps such as interfacing with the CA authority, changing some TXT or CNAME records in your DNS configuration. I was wondering if you could walk us through that hierarchy so we can just understand the players that come into the picture in a production environment. When I talk about digital certificates or a TLS certificate it's, um, in a nutshell or in the lowest form, it's like, a document used to share public keys that will be used to encrypt and authenticate messages exchanged between a client and a server. So [00:11:00] there are a couple of parties involved. To explain this, it just comes down in how HTTPS works. So HTTPS stands for Secure Hypertest Transfer Protocol, and it's just a step ahead of HTTP. And... When you type in a URL into a browser and see the padlock sign, that means that a HTTPS connection exists between the web server that you're, Retrieving information from your browser and a couple of parties involved in making this happen. First of all, there's the certificate authority, which is what less encrypt is. And then there's, of course, the server and the clients. So typically to get a certificate from a certificate authority, now is just a certified body capable of issuing digital certificates and also serves as a.[00:12:00] I don't want to get into complicated details because there are a lot of, things involved in making this work, but if you want to get uh, certificate from a certificate authority, first, you request one and , that's the server request one, every server that you visit that has the padlock sign on has a digital certificate, So the server request one and the certificate authority sends like a challenge for it to solve to verify that it's, um, has the control. So that's when you see make some changes to your DNS file, you know, add like a test document or something, TST documents. That's part of the challenge that the certificate authority is sending. For you to verify that this server has control over this domain name that you're trying to secure, get a certificate for. So that happens, and when you successfully modify your [00:13:00] DNS file and solve the challenge, and then a certificate is provisioned for that server. And so on the client side the browsers have been pre set up with, um, a couple of certificate authorities that they are to trust. So when it's, a client reaches out to a web server to retrieve information, it first asks for, its certificate that if it has been specified that it's running on HTTPS and the server presents that certificate to the client and the client goes through its list of, certificate authorities to check if it has that particular certificate authority that issued the certificate for the server. Okay. On its list of trusted certificate authorities. And if it does, then it initiates the connection and now they can exchange information and that's how your web pages are being rendered. That's what goes on. that's the basis of a TLS handshake. Linda, thank you so much for walking us through that, [00:14:00] that interaction pattern. I think there's a lot of people listening that would find it refreshing and informative to really highlight those fundamentals when we look at the differences in how we can make this happen on the local host and just to pave over some of these details to make sure I understand. So when I do a challenge. The challenge is actually editing the DNS, as you tell me, right? So that's the DNS saying that's sort of the operating. Operator, excuse me, saying, yes, I have control over this DNS and the server are one of the Yeah. So that's you prove your authority over that. Yeah. And then the CA being maybe less encrypt in the running example we've been talking Yeah. who gives them the authority to do this, That's, That's a good question. So, I forget the body in charge. but there's a body. There is somebody, There is a governing body in charge of, certifying public web CAs, and it's called the [00:15:00] CA Browser Forum. Gotcha. Okay. And I know there's got to be folks listening who have maybe looked in their own AWS infrastructure or, insert cloud name that have maybe seen something like a internal signer or an internal CA. Can you highlight the differences between Let's Encrypt and what one of these entities might be? In a private context, So there are two types of CAs, which is you have the public CAs and you have private CAs or private signers. Public CAs, which we have been encrypt. Only issues certificates to publicly accessible domains or websites, and then privacy is used to issue certificates and enable HTTPS for private domains, you know, domains will be assessed um, without like a public internet connection. So , that's the basic difference between them. So if you're within a [00:16:00] cloud environment or within your cloud environment and have an internal sign, that means that that's. Internal CA is for issuing certificates to endpoints or URLs within that internal network. gotcha. And I'm sure this is a good basis. Maybe to now jump off. Cause I, my brain's already buzzing about okay, this feels internal signing and stuff. It feels like we're thinking in the right direction of how to make this work on local host, which is sort of the topic of the talk you gave at react summit. So before we hop into talking about Small step and step CA, step C live, we're going to get into those tools offered. I just want to remind our listeners that this podcast is brought to you by LogRocket. So if you are developing locally or you're developing on the team in your staging environment, you're trying to squash bugs, find errors faster. You can use LogRocket to surface different analytics, trends and patterns and find things that you didn't think you could find. So you can spend [00:17:00] more time building your app and less time. debugging, less time in the console, less time digging through all sorts of different error logs that you might get from your front end application. So head over to log rocket. com today to try it for free. So for folks developing locally, Linda you're, pushing forward to this narrative of dev productivity parity, and we want to get HTTPS on local hosts. We talked about some reasons why the beginning and Small step really offers, these things called step dash ca and we talked about CAS and step dash c l i and I'm guessing that's a c l I for us to sort of bundle these tools together and work together. So could you talk to us a little bit about how we could interface with Small Step to bring this experience to local host? Yeah, so step CA is a open source tool. We have a paid tool, but this is the open source tool that everything is based on. As the name kind of suggests already, it's an open source [00:18:00] certificate authority for private networks. So I I already explained the difference between, public certificate authorities and private certificate authorities and mentioning the limitations, why, public certificate authorities cannot be used in internal networks. And if anybody is interested, I have written a blog post on the, three different strong reasons that prohibits public CAs from being used in private networks, which brings the need for internal CAs like StepCA. So you can either self host StepCA and use that to issue certificates within your private network. And So , that's what StepCA is for. Now, since public CAs cannot be used to issue certificates to internal networks and local environments, then you need to set up your own CA. I have to mention that you can totally create a TLA certificate for your local environment without a CA. In such cases, remember [00:19:00] that I mentioned that a CA issues certificates and acts as a root of trust, or in other words, signs a certificate. Now, in such cases, issuing a TLS certificate for your local environment without a CA, you'll be signing the certificate by yourself. And the problem with that is that for self signed certificates, , there's no route of trust to verify that , the origin server is who it claims to be. And then again, browsers don't consider self signed certificates trustworthy. And we still mark it as not secure. Despite it's running on HTTPS. And so that may also be an issue where you will not be able to replicate. errors that occur in production and I think this is an issue with, the using Gatsby's HTTPS flag because when you use Gatsby's HTTPS flag, what you get is a self signed certificate. And that's why most times, using Gatsby's [00:20:00] flag, you still get the error of like this site is not secure. So what the, um, recommended way is to create your own offline local certificate authority. Get your system to trust that certificate authority, and then use that certificate authority to issue certificates for your, local sites and local environment. Um, Now that might sound like a lot, but with uh, , open source tools, steps here and steps, c l I, that's. You can achieve this in like five steps. So like I mentioned, Step CA is an open source certificate authority and Step CLI is just a CLI tool that makes it easy for you to interface with Step CA. Perfect. So could you outline for us maybe what those five steps would look like if somebody wanted to set that up using step CA? So first of all, you would need to, of course, install Step CLI and Step CA. They are [00:21:00] available with, um, in different packages. If you're on a Mac, you can just install using the command brew install step. But if you're on Windows or, Linux, then you can find installation instructions on our docs, which link will be included in the. Podcast page, so you mentioned if folks are on Mac, they can just do brew, install step. And I think a lot of people listening will be in that boat you know, get it installed. So what's the next step to configure this certificate interaction with small step. So that one command installs Step CA and Step CLI. And then the next thing would be to create and configure a local certificate authority on your device. And that happens by running the command Step CA init. Um, , You'll be presented with a couple of options to fill out. , First one would be to ask what you would like to name your new PKI OCA and you can literally name it anything. [00:22:00] And it will ask you what DNS names or IP addresses you would like to add to your new CA. So it's, basically what, IP addresses would you like your CA to run on. And since we're running on localhost, you just enter localhost. Then to ask you what IP or ports would you like your new CA to be bound to, that's localhost, um, 127. And then to ask you just a couple of other things, ask you for a password and after you've. Provided with all that information, you will have a CA ready to go. And then the next step after initializing a CA would be to install the CA root certificate into your system trustor. Now remember that I mentioned that a certificate authority usually acts as a root of trust. And that's why it's much more [00:23:00] preferable over self signed certificates. And to get your, you need to get your device to trust your local CA so that when you visit a web browser or try to assess it, when you visit your local projects on a web browser, it doesn't come up with the error of this URL is not secure. And so, to install your CA, it will certificate on your device to get your local environment to trust. VCA is using the command step certificate install, and then we path to the CA certificate, which will be provided to you in the previous step when you initialize the CA. So this might be a lot to follow cause it's just audio, but then I have a video about this and that will be provided. Um, on the page of this podcast. So if you want to follow along, you can just follow along. And then after that, the next step is just to start the CA server. And you start that by running the command step [00:24:00] CA, and then the part where the CA is hosted. And when you start your server, , now this is the time when you create a certificate. For your local server Okay. So if I may step in for a moment, Linda, just to summarize where we're at so far. We're going to be running brew install step, which is going to give us step CA and step CLI. You can run and set up the certificate authority. You can take the roots. The root of trust, for the CA, and we have to add it into our OS, our operating system. Is that the right spot where that gets inserted So our computer can trust it, or is it something like with a browser? Oh yes. So you install step and step CA, you start the CA and you install the root certificate to get your OS. So, Your device to trust the CA. So that's where we're at now. And then we can use Step CLI to issue the certificate. For our local [00:25:00] processes. Gotcha. Okay. Now, when we enter the root of trust into the operating system of our, host machine, does that automatically cause all the browsers that we might use to test that piece of local process and we don't need to do anything else. like Chrome So, um, , each device has like a system trust store. And you can do a Google search to check how to assess that. And if you check it, you, you see a list of all sets of public certificate authorities that your devices trust. So what you would just be doing is just adding that local certificate authority to that list, and once it's there, um, even um, tools like Call will trust certificates, from that certificate authority, so you don't need to do any other setup. Gotcha. So we essentially have a locally running certificate authority at this point. What are some other options that , you've seen people use in the past? If any, I don't know, maybe this is something that's [00:26:00] not typically done for folks to simulate that sort of local CA, Or is it just not done? Do people usually just gloss on over it? it's not something I know that's very common. So like I mentioned, before getting into this, most, um, developers that run, build with React or Gatsby , Gatsby has this HTTPS flag that you can enable and React has something similar, but the thing with that is that there's no certificate authority. You're just, , issuing a certificate by yourself. It's called the self signed certificates. And that's why most times when you still visit your local sites. That has the HTTPS flag enabled, you still get, the browser error that says something like, Oh, this page is not secure because you're using a self signed certificate. So the way to get past that error is to have a certificate authority that is trusted. By your, system trust. Gotcha. Now, when we're [00:27:00] maybe making this react application and we have step CA up and running, we have a, certificate. How do we actually put that into our code? , is there a 90 day expiration window? Is there a challenge phase just like we have maybe with ACME and Let's Encrypt? How does that differ with the local version here? Let me answer your first question. Step ca has options for you to set up the validity of your, certificates so you can even set up your certificates to Be valid for a year if you want it to be, but we have, a default validity period of 60 days. But you can set the lifetime of your certificates to run for as long as you need to. But then it's recommended that certificates have short lifespans. Thank you for answering about the time there, because I would assume if it was something local you could have full control and do whatever the heck you wanted uh, which may not always be the case with a. Public CA. And I just that's a nice difference You can do whatever you [00:28:00] want. We just have and adjust. Yeah. So my follow up question then would be like, let's say we get an expiration, the team is comfortable with the certificates created. How do we integrate that into the code? Is there any differences? And using step CA to how we might do this in a production environment, because we want to close that dev productivity parity gap here, right? So I'm up until setting this up I'm wondering if this is where that parity is sort of minimized. What minimizes the parity is when you get a certificate for your local environment. Now your local environment is running on HTTPS, which mirrors exactly how your production HTTPS site is running because your production HTTPS site has a certificate from a certificate authority. Now your local, um, web server or your local environment now also has a certificate. From a certificate authority. So whatever issues you have on production, [00:29:00] you can easily replicate on local because now your local mirrors exactly how your production is running. And when I was talking about the steps to get, um, a certificate from your local CA that we've just talked about how to set up. so you just go to your React or like your Node. js server. And there's a, create server function, Node. js has the create server function where you would just easily insert the certificates that was created in the previous steps. I talked about how you would just run a command to create a certificate and a private key. And when you do that, using steps here. It gives you a certificate file and a private key file, and you just go to your Node. js server and insert those two files into the create server function under the set and key properties. and you get those files [00:30:00] into your project folder, obviously, so you can easily reference the parts. great. Okay, thank you for walking us through that. . So just to wrap up some of these ideas that we're talking about HTTP and HTTPS, what do you think is the number one lack of understanding or maybe misconception that developers have, or you could foresee them having when they try to Run with HTTPS on their local environment or maybe it could be like TLS and HTTPS in general as an educator What do you think is the number one place of misunderstanding that you would like to call out, So, um, why I, I I am from questioning a couple of devs using HTTPS in local is not very commonplace and that's usually because, Without the help of public CAs like LessEncrypt that automates the entire process of getting a certificate, trying to get a certificate manually using a [00:31:00] tool like maybe OpenSSL is incredibly complicated, and that might not be something that most front end developers will have to deal with. So that's why this practice isn't exactly commonplace, although it helps. When you run into certain issues, like I mentioned in the beginning. So it's that sense of difficulty that makes this not commonplace. And that's where steps here comes in because it's handles everything. it gives you the experience of using less encrypts, but on your local environment. So it just automates everything. And so that you can go ahead and focus on doing. What you're supposed to do, which is building stuff and not have to worry about setting up, you know, a CA by yourself and Resolving challenges by yourself. That's what we want to do build stuff spend more time building stuff and less time debugging the tools that are being put out today are really lending themselves to doing that, just like log [00:32:00] rocket, spend less time in your web console. So you're trying to have people spend less time with the SSL primitives, which is fantastic, because I know many of engineer have bashed their heads against the desk, needing to debug those things. Linda, I know you have a Twitter, it's Miss Linda. And you also have a personal website. If people wanted to visit your website, maybe you could just name the address and URL so folks can visit. And do you blog anywhere or write if people want to follow up with more of your content? Oh Okay, so right now I don't actively blog. I maintain an active blog, but that's on a totally different topic That's about it's for Folks who are trying to pick up, technical writing as a career you know, advance their technical writing career, because most of what I do in my job is really technical writing and trying to explain complicated. Concepts to people using simple language. So I blog a lot about [00:33:00] the concept of technical writing and that website is called everythingtechnicalwriting. com. But apart from that, you can find me on Twitter at underscore Miss Linda. I don't have a personal website yet. I would get to that soon, I guess. yeah, we'll be looking out for that. We can always add it in if you happen to boot it up. But Linda, thank you for your time coming on and bringing us back to some fundamentals about TLS, HTTP, and HTTPS. Yeah, sure. It's been a pleasure for me. Likewise, thank you.