Basice cert renewal question

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: sswormwood.com

I ran this command: n/a

It produced this output: n/a

My web server is (include version): n/a

The operating system my web server runs on is (include version): Gentoo, current

My hosting provider, if applicable, is: n/a

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 1.27.0

Question: I'm still new at this, and I've just received the first email with the subject, "Let's Encrypt certificate expiration notice for domain 'sswormwood.com'". I could be wrong -- this is my first time through this process -- but I thought that I had automated the process to renew the notice on this cert. So, two questions:

First, could that be right? How would I check? Some call(s) to the certbot process?

If I'm wrong, and my cert is actually not renewing automatically, where's the process to handle renewal? That hasn't been explained in the email I received. It would be nice if it were.

Thanks,
Michael

With Gentoo, the Certbot ebuild does not install a cronjob for you automatically, so you'd have to add that manually. Did you do that? If so, what's the cronjobs content?

The expiry email is very general and can't explain everything for every ACME client and situation out there. Usually, guides will tell you to add a cronjob, such as the official Certbot guide at Certbot Instructions | Certbot.

8 Likes

Osiris has guided well on auto renew.

In case you are still wondering about the expiry it is because you have issued certs with different sets of "exact names" (described in the links in the email you got).

Your cert history shows you issued certs with just sswormwood domain but more recently created a cert with that and its www subdomain.

8 Likes

@MikeMcQ Note that at the time of writing my post, the cert from today was not issued yet :wink: So yes, it's true there were different certs issued earlier, the expiry notice was warranted due to the lack of renewals.

9 Likes

Thanks both. My question is answered but there's a larger issue, please read on:

Ah! I had neglected that (partly because I was uncertain about the correct way in this case; more on that below); I've reviewed the crontab line, found that it is indeed accurate; also did the update process once manually, and that was successful. So, that's fixed. Thank you!

About the other part:

...and:

The "wildcard" side of the Gentoo help page is inaccurate. When I was new to this process, I was trying to figure out the right way, and that's why the first, "non-wildcard" instance is in place. That could be deleted.

More important: it would be good for others if the "wildcard" side of the Gentoo help page got fixed. Currently, it appears to have been a copy-and-paste from one of the BSD-related instances. The correct version could be something like, "Do the same thing you would for the host-only version, but instead of requesting '[domain]', instead request '*.[domain]'".

I'm sure the LetsEncrypt folk would write it better, but you get the idea. The difference between a single host and a domain really is as simple as that, but because of the current state of the doc page, the process was harder on my end that it should have been.

When this first happened in my case, I raised the issue on this channel and I believe that it was passed along, but that was several weeks ago, the problem would be easy to fix, but it's still there.

Thanks,
Michael

1 Like

Which help page are you referring to exactly? From the Certbot site? The "Wildcard" tab on the Gentoo Certbot instruction page is currently incorrect with regard to the certbot-dns prefix being missing from a few commands. But to actually get your certificate, the page refers to the Certbot user guide which is not OS specific. So I'm not sure which Gentoo help page you mean.

7 Likes

The one Osiris referenced at the beginning of this thread:

https://certbot.eff.org/instructions?ws=other&os=gentoo

At that page, click the "wildcard" option button; sorry I couldn't find any way to link to it directly.

Reading that page:

I don't understand why there's a reference to Docker there; as you said, there are lots of different ways to be doing web traffic. I don't use Docker for example, and the reference there was part of what confused me. Seeing it, I thought there must be some reason to use it in this context. I found out the hard way, no, I don't need it.

Further down: under "3. Install correct DNS plugin", the two calls to the "emerge" command are incorrect. They look like a partial copy from a BSD system onto a Gentoo package manager (emerge).

Again as you pointed out, it's possible that the precise correct command would vary. That said, I think it's fair to suggest two packages:

  • app-crypt/certbot
  • app-crypt/certbot-dns-cloudflare

...but I'm no expert. All I can say for sure is that the commands shown on that page are sure to fail.

1 Like

I don't understand the Docker requirement/part either. Isn't necessary at all.

Those two emerge commands are broken in the template somehow and is a known issue.

The certbot package is already referenced in step 2.

The idea behind step 3 is that everyone can find out the appropriate package by append the DNS provider (e.g. cloudflare) to the app-crypt/certbot-dns- prefix. However, this app-crypt/certbot-dns- prefix somehow is gone from the template, so the command shown on the instructions don't make sense.

