James Renken: The Goal is Secure Website Traffic, Everywhere

Ivan and guest James Renken, Site Reliability Engineer for Let’s Encrypt and attorney, discuss everything you ever wanted to know about certificate authorities but were afraid to ask. Let’s Encrypt, a nonprofit certificate authority, has issued over a billion FREE SSL certificates and has a modest goal: secure website traffic everywhere.
Listen Now
James Renken

Site Reliability Engineer, Let’s Encrypt

Listen Now


Google Street View privacy concerns

What is a certificate authority (CA)?

How ACME protocol allows owners more control over certificate issuance

How DNSSEC makes domains harder to hack


IVAN STEGIC: Hey everyone! You’re listening to The TEN7 Podcast, where we get together every fortnight, and sometimes more often, to talk about technology, business and the humans in it. I’m your host Ivan Stegic. My guest today is James Renken, Site Reliability Engineer at Let’s Encrypt. He’s also an attorney and the managing member of sandwich.net, one of the original hosting providers on the internet and online since 1997. Today we’ll be talking about Let’s Encrypt, its history, origin, its mission, why encryption on the web is important, why privacy is important, and we’re also going to find out what James’ role is in the organization. Hello, and welcome to the podcast. It’s great to have you on, James.

JAMES RENKEN: It’s great to be here. Thanks for having me.

IVAN: So, we were just talking about Google Street View and you said you had your house blurred out. I didn’t even know that was an option.

JAMES: It is. I don’t remember exactly what I had to go through, but it was one of those typical Google experiences where I found the option, submitted a request and about a week later it happened.

IVAN: Wow, a week! That’s a really fast turnaround for such a big company. I wouldn’t have expected that.

JAMES: Yeah, I’m not sure why, but it was very good to be able to do. The reason I did that is because I have to pay attention to such a wide variety of threat models and privacy and security issues and so on. This one actually didn’t arise from Let’s Encrypt. It came out of my law practice, because I unfortunately had a couple of cases that were pretty controversial and got pretty unpleasant and wanted to start thinking about those kinds of physical threats unfortunately, which is not a lot of fun.

IVAN: So, you would recommend doing this to people who are experiencing some sort of threat, that is, maybe from a spouse or a former spouse, or maybe they’re being stalked. I’m reading into what you said, so correct me if I’m wrong. Where would be the recommendation here?

JAMES: That kind of scenario, very much so. Of course, it’s only a very small thing that doesn’t do a whole lot to protect against all the different things that you might run into, but it’s something, and as long as it’s something that’s pretty reasonable, pretty easy to do, I figured that I might as well do it for privacy.

IVAN: I’m going to look into this directly after our podcast and we will certainly put some links on the web, on the podcast episode page as well, as we find out more.

So, I’ve actually been looking forward to talking to you for the longest time. I want to hear more about Let’s Encrypt and all the good it’s trying to do in the world, and we kind of just dove into the whole Google Street View thing right away and you mentioned your law practice, so I would like the audience to get a good sense of your background and your experience, and then we can maybe talk about Let’s Encrypt. Let’s start with formal education. You’re an attorney and you have a bachelors in linguistics as well. Tell me a bit about that.

JAMES: I am. What basically happened, to give the short version, is I was interested in computers from a very young age. This was in—not the early days of the internet, but certainly the early days of the web—and played around a lot with the relatively early web at the time and went to college. Linguistics seemed interesting. I’ve always been more of a verbal than a math type of person. So, having the analytical type of major, type of discipline, was really appealing without having to go into advanced calculus, compiler design, which of course is a big part of formal computer science. So, I’d been involved in computers for a long time both before my formal education and then after college.

 Unfortunately, I graduated college into the tech crash of around 2001, which is why I ended up in law school, another analytical field that seemed like it would give me a chance to both make a decent living but do some good as well. And then, of course, I graduated law school into the huge crash of the legal market in 2007, 2008 [laughing].

IVAN: It happens. [laughing]

JAMES: [laughing] But at that point I had tech to fall back on, very fortunately. And I like it here. I like it in this field a lot.

IVAN: Did you practice law after you graduated, or did you go directly into tech? What was the first thing you did?

JAMES: I looked around for legal jobs, but things were very slim, and I ended up getting a systems engineer sysadmin job with my law school, since they knew me from when I was a student there. I had helped them identify a problem as being a rogue DHCP server, and I guess that stuck in their memory.

