DNS-01 creates expired certificate

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:
timo.cloud
I ran this command:
certbot certonly --manual -d timo.cloud -d *.timo.cloud --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for timo.cloud
dns-01 challenge for timo.cloud

Please deploy a DNS TXT record under the name
_acme-challenge.timo.cloud with the following value:

IYQ2GXioCiieXYK4Myb9eupb95qS-uDQp6Aln_oKngA

Before continuing, verify the record is deployed.

Press Enter to Continue

Please deploy a DNS TXT record under the name
_acme-challenge.timo.cloud with the following value:

AJnFDluKrKOf3hg_Vdbv7uxZgO8aWwEnwg7fSkcs28Q

Before continuing, verify the record is deployed.

Press Enter to Continue
Waiting for verification…
Cleaning up challenges

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/timo.cloud/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/timo.cloud/privkey.pem
    Your cert will expire on 2018-08-31. 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): Does not matter

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

My hosting provider, if applicable, is: Does not matter

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

Hi,
My old DNS-01-issued certificate expired on 2018-08-31. I just crated a new one. However, the one I got also expired on 2018-08-31. How to issue a completely new certificate?

Thanks,
Kind regards,
Timo

2

Hi @timozikeli

you have created a lot of certificates:

https://transparencyreport.google.com/https/certificates?cert_search_auth=&cert_search_cert=&cert_search=include_expired:false;include_subdomains:false;domain:timo.cloud;issuer_uid:4428624498008853827&lu=cert_search

two today, two yesterday.

If you use certonly, the certificate isn't installed.

What's your configuration file?

Did you restart your server?

You have to use these both paths:

3

Hi,
yes, these certificates are used.

Have a look at the log: It says the newly created certificates expires on 2018.08.31. How is that possible?

The reason for the huge amount of certificates is that certbot somehow installed a cronjob which wanted to renew the certs twice a day, which somehow conflicted with certbot-dns-cloudflare.

Kind regards,
Timo

4

I don’t immediately have an answer for you as to why the certificates you’re seeing are expired, but I can tell you that Let’s Encrypt is producing nice shiny new certificates that aren’t expired. So, the fault isn’t with the Let’s Encrypt service.

So, my thinking would start somewhere like this: Does your process have enough access rights/ privileges / etctera to write the new certificate properly, or is it possible that the new certificate is instead discarded, and then an old one is re-used, which has already expired?

1 Like
5

Then stop the cronjobs. And share your configuration file.

Use

certbot certificates

to see, which certificates exists.

It's not a good idea to use certonly --manual and cronjobs concurrently.

6

It could be the symbolic links in the /live/ directory aren't pointing to the correct files in the /archive/ directory. Could you do a ls -l in the appropriate /live/ and /archive/ directory?

7

The expired date you are seeing is the date from the installed cert.
CERTONLY doesn’t install a cert, it only gets a cert.

8

What do you mean? If nothing goes wrong, using the dns-cloudflare plugin, and a typical systemd timer or cron job, will work fine, and won't issue excessive certificates.

certonly doesn't run installers and configure web servers, but it does update /etc/letsencrypt/live/, which is where Certbot then displays the expiration date from. Something is definitely wrong. (Most likely what Osiris suggested.)

2 Likes
9

...but if the symlinks are borked, it will look at the wrong cert, see that it's expir[ed|ing], and run the renewal again. Everything's pointing to those symlinks being bad.

10

I have no idea why it does not replace the certificates. I renamed the directories and will try again as soon as I am allowed to issue a new cert (do you know from the logs when that will be?).

Anyway, that’s probably the reason for my server having exceeded the rate: It wanted to renew the cert since weeks, and tried it twice a day, even though it was never replaced ^^.

Kind regards,
Timo

11

What changes did you make? What do "sudo certbot certificates" and "sudo ls -alR /etc/letsencrypt/{archive,live,renewal}" show now?

You can calculate when it will be based on the rate limit documentation and Certbot's logs or the public Certificate Transparency logs. There are a couple nice tools to do it, but they use a database that's running behind of late, so they're not accurate anymore.

Yeah, probably. :slightly_frowning_face:

12

The only directory which was last changed in August or later is another domain I have, let‘s call it X. Certbot also just lists that single domain X, probably because I renamed all folders of my domain now. But the directories of my domain in the archive were last changed in June. Even though I run certbot as sudo, it somehow is not able to properly replace these certs…

13

If you manually modified any of the directories inside of /etc/letsencrypt, you probably have damaged your Certbot installation to the point where ‘nuke and pave’ is the simplest option. There is a very specific structure and set of symlinks in that directory that are really, really important for Certbot to function properly. You really shouldn’t modify that structure manually.

14

Now it works:

https://timo.cloud/

A Letsencrypt-Certificate, created today.

15

Yep, got it working 2 minutes ago :slight_smile:

I renamed all directories/configurations and created the certificate including another domain, so the old limit did not apply.

Thanks for your help!

2 Likes
16

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