Certbot Nginx Gentoo wildcard has a bug

As described: under "Instructions", "My HTTP website is running (Nginx) on (Gentoo), with the "wildcard" section selected, there's a mistake.

First a minor gripe: the "Install Certbot" section is correct but I'd adjust it, from:

$ sudo emerge -av app-crypt/certbot certbot-nginx

...to:

$ sudo emerge -av app-crypt/certbot app-crypt/certbot-nginx

The first version will run, but in the docs it's better to be explicit.

More serious though: in section 3., "Install correct DNS plugin", we find:

$ sudo emerge -av -<PLUGIN>

The "example" section:

$ sudo emerge -av -cloudflare

...is definitely wrong. If someone is trying to do this by following along, they get the same as:

$ sudo emerge -a -v -c -l -o -u -d -f -l -a -r -e

...which is a call to emerge's depclean function. I'll leave specifics as an exercise to the reader but it could potentially remove unexpected parts of the system.

Anyhow it's an obvious booboo; looking under the "default" section that looks right, but I don't know enough to port that over to the "wildcard" side.

Looking at other OS's for clues, the closest I've found is OpenBSD, where we find:

$ pkg_add -<PLUGIN>
$ pkg_add -cloudflare

...so that looks like a partial copy-and-paste to the Gentoo side.

1 Like

Thank you for reporting this. I've filed it at Errors in Gentoo documentation · Issue #766 · certbot/website · GitHub.

4 Likes

Note that Gentoo currently does not have any but the nsone DNS plugins included in their official repository.

You can use my Gentoo DNS plugins overlay to install the other official DNS plugins:

See the instructions in the README. My advice is to use eselect to add the overlay.

If you have any trouble with the above, please let me know!

4 Likes

Thanks for this. Now I fumble:

I do have it installed on my build server. What I want is to just make my web host, which happens to run on Gentoo, handle some arbitrary set of host names. I am not up to date on the particulars of this circumstance; I know the gist; but I read, at:

https://eff-certbot.readthedocs.io/en/stable/install.html#running-with-docker

...oh no, You'd better use Certbot or else you'll have to make decisions about this or that...

I'd happily watch Certbot do the dance if it didn't fail on this particular part of the project. I'm not up to date on this.

So I'm sort of stuck. Where I'm at now (right?) is to wait for the bug to be fixed under the "wildcard" channel of the Gentoo page. It's one thing to have the Cloudflare set in place, and another to know how to dance with it.

As I read the page, "To get a wildcard certificate on this system, you'll need to run Certbot in Docker. You can do so by following these steps from our documentation." I'd love to!

But I go on. Tips are welcome. If the tip is, "wait for that bug to be rewritten," I'm happy for that, but I'd welcome clues in the meantime.

Thanks.

1 Like

I'm not sure I follow.

All pointing to your server, right?

I'm not sure where you read that exactly. Also, I wouldn't recommend Docker. As far as I know, it's also not especially recommended in the Certbot documentation, only mentioned as an option.

It's not that hard to figure out how to install a package using emerge, right? You don't need Certbot documentation for that I hope. :slight_smile:

But to start from the beginning: do you actually require a wildcard certificate to begin with?

3 Likes

Yeah. I have exactly one public server to "work" with.

Under "Nginx on Gentoo", "wildcard", we've already noted the bugs, but above that section I see:

Follow Docker instructions

To get a wildcard certificate on this system, you'll need to run Certbot in Docker. You can do so by following these steps from our documentation.

...so, I thought, maybe that's the earlier way, it might be worth a shot...

I'm happy to read that. Away it shall now go.

Yeah; I took it to mean, "this is the way it used to work, the new way is better, but that hasn't been ported yet in every environment." Bad guess on my part.

Installation isn't the issue. Configuration is. nginx is running fine, holds multiple environments, but needs to be told to associate specific names (environments) according to a specific key, the hosting of which is...

HA! Now we come to my story! Laugh, I beg of you.

I'm doing a little project, with a small circle of people, in different parts of the country. We have a wiki we'd like to share, TiddlyWiki. I was surprised to learn that talking to this wiki -- which is, like, a wiki -- was unusual over a network. Make that network The Network? Egad! But I'd gone this far, so why stop now?

My "little project" is actually a small but growing set of projects. More than one instance of TiddlyWiki.

Fine, I thought:

https://host.name/foo/wiki/
https://host.name/bar/wiki/
https://host.name/[...]/wiki/

But, it turns out, the chosen wiki doesn't like to work that way. It really, really wants to expect:

https://foo.host.name/
https://bar.host.name/
https://[...].host.name/

Multiple instances of a single proxy web server is fine. The trouble starts to crop up when the wiki behaves like a shared instance within a single environment.

There's no way -- I have learned -- to tell TiddlyWiki to specify, say,