IVAN: That’s quite an achievement to have identified that and been known for that. So, you were in system admin, and then you single-handedly started and still operate the same hosting company?

JAMES: Yeah. I had started the hosting company when I was still in college and kept doing that on the side, but I’m a much better sysadmin, systems engineer, SRE, whatever you’d like to call it, than I am a business person. So, it never really was commercially successful but it’s a great way to be able to play around with platforms, especially open source projects that don’t really have a home at my full-time job. And it can also be a testbed for interesting things and interesting implementations.

IVAN: In preparation for the podcast I checked out sandwich.net and noticed that it had a design overhaul. It looks great.

JAMES: Thank you. The old site I think dates to right around before I started law school, so it had a good 10-15 year run there, and it was showing its age. So, thank you. I picked Hugo to design the site and manage the templating and layout and so on, since we used it very successfully for Let’s Encrypt, and it’s been great, very straightforward. And all I really wanted was a static site, so it is very much suitable for that purpose.

IVAN: And the threat model on the static website is so much lower on static web pages anywhere than it is on something that’s powered by PHP, and has a MySQL backend or any kind of database back end isn’t it? So, I’m sure that checked the box for you.

JAMES: Definitely. I have a lot of thoughts about what I might explore if I were really designing a “real dynamic” powerful website or CMS now. But I haven’t had to do that in quite some time, and it really, in the time that I’ve been in industry, has evolved from a thing you can pretty achievably do on the side to an entire set of disciplines and specialties.

IVAN: It’s amazing how it’s all evolved hasn’t it?

JAMES: It really is astonishing. And, I’ve been skeptical about how that evolution has happened. But I just saw something the other day remarking on how everyone using similar frameworks—which are, of course, very complicated—can make things like accessibility much easier. Whereas if you’re templating your own static website or writing something from scratch, you’re not really going to be able to do that well, and that’s something I hadn’t thought about. That’s pretty compelling.

IVAN: That is a compelling reason to use a framework, isn’t it, especially good ones that are being maintained, you can rely on that accessibility feature later on in the evolution of your site as well.

JAMES: I really like that, so I’m glad I went with Hugo.

IVAN: Yeah, it looks great. It looks great. So, I heard you use system admin and site reliability engineer almost interchangeably. Let’s talk about what your role is at Let’s Encrypt as Site Reliability Engineer and what the overlaps are with system admin.

JAMES: Definitely. It’s very difficult to be precise about it because everyone seems to have a different idea of what site reliability engineering is as a discipline or a job title or a mindset. I use that interchangeably because I come out of the traditional operations, UNIX sysadmin, ISP hosting-type world. So, those are my roots. As an SRE, I’m learning and really enjoying what I think most people agree on the definition of bringing more science and bringing more metrics and a real engineering mindset to the extent that it does fit into operations and into DevOps, which itself is sort of an ambiguous, ill-defined term.

IVAN: And so, your day-to-day responsibilities at Let’s Encrypt are, I’m going to guess, you’re responsible for letsencrypt.org, or you’re responsible for the Let’s Encrypt product in some fashion?

JAMES: For the product, I do very little with the frontend website. I make the occasional suggestion, or tweak how it’s hosted and so on. But most of my work is on the product, the backend certificate authority service and API. So, I do a lot of work with the internal configuration orchestration, operations and trying to make those better, more efficient, more reliable.

IVAN: So, let’s talk about what Let’s Encrypt actually is. Let’s Encrypt is a free automated and open certificate authority. Now, that sounds like a whole bunch of technical jargon in some ways, so let’s try to unpack that and try to describe what Let’s Encrypt’s product actually is. Maybe start with the end. What is a certificate authority or CA?

JAMES: We are basically a trusted third party that a lot of software, including all of the major web browsers, they trust us to certify that a particular public encryption key is controlled by the same entity that controls a website like, let’s say, google.com. So, our cryptographic signature on a website certificate says, Yes, this certificate belongs to someone who we believe controls google.com and not to, for example, some sketchy person next to you at the coffee shop who is intercepting your Wi-Fi connection.

IVAN: So, you’re basically the arbiter of truth when it comes to the encryption and google.com saying and us believing who google.com actually is?