The Certbot team is already informed about this.

It's rather unfortunate, but the Certbot team has decided to internalise the once public Github repository for their site. So we can't suggest improvements to the instructions any longer. See Certbot Nginx Gentoo wildcard has a bug for more info. It also contains a post where I explain the existance of a Gentoo overlay (from my hand) which contains the DNS plugins. Currently, Gentoo only has the certbot-dns-nsone plugin in the official repository.

7 Likes

What template are you referring to here?

The commands listed here are not 'emerge' text at all, they're a partial copy-and-paste from a related command under one of the BSD's.

Ha! Yeah, notice who's at the top of that thread. And, thanks again for the overlay.

Well, bummer that the maintainers of the site can't address glaring issues with it.

1 Like

The underlying code of the Certbot instruction generator. Those pages aren't static HTML. If the Github repository was still public, I could have shown you, but unfortunately the sites code isn't public any longer.

Edit:
Although you can still find the now-probably-outdated code before everything was removed at GitHub - certbot/website at 003988c4b31e57db2d12e72ecb78f0611ae835ac

I'm not sure I understand. If I go to Certbot Instructions | Certbot and click on the wildcard tab, I see the following:

  1. Install correct DNS pluginRun the following command, replacing with the name of your DNS provider.

sudo emerge -av -<PLUGIN>

For example, if your DNS provider is Cloudflare, you'd run the following command:

sudo emerge -av -cloudflare

I agree those commands are broken due to the missing certbot-dns before the -<PLUGIN> and -cloudflare part, but I disagree those are BSD commands?

:smiley: And still it's not fixed :sob:

The Certbot team has very little time to spare unfortunately. Personally I think it's a shame and all kind of choices have made me to not invest any more time into Certbot myself. At least, not with PRs and stuff like that. I maintain my own Certbot enhancements for private use (but the code is all available in my fork), but won't open PRs as it just takes AGES for the PRs to be reviewed.. And after months of lingering around, chances are your PR is full with all kinds of conflicts. So you have to maintain a PR if you want to do it properly.. And maintaining these PRs are a hassle.

9 Likes

-<PLUGIN> is not present in 'emerge'. -<anything> is always more emerge commands. The name of the plugin category will never be in that format. Instead, it will be in the form of a package.

It does show up that way in the context of one of the BSD flavors. I'm sorry I don't recall whether it's FreeBSD or OpenBSD; but, "-" is the way one of them present a provider's name from the command used there.

OK, found it. It's from OpenBSD's "wildcard" section, which further suggests that there's been a partial copy-and-paste from there onto the Linux side.

It has, near the top, the same reference to Docker, with no explanation why that reference would be made.

Further down, we have

pkg_add -

Tweak: after the "dash", above, we should find the string 'carat-PLUGIN-closecarat', but that's being cut out by the formatting here.

[...]

pkg_add -cloudflare

I don't find that anywhere in either of the *BSD's I find here. All I see is that, in this section, we have "pkg_add", while in a copy over to Linux, we have "emerge".

I think you don't understand my previous post(s): the site is broken and the currently visible commands are not what the instructions should represent. The actual commands shown on the site, when fixed, should say:

  1. Install correct DNS pluginRun the following command, replacing with the name of your DNS provider.

sudo emerge -av app-crypt/certbot-dns-<PLUGIN>

For example, if your DNS provider is Cloudflare, you'd run the following command:

sudo emerge -av app-crypt/certbot-dns-cloudflare

Where the user would not actually use the literal <PLUGIN>, but would substitute <PLUGIN> for the actual name of the DNS provider, as shown in the example. I'm not sure what the benefit of using anything above PLUGIN would be to be honest.

7 Likes

We are talking past each other. If I can be of further assistance, please let me know.

The instructions generator is relatively complicated. You can see the code for individualisation for Gentoo here: https://github.com/certbot/website/blob/003988c4b31e57db2d12e72ecb78f0611ae835ac/_scripts/instruction-widget/install.js#L158-L170 (note: possibly older code)

It's missing the context.dns_package_prefix variable.

Quite possible.

The issue is known with the Certbot team. The team is short staffed. The site has been "internalised" and is no longer publicly available. IMO nothing we can do, the Certbot team is in the lead now.

7 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.