Issue renewing cert created manually

Help
1

My domain is: sunset-pines.com

I ran this command: sudo certbot certonly --manual

It produced this output: Create a file containing just this data:

[joliver@leaf ~]$ cat /etc/letsencrypt/renewal/sunset-pines.com.conf

renew_before_expiry = 30 days

version = 2.10.0
archive_dir = /etc/letsencrypt/archive/sunset-pines.com
cert = /etc/letsencrypt/live/sunset-pines.com/cert.pem
privkey = /etc/letsencrypt/live/sunset-pines.com/privkey.pem
chain = /etc/letsencrypt/live/sunset-pines.com/chain.pem
fullchain = /etc/letsencrypt/live/sunset-pines.com/fullchain.pem

Options used in the renewal process

[renewalparams]
account = 0794093f589a1a80e29351799b68ff19
pref_challs = dns-01,
authenticator = manual
server = https://acme-v02.api.letsencrypt.org/directory
key_type = ecdsa

My web server is (include version): apache2 httpd-2.4.37-65

The operating system my web server runs on is (include version): RHEL 8.10

My hosting provider, if applicable, is: me (linode VM)

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

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

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

[joliver@leaf ~]$ sudo certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/ars4-229.com.conf

Certificate not yet due for renewal

Processing /etc/letsencrypt/renewal/forsandiego.com.conf

Certificate not yet due for renewal

Processing /etc/letsencrypt/renewal/hire.john-oliver.net.conf

Certificate not yet due for renewal

Processing /etc/letsencrypt/renewal/sdshooting.com.conf

Certificate not yet due for renewal

Processing /etc/letsencrypt/renewal/sdsitehosting.com.conf

Certificate not yet due for renewal

Processing /etc/letsencrypt/renewal/sf.arpnic.net.conf

Certificate not yet due for renewal

Processing /etc/letsencrypt/renewal/showlowretreat.com.conf

Certificate not yet due for renewal

Processing /etc/letsencrypt/renewal/sunset-pines.com.conf

Failed to renew certificate sunset-pines.com with 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.')

Processing /etc/letsencrypt/renewal/sunsetpineresorts.com.conf

Certificate not yet due for renewal

Processing /etc/letsencrypt/renewal/wrxr374.com.conf

Certificate not yet due for renewal

Processing /etc/letsencrypt/renewal/www.arpnic.net.conf

Certificate not yet due for renewal

Processing /etc/letsencrypt/renewal/www.kk7nlq.com.conf

Certificate not yet due for renewal

The following certificates are not due for renewal yet:
/etc/letsencrypt/live/ars4-229.com/fullchain.pem expires on 2024-10-17 (skipped)
/etc/letsencrypt/live/forsandiego.com/fullchain.pem expires on 2024-10-17 (skipped)
/etc/letsencrypt/live/hire.john-oliver.net/fullchain.pem expires on 2024-10-17 (skipped)
/etc/letsencrypt/live/sdshooting.com/fullchain.pem expires on 2024-10-17 (skipped)
/etc/letsencrypt/live/sdsitehosting.com/fullchain.pem expires on 2024-10-17 (skipped)
/etc/letsencrypt/live/sf.arpnic.net/fullchain.pem expires on 2024-10-17 (skipped)
/etc/letsencrypt/live/showlowretreat.com/fullchain.pem expires on 2024-10-17 (skipped)
/etc/letsencrypt/live/sunsetpineresorts.com/fullchain.pem expires on 2024-10-17 (skipped)
/etc/letsencrypt/live/wrxr374.com/fullchain.pem expires on 2024-10-17 (skipped)
/etc/letsencrypt/live/www.arpnic.net/fullchain.pem expires on 2024-10-17 (skipped)
/etc/letsencrypt/live/www.kk7nlq.com/fullchain.pem expires on 2024-10-17 (skipped)
All renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/sunset-pines.com/fullchain.pem (failure)

2

I think

sudo certbot certonly --manual --preferred-challenges dns -d www.sunset-pines.com