JAMES: Exactly. One thing that is important to emphasize though, is that we don’t necessarily, with the type of certificate we issue, which is the dominant type of certificate on the web, we don’t say that google.com is Google Incorporated, or Alphabet or LLC, or whatever the appropriate entity is. We just know that the person who has the certificate is the same person who showed to us that they have control over the domain google.com. That’s it. So, we don’t necessarily say that the entity is trustworthy, or the entity is the entity you would expect. But we do say that the entity is in fact, the one who, at the time we issued the certificate, controlled that domain name.

IVAN: Okay, so that’s a very important distinction, and I think that’s a good enough distinction in the internet and online these days, because it allows for automation, and it allows for doing things in a more streamlined fashion compared to the way it used to be done.

So, you’re not the only certificate authority, there are others. All of them, from what I understand, are for profit. All of them charge a lot of money to have an SSL certificate or an encryption key verified. You are the only nonprofit that does that. Is that correct?

JAMES: As far as I’m aware I think that’s correct, unless you count governments, as there are at least a couple of government-run CAs out there as well.

IVAN: Okay, but I couldn’t buy a certificate from them, so, I would discount them then. [laughing] Okay, so, you are confirming that the organization that has the certificate, that has the SSL encryption capability when you visit a website, is the same—no, that whoever has that certificate has control over the domain that you are visiting, and I guess by extension, the company or organization that has control over the domain is likely to be, most of the time, the company you think you’re dealing with at that domain.

JAMES: Exactly. Most of the time that is the case. And, of course there are exceptions to that. Malicious parties will take advantage of, like minor typos or that kind of thing. That is not something that certificate authority protects against for the most part.

IVAN: And the certificates are free? What?

JAMES: Yeah, they are. We work on a similar model to a lot of different free services on the internet in that we reduce the need for a large customer service staff by making our product completely automated from end to end and providing very limited or no customer support. As part of that, we have to me, an astonishingly good community forum. A lot of community forums and community support gets a bad rap, because there are few answers to be had or inaccurate answers. But we have some absolutely excellent volunteers, and our staff participate as well. But that’s the only way you get support from us. We don’t help you with your web server’s configuration, we don’t really answer questions. We’d love to, but at our scale with millions and millions of certificates, that simply isn’t doable with a nonprofit model as far as we’ve been able to do it.

IVAN: So, you have a salary. You work for the nonprofit. There are other employees that work for Let’s Encrypt. How is Let’s Encrypt funded?

JAMES: It is almost all donations. We have some grants. We have sponsors from throughout the whole internet ecosystem. A lot of companies and organizations are very generous and sponsor us, and we do have some individual donors as well.

IVAN: That’s amazing. That’s exactly how a nonprofit should work, and the fact that it covers the operating budget and that you’re still able to provide this free service, that’s a testament to how I think the World Wide Web was originally envisioned.

JAMES: I really like working here partially for those reasons. It’s wonderful to be a part of this, and we do it all on what is a very small budget for the work that we do. It’s still more than a lot of people might expect. It does take an absolutely enormous amount of very careful and exacting work to run a CA.

IVAN: The description I gave earlier said Let’s Encrypt is a free, automated and open certificate authority, and I think we covered free and automated, and I think we covered certificate authority, but we didn’t quite spend time on the open part. Why is that word important in the description of the certificate authority?

JAMES: So, we are available to pretty much anybody who wants to use the service. We don’t have any barriers of payment processing or anything like that. We just make it available because we think everyone should have access to the, at a station, the ability to have encryption that’s trusted and recognized by web browsers.

IVAN: So, the idea is, encrypt all the things, this is important and we want to try and reduce the barrier of entry to doing that, is what I’m hearing.

JAMES: That’s exactly it. The barrier to entry, before, of money, was really significant for a lot of people. Because even though to you and I, $12.00 a year from a discount certificate provider is not that much, it’s almost trivial. There is a huge world out there to whom that is very, very nontrivial, and even to people who are pretty lucky like us, spending $12.00 for every single little experimental side project website we want to spin up doesn’t really make sense. And so there was that real barrier to adoption of HTTPS, which is to say, encrypted traffic, using SSL and TLS.

IVAN: Was that the only reason it was so hard to get SSL, was the barrier of cost? Because if I remember correctly, it used to be pretty difficult to get those certs generated and installed on Apache and on Nginx and wherever else we were going to put them. I feel like it was harder previously as well.

