Never had a successful 'renew'. Ever


#1

Every time I get a notice to renew I try to ‘cerbot renew’ to no avail. There’s always an error of some sort and I have to resolve everything. When I do, the next time I renew, I have a new problem or the same one. So I’m going to get straight to the point this time:

Here’s the command I use to get my certs:

sudo ./certbot/certbot-auto -d hellhawks.net -d *.hellhawks.net --manual --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory certonly

Here’s the most recent error:

Attempting to renew cert (hellhawks.net) from /etc/letsencrypt/renewal/hellhawks.net.conf produced an unexpected error: The manual plugin is not working; there may be problems with your existing configuration.
The error was: PluginError(‘An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively.’,). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/hellhawks.net/fullchain.pem (failure)

What do I need to do in order to just have ONE successful renewal? Just one? I’ll be really [censored] happy if after all these years I could just RENEW instead of installing new certs. Sorry for my frustration, but I’ve been using LetsEncrypt since it came out. You can imagine having issues with every single renewal is really annoying.


#2

Hi,

The renewal failed because you are using manual authenticator, and you’ll need to look for a script that automatically update your DNS records in order for the challenges to be passed without issue.

For now, since you are using manual (and probably update the records manually), certbot don’t know how to automatically update the records and complete the challenge. Hence this is why the above error message is shown.

Thank you


#3

Also, since you are using NameCheap DNS, you could take advantage of the DNS API (however NameCheap has certain requirement you’ll to meet in order for the API enable request being proceed… Check with NameCheap please)

For the DNS API, since certbot does not support namecheap’s DNS API, you could use acme.sh (they support nc DNS API), please check with acme.sh support documentation.

Thank you


#4

Thank you very much for the quick reply.

I guess that means I have to continue to install new certs and put the challenges in myself. Tedious and not impressive… I’m still grateful for the free certs though. Sad that my domain provider isn’t supported.


#5

I’m not really interested in a 3rd party workaround for this. If certbot can’t do it, then the issue stands as unresolved. I’ll continue to install new certs and come back every time I need to renew and see if a proper solution exists yet.


#6

Then frankly, you’re kind of missing out. There are a lot of great clients out there and being stubborn about only using certbot doesn’t really do anything except make your own life more frustrating. It might also interest you that some of the DNS plugins that work with certbot are actually “3rd party workarounds” not written by the certbot team.

And like @stevenzhu said, even if there were a Namecheap plugin for certbot, you couldn’t use it anyway if don’t qualify to use their API. So you’d probably be better off moving your DNS to another provider. If you weren’t aware, that doesn’t mean you need to move your domain registration away from Namecheap. DNS and registration are two separate things.


#7

P.S. Then, certbot is also considered as third party client because certbot is develop & maintained by EFF (and Let’s Encrypt is maintained by ISRG)

Thank you


#8

Preferring an officially supported solution is a means of sticking with something that won’t someday become defunct because the developer discontinued their work. I’m looking for a working solution that I can rely on for the long term. The officially supported tools are, in my mind, the tools that will maintain the best support as long as LetsEncrypt stays in service. I have a working solution to keep my certs current, and I’m fine with continuing to use that method as long as there’s no officially supported solution that handles this specific issue.


#9

With that said I will keep an open mind about moving my DNS services and properly configuring the manual authentication hook to keep my wildcard certs current the proper way.


#10

Another option that you would consider “third party”, but is highly effective and would allow you to retain use of NameCheap DNS would be something like the following options. Note that they’re not in any particular order, so an option being first doesn’t necessarily mean I think it’s best.

  • Use acme-dns. This is a small, stripped-down DNS server that runs on your system to respond to challenges and has a RESTful API so that it can be updated automatically by ACME clients, such as Certbot. The link here is that you’d add a CNAME record to your NameCheap DNS for _acme-challenge, pointing it to your server’s public IP. This enables acme-dns to respond to challenges.
    There is the caveat here that it takes some extra setup on your server.

  • Use the same CNAME trick mentioned above, but instead point it to the location of a TXT record on another, free DNS provider who supports API (e.g. CloudFlare) and update this record instead. You can still keep the bulk of your DNS on NameCheap, but only use another provider for the ACME TXT records.


#11

Thanks! This is actually really good info. I’ll look into this CNAME trick more. It does sound like a fairly reliable solution.


#12

In addition to @jared.m’s great suggestions I would also encourage you to consider whether or not you need a wildcard certificate. It seems like much of the difficulty here is related to having to perform DNS-01 authentication manually. You may find HTTP-01 will be considerably easier to automate at the cost of not being able to issue a wildcard subject identifier. For most individuals with a small, static number of domains and servers it is often better to issue many small certificates or one certificate with up to 100 fixed names instead of using a wildcard.


#13

I used to use the fixed names. I switched to wildcard because at the time I was dealing with a variable list of subdomains. But now I think I’m back down to a simple list again. Maybe I should consider the switch back. if anything changes I can generate new certs easily enough, right?

Thanks for the suggestion!


#14

Yup! The only thing to be aware of are the rate limits: https://letsencrypt.org/docs/rate-limits/ Particularly the certificates per registered domain rate limit for this case.


#15

Thanks for the link. Yea I don’t think I can get anywhere near those limits in those time frames. Should be good. I think aside from the CNAME solution this might be the best idea in terms of getting to a stable state of renewal-ability.


#16

This is “by design” when using the manual plugin.

The renew function is supposed to be run from automated timers like systemd timers or cronjobs. With the manual plugin without the “hooks” the error message is refering to, you’ll need to input the challenges manually. Hence the name :wink: But! You can’t manually input challenges when using cronjobs! So that combination is a “no go”. And thus certbot will refuse to function when renew is used in combination with the manual plugin without any authentication hooks. See for more information: https://certbot.eff.org/docs/using.html#hooks


#17

I think this is a reminder about the comparative importance of

In my experience on the forum, a lot of people don’t understand the significance of the existing error message or what it’s encouraging them to do differently.


#18

I still think certbot should get an option to force the use of renew with the manual plugin without hooks. Yes, I know, Let’s Encrypt and certbot is all about automation. No, not by default. But as an option for people who perhaps can’t automate. But still would like to use certbot, the “hard” way, in stead of opting for sites.

Although, when I say sites… I remember Let’s Encrypt even removed those clients from the 3rd party client list :cry: Because those couldn’t be automated… I think that’s a little bit far fetched. Having a goal is a good thing. But discriminating against people who perhaps can’t get things automated, no, I don’t think that’s the way to go. I think it’s very unfair.


#19

Issue: --manual should display a warning about the inability to use certbot renew

I’m certainly guilty of overlooking the manual thing and I agree that things could be clarified better. I originally found those options when I looked up how to use the wildcard certs, but I vaguely skimmed most of the information in my mission to get the certs installed and get back to work. But at least my rant helps bring awareness to this issue. I agree, it should be more informative and maybe ‘renew’ (or a new/similar option?) should give the user a chance to manually insert the txt records like it does when new certs are requested.


#20

The supported way to do that is with certbot certonly --force-renew. I think we have some significant architectural challenges allowing plugins called from certbot renew to be interactive. But if we can improve the error message, we can explain to users who used --manual what they’re expected to do for renewal (which right now most of them understandably have trouble following).