`certbot-dns-multi` - bringing lego's 100+ DNS providers to Certbot

Client dev
1

Hi,

I wanted to announce that I've published this Certbot DNS plugin which might be of some use in the situation where Certbot users find their that nothing is available for their DNS provider. Often, this seems to result in people changing ACME clients or doing things manually. My hope is that this might make a dent in the "sorry, try another client or [something complicated]" forum response that we're forced into sometimes.

It's available from https://github.com/alexzorin/certbot-dns-multi via snap and pip.

There seems to be a lot of duplicated effort in the ecosystem when it comes to DNS plugins and lego has a lot of eyeballs on it (I think both Caddy and cert-manager either used it or vendored the DNS providers) and this was something I wanted to try out.

I also considered integrating acme.sh, libdns, cert-manager's vendored libraries and lexicon, but they felt like weaker choices or too difficult to integrate for one reason or another, compared to lego.

One potential improvement I'm looking at making, if there's any interest in the plugin, is mixing DNS providers in a single certificate, which is something that might be possible in a way similar to --webroot-map.

13 Likes
2

Great idea! We do something similar in Certify The Web using many of Posh-ACME's DNS providers.

There is indeed a lot of duplicated effort invested across acme clients for DNS providers, often for very niche DNS providers which all use different proprietary APIs. I did once consider creating a single cloud based API for DNS updates but it required sharing your DNS API credentials with the service, which many users (understandably) just wouldn't be comfortable with.

One possible (and entirely debatable) disadvantage of implementing support for smaller DNS providers is that it removes some of the incentive for them (as an industry) to work towards a common API. In our case we hold off implementing providers (even if we have the code) until someone asks for it as there's no real advantage to shipping support for something nobody will use (and every included line of code is a possible bug or vulnerability later).

Regarding mixed challenges, in Certify The Web we allow multiple challenge configs (e.g. http, dns etc) and use a domain matching rule of the form example.domain.com;*.otherdomain.com;*.subdomain.something.com; to match challenge configs against different domains in a cert. That way one cert can span many different http and dns validation configs.

4 Likes
3

Is mixing different challenge types possible as well?

Like, in a certificate for example.com,*.example.com, using http-01 for example.com and dns-01 for *.example.com?

3 Likes
4

It is in both Posh-ACME and Certify the Web.

5 Likes
5

While I think it's a very good idea to use already implemented code (why invent the wheel multiple times?), I do have issues with the whole setuptools-golang requirement. It's not part of Gentoos repository and if I look at the code, it has some "troublesome" parts I do not like and makes me not wanting to build an ebuild for it:

E.g., this part of the script:

Dowloading go? (GOLANG is used further down the code.) Messing around in /tmp/?

Requiring Docker apparently?

Due to my very serious doubts about the entire setuptools-golang (and Go by itself), I personally won't be pursuing your plugin, unless the setuptools-golang thingy can work with all the )(#$()# parts of it stripped out.. :slight_smile:

4 Likes
6

The code you're worried about is a optional entrypoint to build manylinux wheels.

The plugin itself just needs the Go compiler to be (pre)installed, which will call whatever C compiler is avaialble for the cgo bits.

I think this probably needs bigger changes to Certbot than what can be done from a plugin.

4 Likes
7

So I should be able to just yank the entire build_manylinux_wheels() function? That would make it a little bit less worrysome :slight_smile:

3 Likes
8

Yes, and the reference to it from setup.cfg.

3 Likes
9

Cool, I could try that :slight_smile:

2 Likes
10

I meant from a CA standpoint, but yeah, it would be interesting but in no way important enough.

3 Likes
11

@_az How is the plugin licensed? :slight_smile:

3 Likes
12

MIT, it's in pyproject.toml at the moment, I'll add the license text to the repo later.

4 Likes
13

The one file I did not check :sob: Thanks :slight_smile:

3 Likes
14

@_az It seems my setuptools doesn't like the _version.py generated by setuptools_scm unless I add write_to_template = "__version__ = \"{version}\"" to [tool.setuptools_scm]

That said, I'm giving up on making a Gentoo ebuild for your plugin unfortunately. As the build process is sandboxed and setuptools-golang (or something else) apparently still seems to be trying to download Go (or something else) from cloud.google.com/go@v0.54.0:, this is way above my head.. Writing an ebuild for a Go application is terrible enough, combining Python and Go is a no-go for me :stuck_out_tongue:

Maybe someone else with Gentoo experience can build an ebuild for it, but I'm not the person to do it I'm afraid.

3 Likes
15

lego has quite a few Go library dependencies due to the sheer number of providers, this is the Google Cloud APIs. If you leave it for a while it will succeed eventually - it takes a few minutes if the Go local cache is empty. But I understand, thanks for looking into it!

The setuptools_scm thing is interesting, what version of setuptools, setuptools_scm and pip is in that environment?

3 Likes
16

dev-python/setuptools-65.3.0 and dev-python/setuptools_scm-6.4.2 where the latter is upgradable to 7.0.5, might be due to that perhaps, can try to see if it helps :slight_smile:

By the way, no pip is used. Pip is evil.

I think every Gentoo Go ebuild requires the Go dependencies in either a separate file so Portage can download them separately from their own source first before the compiling phase starts, use the vendor directory in the applications own source or, which seems to be "recommended" nowadays, have the package maintainer put all the dependency source code in a single tarball and have it hosted somewhere.. It's all quite a hassle to be honest. Writing an ebuild for even the simplest Go application gives me a headache :roll_eyes: Obviously has something to do with profound lack of understanding the Go ecosystem and, I think, Gentoos struggle to handle that.

3 Likes
17

Ah, that could be definitely be an option with go mod vendor.

3 Likes
18

By the way, updating setuptools_scm to 7.0.5 did indeed fix the __version__ error.. Now setuptools_scm generates the proper variables in _version.py by itself.

Uch, go mod vendor does not fix the fact setuptools-golang itself calls go get -d from inside the compiling phase.. Seems to be a reason why there isn't a Gentoo ebuild for that setuptools extension :stuck_out_tongue:

Maybe I can just strip that out of setuptools-golang too :grimacing:

3 Likes
19

I've managed to hack something together :slight_smile:

For our Gentoo users out there, the third-party-certbot-plugins overlay soon will also have the certbot-dns-multi (and its dependency setuptools-golang, slimmed down a little bit with the patches) package, once the CI passes. Below are the new ebuilds, for those interested. For users, simply follow the instructions in the overlays README (once I've pushed the dev branch to the main branch).

certbot-dns-multi:

The setuptools-golang dependency with patches:

@_az Why is Go 1.19 required by the way? Lego seems to be compiling with Go 1.17 or higher.

Edit: FFS, for some reason the /bridge/ directory isn't removed any longer, so it gets installed too... #($#)($() that's not supposed to happen.. Back to the drawing board tomorrow.

4 Likes
20

No reason really, the directive in go.mod was autogenerated but it should work without complaint on older versions of the compiler. Go provides support for two major releases so 1.17 is technically EOL, I guess.

3 Likes