JAMES: It was definitely that technical barrier to entry too. We ourselves have been very lucky to have other organizations, especially the Electronic Frontier Foundation, work on client programs that make it a lot easier for people to interact with our service and get and install certificates. So, the most popular client for the ACME protocol—that is how you interact with Let’s Encrypt and other CAs now as well—is Certbot, which is an open source project managed by the Electronic Frontier Foundation. And, like you were getting at, it makes it much, much easier to automatically acquire and provision a certificate, set up your web server to use it and then automatically renew it. And the automatic renewal is a really big part of the automation that we help deliver and that helps improve the ecosystem.

Because another technical barrier wasn’t just acquiring the certificate, it was remembering that it needed to be renewed, which was one of those infamous things, especially on the one end of the scale was side project that you’re really not paying attention to. Or on the other end of the scale, a very large enterprise where keeping track of all of the different moving parts is a responsibility of someone in some department who may have left.

IVAN: Or went on vacation or was having a bad day. There’s so many variables.

JAMES: Exactly. And if you have a two- or three-year certificate and it only needs renewing that often, then it’s very, very easy to forget that or processes to change or people to lose track. And automating the renewal makes that so much easier. Of course, getting the automation in place is one of those hoops to jump through, but for most people, Certbot makes that very straightforward.

IVAN: So, this is a really interesting idea in which the opposite of what you would naturally think would be the smart decision, actually makes a better service. And, what I mean by that is, most certificate authorities out there, and for the longest time on the World Wide Web, it was thought that you should have an SSL certificate that is as long as possible. Get the two-year one, then you don’t have to worry about it, and when it comes around to renew, you’ll just renew it, and you’ll be happy about that. And what you guys are doing is you’re saying, No, that’s wrong. You should have a really short expiration, like 90 days, and you should renew it sooner than that, and it should be easy to renew, it should be automated. So, it’s kind of the opposite of what you naturally think has actually worked out even better for consumers on the web, for users, for developers, even for business people.

JAMES: Exactly. And there are always scenarios where Let’s Encrypt won’t be the appropriate choice. There are definitely systems where they need to remain as they are. You can’t really configure a new certificate very easily, so it makes sense to have that longer validity period. And that’s perfectly fine. We try not to compete with other certificate authorities, because there’s a lot of room for customers who need more support, who need a longer certificate for a particular reason, or who need a certificate with extended validation, where the authority actually is verifying the corporate identity of the requester and not just their control over the domain. So, we definitely don’t see other CAs as competitors. We have our place in the ecosystem that I think was an underserved one, and there’s a lot left to serve and cooperate on.

IVAN: So, let’s just be clear about that. Other certificates you’re going to get on the web for a browser actually are additionally verified. They have extended validation, and so it’s not just the organization that controls the domain name that you’re visiting. It’s maybe a site visit, maybe a phone call, maybe other verification methods, to make sure that the company that’s claiming to have that domain actually owns that domain and is the company it’s at. And so, that gives you a better feeling when you hear “extended validation,” or you might see a green bar that has additional information in your browser. Is the encryption any different? Is there a higher level? Is Let’s Encrypt’s certificate somehow the lowest entry? Is it less secure than any of the other certificates that are out there?

JAMES: The encryption is exactly identical. So, the only real difference there is in how much has been validated about the certificate owner, what pieces of information have been confirmed. There’s a lot of questions and a lot of controversy in the industry about whether end users really pay attention to any of those signifiers and how valuable they are. That’s a very controversial debate and even if I wanted to weigh in on it, I’m definitely not a user experience expert, and that’s who I’d really want to hear from on the issue.

IVAN: That makes a lot of sense. From my personal perspective, if it’s secured, it’s secured. I’m happier that it’s secured than if it’s in plain text as far as I’m concerned. I think what Let’s Encrypt is doing is a wonderful job, and I’m just so happy that we’ve been able to use it as much as we have, and that we’ve been able to deploy it the way we have as well. It’s really been quite astonishing.

I want to ask about the ACME protocol, because you mentioned that earlier, and you also said something about others also using it. Tell us a little bit about what that is? Is that the actual heart of the API? Of the automation?

JAMES: It is. So, that is on the side of getting the certificate, rather than the side of how the end users interact with your site using the certificate. So, ACME is the protocol that people who want a certificate use to communicate with our API and request it, give us the information about what they want and then follow up on the status of their request and then receive their certificate. So, it is an open standard. It’s now what’s called an RFC or Request for Comments, which is sort of a counterintuitively named series of documents that are essentially internet standards or proposed standards. So, anyone can implement this for a client or for a server, and there are now other certificate authorities who are offering ACME endpoints to their subscribers which is fantastic. That’s what we want, because it makes for a better, more interoperable client ecosystem.