is probably how I generated the cert. The host I'm running on is actually running a proxy for sunset-pines.com because it's hosted on some platform that gives my wife an easy way to manage it. They want $$$ for TLS so I'm capturing traffic, securing with TSL, and then redirecting traffic to that host.

1 Like
3

Welcome @jnojr

If so then yes. The Certbot renew command only works for automatically renewable certs. Manual requested certs require manual interaction so are not automatic. Unless you are able to provide that interaction using the hook described.

What kind of help are you looking for? There is no way to auto-renew something requiring manual action.

Do you want help finding a different way to get that cert? Or just to avoid this message during renew? Or just asking to make sure you understand how this works?

PS:
You probably specified both domain names in your command though. That is, the registered name and the www subdomain. You can view all your certs with sudo certbot certificates.

5 Likes
4

@MikeMcQ I want to know how to renew this certificate.

5

Just repeat the steps you did originally.

Your current www subdomain uses a cert with both it and the apex name in it so you probably use something like below instead of your example.

Note there is no DNS A record for the apex name (just the www subdomain) so no one can reach it from the public internet on that name. You should probably fix that too.

See the cert your domain uses with a tool like this

3 Likes
6

Ugh, can't I do this without having to change the challenge every time?

7

No, a new challenge is needed for every new cert. Your other certs from certbot certificates that auto-renew handle this, well, automatically.

For this cert, you would have to change to use a method that supports automation. You have a lot of other active certs on this machine so you seem familiar with that. I'll recap anyway ...

To automate a DNS Challenge requires your DNS provider to have an API to add/remove the needed TXT records. Or, you can delegate that DNS to a different one that does (using CNAME or NS records). Or use a different DNS provider,

To automate an HTTP (or TLS-ALPN) challenge requires HTTP(s) access to the server and to run Certbot on that server so it can prepare the challenge tokens. It is technically possible to redirect those challenges to a different server but usually this just adds complexity.

3 Likes
8

It looks like the DNS service provider for sunset-pines.com is Linode. Certbot has a DNS plugin for Linode: Welcome to certbot-dns-linode’s documentation! — certbot-dns-linode 0 documentation. OP could try that.

I do see some weird stuff at the DNS level though:

The .com nameservers say the following when requesting the sunset-pines.com SOA RR:

;; AUTHORITY SECTION:
sunset-pines.com.	172800	IN	NS	ns.sdsitehosting.net.
sunset-pines.com.	172800	IN	NS	ns1.linode.com.
sunset-pines.com.	172800	IN	NS	ns2.linode.com.
sunset-pines.com.	172800	IN	NS	ns3.linode.com.
sunset-pines.com.	172800	IN	NS	ns4.linode.com.
sunset-pines.com.	172800	IN	NS	ns5.linode.com.

;; ADDITIONAL SECTION:
ns1.linode.com.		172800	IN	AAAA	2600:14c0:6::2
ns1.linode.com.		172800	IN	A	92.123.94.2
ns2.linode.com.		172800	IN	AAAA	2600:14c0:6::3
ns2.linode.com.		172800	IN	A	92.123.94.3
ns3.linode.com.		172800	IN	AAAA	2600:14c0:7::3
ns3.linode.com.		172800	IN	A	92.123.95.3
ns4.linode.com.		172800	IN	AAAA	2600:14c0:7::4
ns4.linode.com.		172800	IN	A	92.123.95.4
ns5.linode.com.		172800	IN	AAAA	2600:14c0:7::2
ns5.linode.com.		172800	IN	A	92.123.95.2

Notice the use of the .com TLD in the nameservers of Linode.

However, if we request ns.sdsitehosting.net or any of the Linode nameservers for that matter, the result is:

;; ANSWER SECTION:
sunset-pines.com.	3600	IN	NS	ns5.linode.net.
sunset-pines.com.	3600	IN	NS	ns2.linode.net.
sunset-pines.com.	3600	IN	NS	ns.sdsitehosting.net.
sunset-pines.com.	3600	IN	NS	ns3.linode.net.
sunset-pines.com.	3600	IN	NS	ns4.linode.net.
sunset-pines.com.	3600	IN	NS	ns1.linode.net.

