Certificate renewal appeared to succeed, but didn't

Help
1

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. https://crt.sh/?q=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: solartest.org.uk

I ran this command:

sudo certbot certonly --manual --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory -d "*.solartest.org.uk" -d solartest.org.uk

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/solartest.org.uk.conf)

What would you like to do?

1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)

Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate

IMPORTANT NOTES:

Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/solartest.org.uk/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/solartest.org.uk/privkey.pem
Your cert will expire on 2021-03-01. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew all of your certificates, run
"certbot renew"

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

Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
Donating to EFF:                    https://eff.org/donate-le

My web server is (include version): nginx/1.12.2

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

centos-release-7-7.1908.0.el7.centos.x86_64

My hosting provider, if applicable, is: Linode

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): certbot 0.37.2

The problem I have is that I now appear to have a certificate divided into two parts: one called *.solartest.org.uk which expired 01/12/2020, 12:47:56 (Greenwich Mean Time); and one called Let's Encrypt Authority X3, which expires 17/03/2021, 16:40:46 (Greenwich Mean Time).

When I attempt to access this server, with, e.g. demos.solartest.org.uk I get site’s certificate is expired.

I always use the command above to renew the certificate (adding the _acme_challenge token to the DNS TXT Record and waiting 5 minutes TTL).

It appeared to work. But it didn't !?

2

Hi @ctleake

doesn't restart / install the certificate. certonly says: It's your job. Job done?

3

Hello Juergen,

Thanks for your reply.

To tell you the truth this is pretty murky waters to me. I grabbed the command off the web ages ago and have repeatedly used it successfully since then.

Basically, I type in the command at the server's command prompt; it generates a token and pauses; meanwhile I copy that generated token into my DNS TXT _acme_challenge field, wait 5 minutes, and then hit enter on the paused command.

That has worked without fail up till now.

Of course I've now exceeded the 5 failed attempts and will have to wait a week before I can do anything...

1 Like
4

That's not possible, please read my answer.

You ignore your own output. There is no need to wait.

5

Hello Juergon,

Thanks for your patience.

Okay, reading the output it says: To non-interactively renew all of your certificates, run
"certbot renew".

So I did that, and the output was:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/solartest.org.uk.conf

Cert not yet due for renewal

Processing /etc/letsencrypt/renewal/test.solartest.org.uk.conf

Cert not yet due for renewal

The following certs are not due for renewal yet:
/etc/letsencrypt/live/solartest.org.uk/fullchain.pem expires on 2021-03-01 (skipped)
/etc/letsencrypt/live/test.solartest.org.uk/fullchain.pem expires on 2021-03-01 (skipped)
No renewals were attempted.

No matter how much the system insistes my certificates don't need renewing, when I attempt to go to my web site (try demos.solartest.org.uk) I get: Warning: Potential Security Risk Ahead.

I must confess I didn't quite understand your original message.

You appear to take issue with the certonly parameter. Are you suggesting I replace it with 'install' or 'replace'?

Kind regards,

Chris

1 Like
6

Hello Juergen,

Perhaps the crucial issue here is that I have a wildcarded domain *.solartest.org.uk. This doesn't appear to be renewing:

image
image1855×1056 95.7 KB

This does rather complicate matters. Certainly the command I'm using took extensive research:

sudo certbot certonly --manual --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory -d "*.solartest.org.uk" -d solartest.org.uk

I don't pretend to fully understand what that command is trying to achieve.

Kind regards,

Chris

1 Like
7

Well, that's a problem. You should never run any command you don't understand.

@JuergenAuer has already told you what's going on. The certificate issuance is working fine! You don't need to keep getting new certificates! That will only impose a bigger load on the Let's Encrypt systems! The certificates have been stored in your server already! Only because you're using certonly, your webserver doesn't know about these new certificates: as long as you don't "tell" it to use a new one, it'll just keep using the old one!

How do you tell a webserver to use the new one? Well, if you've set up your webserver properly (i.e., pointing to the correct symbolic link in the /live/ directory, you juet have to reload the webserver.

1 Like
8

Hello Juergen,

Oh, thank you, that did it.

As to never running a command I don't understand, I hardly think I'd run any infrastructure command at all; and I'm not sure I'm entirely alone in that. I'm a serf of the Lords of Google.

I was a grunt programmer in the IBM COBOL Mainframe days. I've transferred my skills across to PHP/MySQL/Javascript. I take great pains to be clear on what applications I write do and exactly how they do it.

But nowadays if you ply your trade coding in any part of the web you seem to be expected to know exactly how every part of the web works. I'm the sole technical support for my little company. If I held up my hands and said I don't know how security works, give me a few months, halting any development, whilst I try to unravel it; then another 6 months on some other part of web infrastructure; then another... I certainly wouldn't be bothering good people like you any more - I wouldn't be employed.

However, it's comforting to know that there are colleagues out there like you for whom every part of the web is transparent to their understanding.

Again. Thank you. I was stuck, and now I'm free.

Envious regards,

Chris

1 Like
9

That was @Osiris

But I told you in the first answer you have to restart your webserver.

You have to use the documentation - User Guide — Certbot 2.7.0.dev0 documentation

If you use PHP etc., you have to know all these things. If not, you have to learn it.

That's unrelevant. Using commands blindly is always wrong. Looks like you sit in a car and use everything randomly -> you will create a lot of accidents.

2 Likes
10

I wouldn't say everything, but yes, some basics would be nice :wink: I obviously didn't understand everything in the beginnen, still don't. But I did read the documentation back then.

Also, there aren't that many commands on your certbot command line? Knowing what certonly does and more importantly, what it doesn't do I would call essential.

Also, almost every service like Apache needs a reload to find out if anything changed in the configuration files. PHP settings for example in an Apache configuration file aren't different from a certificate in that regard (if you used certonly that is..)

2 Likes
11

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