IVAN: So, the same protocol could be used to order or renew a certificate from someone other than Let’s Encrypt?

JAMES: Absolutely. There is one CA called Buypass based out of Norway that I believe is offering certificates to the public with ACME. So, you can specify their endpoint using regular Certbot and it works just fine. And I believe some larger commercial CAs are offering it to enterprise customers as well.

IVAN: That’s really exciting. That’s exactly what you want when you come up with an open standard is, you hope that that kind of adoption permeates the web.

JAMES: Exactly. And being able to use the same client for multiple needs is just fantastic. That’s what we want more of.

IVAN: Now, you were telling me that you were really excited about an extension to ACME, and you were hoping we would get a chance to talk about it, and I would love to hear about the extension to ACME that you are really excited about. What does this do?

JAMES: So, this interacts with DNS, the domain name system, to let a domain owner exercise more control over when and by whom a certificate can be issued. So, there’s already a mechanism to publish a record called a CAA, or Certificate Authority Authorization Record linked to your domain name that says, I only want certificates for my domain to be issued by this certificate authority or by these few certificate authorities.

So, if you want to exercise very careful control over who can get an SSL or TLS certificate for your domain, which is something you probably want to do, you may not want to allow any one of the dozens of CAs to issue, only the ones that you intend to use to get certificates. And that capability is already out there. This extension will let you go a little bit further and say, I only want this particular account ID at my certificate authority of choice to be able to issue.

So, as it stands right now you can already limit issuance to, let’s say, Let’s Encrypt. But anyone could still use Let’s Encrypt to get a cert for your domain name. This will let you say, Only allow my Let’s Encrypt account to issue, and that’s crucial to exercise much tighter control. And that’s already available in our staging and testing setup, and it will be coming hopefully quite soon to our live product.

IVAN: So, it sounds like this reduces the threat vector and the whole surface of attack here by yet another amount. What is it actually preventing apart from someone else not being able to generate those certificates for you?

JAMES: That’s what it’s preventing.

IVAN: Oh, I thought you mentioned BGP hijacking was part of—or is that what you’re talking about?

JAMES: That’s pretty much what I’m talking about. An attacker could subvert the routing protocols that the internet uses, to basically stand in front of your website and say, Oh, I control the website, everything is fine, and I authorize this certificate to be issued, and then get a certificate for your website. This requires a pretty noisy attack that’s called BGP hijacking, where the attacker basically hijacks a part of the internet’s route to reach your website. It requires a pretty high level of sophistication and a very high level of risk tolerance for the attacker. It’s not a cheap or easy attack. But if you’re an activist, or running a large company that deals in significant transactions, then this is the kind of thing you might well be worried about.

IVAN: Got it. And why is there mention of a horrible goose and DNSSEC? Tell me about that [laughing] what that horrible goose is about. I was looking at that in the slide deck.

JAMES: So, I’ll start with the silly part. I made my presentation about this just a little bit after Untitled Goose Game was released, or I should say, unleashed on the general public, and this is a wonderful game. Everyone should go find it and try to play it, it’s really delightful. It’s also a really good example of the hacker mindset. In the game, the goose goes to make mischief and break things just for the sheer ornery joy of it. And a lot of attackers these days work for much more boring, but maybe more motivating financial reasons, but it’s a really nostalgic look back at the hacker mindset of 15 or 25 years ago.

So, anyway, I use that as an analogy there, because there is an extension to DNS called DNSSEC that will let a domain owner cryptographically sign the responses to DNS queries, making domains quite a bit harder to hijack. But DNSSEC is notoriously difficult to implement and fragile. If you have a provider doing everything for you who supports DNSSEC, it’s a reasonably safe bet. But if you’re doing it yourself like I did, it’s very easy for things to stop working, or keys to expire or for all sorts of unpleasant mismatches to happen and break your domain name for the better part of a day, which if you’re running something of any seriousness, that’s a very bad day.

So, DNSSEC is something that I recommend if you’re very risk conscious, and also you have a lot of operational sophistication, you have really solid monitoring, you have the resources to put all of the effort into running this properly. But, if you don’t have all of those resources, and you’re not willing to go chase every little risk, maybe it won’t be the best or safest choice for you.