Notice the .net TLD usage in the Linode nameservers: those hostnames do not exist!

Thus, OP should probably fix their NS RR for their domain at the Linode DNS zone level.

2 Likes
9

I handle my own DNS... Linode just slaves to my master. How can I extract the challenge before running certbot? I can use sed or Ansible to fix my challenge, but I'd need to know what it was before running certbot to automate that.

Thanks for all the help, I really appreciate it!

1 Like
10

Which server? Most DNS servers support RFC 2136 (which is also used by nsupdate),for which also a Certbot DNS plugin exists: Welcome to certbot-dns-rfc2136’s documentation! — certbot-dns-rfc2136 0 documentation.

You can't know before running Certbot, but you can know during running Certbot by using the --manual-auth-hook option as mentioned in the initial error message presented to you. You can find more information about those hooks for the manual plugin at User Guide — Certbot 2.11.0 documentation.

2 Likes
11

After running certbot and having it finish seemingly successfully, I still see the old cert and old expiration date. When I look at my files:

[joliver@leaf ~]$ sudo ls -l /etc/letsencrypt/live/www.sunset-pines.com
total 4
lrwxrwxrwx. 1 root root 44 Aug 11 09:45 cert.pem -> ../../archive/www.sunset-pines.com/cert1.pem
lrwxrwxrwx. 1 root root 45 Aug 11 09:45 chain.pem -> ../../archive/www.sunset-pines.com/chain1.pem
lrwxrwxrwx. 1 root root 49 Aug 11 09:45 fullchain.pem -> ../../archive/www.sunset-pines.com/fullchain1.pem
lrwxrwxrwx. 1 root root 47 Aug 11 09:45 privkey.pem -> ../../archive/www.sunset-pines.com/privkey1.pem
-rw-r--r--. 1 root root 692 Aug 11 09:45 README

It appears to have just moved the old cert and key and created symlinks to them, and didn't actually create new ones. What did I do wrong?

12

The symlinking is normal.

But previously your certificate was for sunset-pines.com and www.sunset-pines.com with the certificate name being "sunset-pines.com". But now you've requested a certificate for JUST www.sunset-pines.com with the certificate name "www.sunset-pines.com", thus having a second certificate laying around in Certbot.

You can check the certificates present in Certbot by running sudo certbot certificates.

Please appreciate this is exactly(well, not that exactly..) what Mike warned you about earlier:

2 Likes
13

Weird, that isn't in my .bash_history And I never had a TXT for _acme-challenge.sunset-pines.com. only one for _acme-challenge.www.sunset-pines.com. But I'll try that...

So, that's weird, as I do have A and AAAA records in my zone, and my zone is being loaded correctly. I can only imagine my DNS-fu is so old and rusty that there's some new requirement in bind that I'm not aware of? Any ideas?

14

It was probably with the order of the two domain names reversed from my example. But, you definitely got a cert with both names on May19 and your server is using it. You can see that on the SSL Checker link I earlier provided. A valid TXT record was provided at that time. Can't be any other way.

Osiris pointed out the problem with your DNS config. Chasing the DNS authoritive tree like Let's Encrypt never sees that A record. I don't see it from my own test server system either using a regular resolver.
https://unboundtest.com/m/A/sunset-pines.com/ZUAEGXAM

For a visual pic of what Osiris said see:
https://dnsviz.net/d/sunset-pines.com/dnssec/

4 Likes
15

Yet here DNS Spy report for sunset-pines.com shows both an A & AAAA records. Granted this may not be using authoritative NS.

IMG_1159
IMG_11591290×2796 229 KB

Edit
And this is what ICANN Lookup shows.

IMG_1160
IMG_11601290×2796 243 KB

Edit2

Shows

IMG_1161
IMG_11611290×2796 248 KB

2 Likes
16

Thanks @Bruce5051 Your DNSSpy actually seems to agree with what Osiris and Mike are seeing... A and AAAA records for "www.sunset-pines.com" but not for "sunset-pines.com"

