Difference between certbot and lego

[lonix1]

I've used Certbot for a while. But now I'm using a hoster for which there's no DNS challenge support. Which led me here, to Lego.

What is the difference between lego and certbot? Can I use lego instead of certbot?

(I read the docs, but couldn't find this info.)

Thanks for your help!

[ldez]

Hello,

lego and certbot follow the ACME RFC8555.

The main difference is the language: we use Go and Certbot uses Python.
lego is not a drop-in replacement for certbot because we don't have the same options, there are some other minor differences but both tools are here to generate certificates with the same approach.

[lonix1]

Thanks @ldez! That is very nice to know. I thought that lego did something else completely.

Out of curiosity: if lego does the same thing, more or less, why did you guys build lego? Was there something about certbot that you didn't like?

(Personally, lego supports DNS challenge for more hosters, so I am definitely going to use lego from now on.)

[ldez]

Out of curiosity: if lego does the same thing, more or less, why did you guys build lego? Was there something about certbot that you didn't like?

lego is used as a library inside Go projects.

[lonix1]

I just discovered that traefik uses the lego library.

[mholt]

Out of curiosity: if lego does the same thing, more or less, why did you guys build lego? Was there something about certbot that you didn't like?

To add more context and history here:

In summary, this project started long before "Certbot" as we know it today existed, and it was originally designed to be used as the ACME library for the Caddy web server.

In 2014 I was working on a web server project. Let's Encrypt was preparing to launch around shortly after I released my new server, and so it was the perfect time to integrate their service and make HTTPS just work automatically.

So, this project was started in 2015 long before the public beta of Let's Encrypt. At the time, ACME was not a standard. Certbot wasn't called Certbot yet, and it was still a niche experimental tool.

I collaborated with a developer named Sebastian (@xenolf) who thought it would be great to implement ACME in Go and have it used in a web server. So he wrote the first client implementation of the ACME protocol in Go, being this library. Here is the first commit:

commit ea47f1137a1ad9b2bf375f4e276137147cdfc689
Author: xenolf <[email protected]>
Date:   Mon Jun 8 02:36:07 2015 +0200

    Base implementation with registration support

We discussed things in Slack while he made commits. For the time (as a totally new and experimental protocol), his implementation was quite good and carefully-thought-out. He chose to implement a simple CLI so he could easily run and test his implementation, since I didn't have the server integration finished yet. (IIRC the initial vision was never to have a production CLI, it was only for testing -- since it would be integrated directly into Caddy.)

My first commit to the project was an automated test:

commit 7e12bcd8009490283fc5770c9c51e6fb89b986bd
Author: Matt Holt <[email protected]>
Date:   Sat Jun 13 09:00:18 2015 -0600

    Test NewClient
    
    Just a simple test to make sure a Client gets set up properly

Anyway, Caddy 0.8 was released with built-in support for Let's Encrypt, and we showed what was possible by having sites automatically be served over HTTPS, thanks to this package.

Eventually, xenolf had to step down from maintenance and @ldez graciously took up lead development.

We were happy to see an upcoming proxy/service mesh, Traefik, use this library as well.

Eventually, our priorities diverged sufficiently that I went on to develop ACMEz and switched Caddy/CertMagic over to using it. But this project still holds the legacy of being the first ACME client written in Go, and the one that powered Caddy for the first several years, and still powers Traefik's certs.

So to come back around and fully answer your question:

if lego does the same thing, more or less, why did you guys build lego? Was there something about certbot that you didn't like?

Because back in the day, it wasn't intended to do the same thing. People used the CLI in production since they didn't want to replace existing infrastructure. They liked it for its static binary (as opposed to a Python behemoth with dependencies) and cross-platform ease. The intended vision was for it to be embedded in web servers.

In hindsight, we are realizing that CLI tools are NOT ideal for long-term certificate automation. Even the Certbot engineers are questioning why Certbot is still recommended by Let's Encrypt. (Of CLI tools, though, I think Lego is the best for its static binary and broad DNS provider support.)

It is best to transition our infrastructure over to integrated, fully-native ACME clients like what Caddy and Traefik do.

[lonix1]

Wow that must have been a "blast from the past" experience for you. Thanks for the history.