IVAN: Okay. Point taken. One last thing before we wrap up. According to the Let’s Encrypt annual report from 2019, Global HTTPS usage—that’s SSL-encrypted traffic—hit 80% of webpage loads for the first time in history on the internet. 50% of our sponsors were U.S.-based and 50% are based outside of the U.S., and this is from your annual report. Can you explain what that means? What does it actually mean and is the goal HTTPS everywhere, all the time?

JAMES: That is the goal. We have data from, I believe it’s from Mozilla, showing that of the data they have, HTTPS usage on just the percentage of page loads that do go over HTTPS, has been steadily growing, especially since Let’s Encrypt launched. And we broke 80% which is amazing, which definitely leads into the goal, we would love for that to reach 100%. The reason being that, if you’re running a website, even if you perceive it as something unimportant, even if it doesn’t have any user credentials, doesn’t have anything financial, if it’s just something relatively trivial, nevertheless, if an end user connects to your site, and they’re on a malicious network, that unencrypted connection is an invitation for the malicious network to introduce ads, introduce spyware, introduce something worse, and encryption prevents that. End-to-end encryption prevents a malicious network from intercepting and manipulating traffic. And, no matter how seemingly trivial the site may be, that can be really important.

IVAN: I agree. The only thing at that point that’s not encrypted is the URL itself.

JAMES: Exactly. And that hopefully in the near future as a new extension to a standard called encrypted SNI is adopted, even that will be better protected. Right now, everything that comes after the host name in the URL gets encrypted when you’re going over HTTPS. But pretty soon that host name can be protected as well with encrypted SNI.

IVAN: I didn’t realize that the part after the domain name was also encrypted right now. That’s actually nice to hear.

JAMES: Yeah. And that can be really important with some ways that sites are constructed with like tokens and IDs in the URL.

IVAN: So, do you think it’ll be possible for someone in the near future to fire up a web browser, type in a domain name, hit submit—at which point there’s a request to a web server somewhere, and everything from the point of hitting submit to the point of the connection and any traffic that comes back to the browser, is all encrypted?

JAMES: Absolutely. We almost have that, with the exception of that host name. Even once that happens, in a lot of cases it will still be possible to infer from looking at the session more or less what it is. If you’re going to a company’s website that they self-host, then even if the domain name is protected, the fact that you’re connecting to that company’s network is pretty much a giveaway.

IVAN: Yeah. So, there’s still ways to infer, but the vast amount of data that used to be available just by looking at the connections and where they’re happening has been reduced now?

JAMES: Exactly. And there will always be that arms race with attackers, the back and forth. I’ve heard about some research on looking at the exact length of even an encrypted HTTPS request and response, and with enough knowledge of the website you can still very accurately infer, in a lot of cases what the end user is looking at. But then there are potential defenses against that by padding or randomizing the amount of data, and then the attackers will think of something new.

IVAN: [laughing] Yeah, it’s always an arms race, isn’t it James?

JAMES: Always.

IVAN: It’s been a joy talking to you. I was just thinking about how we haven’t gotten to even other topics like encrypted email and whether that should be a thing, and VPNs and how many there are and which ones we should actually be using or not using. Would you join us again at a later date for another episode?

JAMES: I would be happy to. When it comes to VPNs, I definitely would love to talk about that. Encrypted email is something where I think we need a usability expert to talk to as well.

IVAN: [laughing] Yeah. There’s just nothing you can really—I’m not even going to get into it. I read an article the other day about it and wholeheartedly agreed with the author who basically said there is really no reason to do encrypted email. Even with the systems we have right now, you’re basically just encrypting the body of an email, and if someone forwards the email and doesn’t encrypt it, you’re pretty much exposed at that point anyway.

JAMES: I tend to agree. I would love to do a really truly deep dive into how email works, but this podcast would have to be about, I would say, five times as long.

IVAN: [laughing] Maybe we could split it up across five episodes. Well, thank you so much for spending your time with me today. It’s been a real pleasure talking with you.

JAMES: Likewise. Thank you so much for having me.

IVAN: James Renken is Site Reliability Engineer at Let’s Encrypt, and you can find him on Twitter @jrenken and Let’s Encrypt at letsencrypt.org. You’ve been listening to The TEN7 Podcast. Find us online at ten7.com/podcast. And if you have a second, do send us a message. We love hearing from you. Our email address is [email protected]. Until next time, this is Ivan Stegic. Thank you for listening.

Continue Reading

Subscribe and listen wherever you get your podcasts.