All of these are very helpful! I didn't realize there were so many DNS tools out there. I'm fixing a number of little issues, especially with older zones I haven't touched in a while.

I'm wondering if I need to explicitly use '@' for apex records now? I'm going to try that with one domain and see if that fixes the error.

2 Likes
17

[joliver@leaf ~]$ sudo certbot certonly --manual --preferred-challenges dns -d www.sunset-pines.com -d sunset-pines.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate for www.sunset-pines.com and sunset-pines.com

Please deploy a DNS TXT record under the name:

_acme-challenge.sunset-pines.com.

with the following value:

CdXN6lYfxNDBVDk7GagI8eDnrXzgQwOB9u62ngb-F5E

Before continuing, verify the TXT record has been deployed. Depending on the DNS
provider, this may take some time, from a few seconds to multiple minutes. You can
check if it has finished deploying with aid of online tools, such as the Google
Admin Toolbox: Dig (DNS lookup).
Look for one or more bolded line(s) below the line ';ANSWER'. It should show the
value(s) you've just added.

Press Enter to Continue

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/sunset-pines.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/sunset-pines.com/privkey.pem
This certificate expires on 2024-11-09.
These files will be updated when the certificate renews.

NEXT STEPS:

  • This certificate will not be renewed automatically. Autorenewal of --manual certificates requires the use of an authentication hook script (--manual-auth-hook) but one was not provided. To renew this certificate, repeat this same certbot command before the certificate's expiry date.

If you like Certbot, please consider supporting our work by:

But:

[joliver@leaf ~]$ sudo ls -l /etc/letsencrypt/live/sunset-pines.com
total 4
lrwxrwxrwx. 1 root root 40 Aug 11 10:54 cert.pem -> ../../archive/sunset-pines.com/cert3.pem
lrwxrwxrwx. 1 root root 41 Aug 11 10:54 chain.pem -> ../../archive/sunset-pines.com/chain3.pem
lrwxrwxrwx. 1 root root 45 Aug 11 10:54 fullchain.pem -> ../../archive/sunset-pines.com/fullchain3.pem
lrwxrwxrwx. 1 root root 43 Aug 11 10:54 privkey.pem -> ../../archive/sunset-pines.com/privkey3.pem
-rw-r--r--. 1 root root 692 May 19 12:16 README
[joliver@leaf ~]$ sudo ls -l /etc/letsencrypt/live/www.sunset-pines.com
total 4
lrwxrwxrwx. 1 root root 44 Aug 11 09:45 cert.pem -> ../../archive/www.sunset-pines.com/cert1.pem
lrwxrwxrwx. 1 root root 45 Aug 11 09:45 chain.pem -> ../../archive/www.sunset-pines.com/chain1.pem
lrwxrwxrwx. 1 root root 49 Aug 11 09:45 fullchain.pem -> ../../archive/www.sunset-pines.com/fullchain1.pem
lrwxrwxrwx. 1 root root 47 Aug 11 09:45 privkey.pem -> ../../archive/www.sunset-pines.com/privkey1.pem
-rw-r--r--. 1 root root 692 Aug 11 09:45 README

I'm still just getting symlinks to archive instead of new certs.

18

Note the Name Servers
NSx.linode.net they do not seem to exist
while NSx.linode.com they do exist and are what ICANN reports as the Authoritative NS.

I suggest stop using and advertising NSx.linode.net NS.

3 Likes
19

The cert files are kept in ../archive/ and I think a total of 6 most recent are kept there (maybe just 5).

The ../live/ symlink points to the most recent set of files in ../archive/

This allows continuous use of the ../live/ names for the most recent cert

3 Likes
20

Your sunset-pines.com cert which was just updated, is symlinking to 'version 3' of the certs in the /archive/ directory, which is probably just fine.

Please don't use the internal structure of Certbot in /etc/letsencrypt/ unless you know exactly what you're doing cq. what you're looking at. It's probably way better to just check the expiration date mentioned in sudo certbot certificates.

2 Likes