"/instance-A/path-X/"
"/instance-B/path-X/"

There are multiple places within the wiki where it refers explicitly to its home base as "/", and will address the OS by that hardwired name.

In my past experience it was a windfall to be able to host multiple environments withing a single "*" cert. So, doing that on a project like this was reflexive. Single system, multiple names, why bother to have more than one key?

I guess I could give each wiki instance its own unique key. Hey, they're free, w00h00! But it's nice to have an outside process (Let's Encrypt, for example) needing as few visits as possible.

New instance of the project: tell nginx to add a fresh file path (and, okay, a new A record, fine, fine, you win, TiddlyWiki);

Or:

New instance of the project: fresh nginx file path, new A record, and, conjure a fresh cert to go with the A record, deliver that, accept the response... this for a project that might not last a week and, for sure, will never involve more than half a dozen people.

1 Like

Ah, I didn't see that. I guess maybe the Certbot team says so due to the fact most DNS plugins aren't in the official Portage repository?

Well, I guess that's kinda personal. But no docker or the likes for me :slight_smile:

Sounds complicated. Could be Certbot doesn't actually work, might work anyway, YMMV.

That does sound a good reason for a wildcard cert indeed.

Have you already tried my overlay to install the Cloudflare DNS plugin?

1 Like

Yep, thanks. Plugin installation: fine. Cert fetch and configuration: unclear.

Duffer that I am, I'm using this as my guide:

Wildcard certificate from Let’s Encrypt with CloudFlare DNS

That guide only covers getting a cert, not installing it. See the certonly part of the command.

If you didn't know what that subcommand does, you should look it up. You can find the Certbot documentation here: User Guide — Certbot 1.26.0 documentation

2 Likes

Right. Getting the cert is where I'm hung up. It's the part that's wrong in the link I sent.

It seems -- and again, educate me here -- that Snap is not available on Gentoo. Am I wrong? I'm guessing that may be why that happened in the docs?

I had not gotten to the nginx cert installation stage, so thanks for the link you sent.

Oops. Minor correction here:

app-crypt/certbot-nginx is a package I hadn't installed yet, it is in place now, so thanks for that.

I had installed that; referenced in my "piddly gripe" section where I posted to begin with.

Anyhow...

Have your thought of using any other ACME client?
[like: acme.sh]

3 Likes

I had not! Thanks for cluing me in to that.

I shall read now...

1 Like

If you already have your certificate, using another ACME client will not solve any problem.

[acme.sh is fine but it's not the best introduction to ACME. It's powerful but not very user-friendly.]

2 Likes

I think I may have crisscrossed topics - LOL
[sucks to get old - avoid it at all costs]

4 Likes

You're not wrong. Snap requires systemd and Gentoo does not, by default, run on systemd but OpenRC. So no snap.

How do you mean, "wrong in the link"? Are you now refering to the Certbot page earlier or that how-to you've linked just now above?

3 Likes

After a quick Gentoo-browse, the one I'm trying is acme-tiny. Still reading on that.

Getting the cert is where I'm "stuck". Which is to say, I got this far, from the rundown I linked:

If you follow the instructions on the EFF site, make sure you select the “wildcard” tab, to get the installation instructions for the DNS authenticator plugin as well.

At the EFF site, it seems to imply that the server I use (so far so good...) and the OS it runs on on (which is not covered there within the wildcard section) will need some specific settings. Once I have an instance of the cert, I'll be better equipped to know what issues there will be, if any. But I don't want to start with a "maybe" cert, and risk making some non-obvious mistake, which can lead to unexpected problems later on.

I tried going a different route: click a different flavor of Linux and work from there. But, I find that snapd is currently in the "Masked" setting on Gentoo. Why, I don't know, but again I didn't want to ignore the issue when others who have more experience than I do might just fix the doc.

A post was split to a new topic: Nothing to see here

I already told you above..

Also, if you've installed certbot-dns-cloudflare already, as you've said earlier, what is the exact problem? Please post outputs of your certbot attempts.

2 Likes

Thanks for explaining that. My hosts do run on OpenRC.

The former; the link I sent to begin with, in the certbot.eff.org page.

But you've already stated that you've installed the certbot-dns-cloudflare plugin "fine" earlier:

So you can continue with getting a certificate. What's not working about that?

I've also linked to the Certbot documentation "User Guide" (which is not on the page you've found the bug in!) above. This also has information about getting a cert with the Cloudflare DNS plugin.

But if you only tell us "it doesn't work" without providing commands and output, well, then there is nothing we can do... But if you DO provide is with attempted commands and outputs, we MIGHT be able to help you.

Please also notice that you should experiment and test on the staging environment.

Edit: I also see now that the certbot.eff.org instructions actually link to the User Guide in the stap just after the plugin installation step.. So I reallllly don't understand what the actual issue here is now. Could you clarify please?

3 Likes