Certificate renewal problem with acme dns challenge

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: dipstik.info

I ran this command: sudo certbot renew --dry-run

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/dipstik.info.conf

Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator manual, Installer None
Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for dipstik.info
dns-01 challenge for dipstik.info
Cleaning up challenges
Attempting to renew cert (dipstik.info) from /etc/letsencrypt/renewal/dipstik.info.conf produced an unexpected error: Missing command line flag or config entry for this setting:
NOTE: The IP of this machine will be publicly logged as having requested this certificate. If you're running certbot in manual mode on a machine that is not your server, please ensure you're okay with that.

Are you OK with your IP being logged?

(You can set this with the --manual-public-ip-logging-ok flag). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/dipstik.info/fullchain.pem (failure)

** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/dipstik.info/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)

1 renew failure(s), 0 parse failure(s)

My web server is (include version):
I am running a python based server (python 2.7 using SimpleHTTPServer)

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

My hosting provider, if applicable, is: Digital Ocean

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): 0.40.0

I have recently attempted to upgrade a simple HTTP site to use HTTPS and be compliant with modern browsers.

I was originally running on Ubuntu 18.04 and managed to set up the system using letsencrypt. It appeared to work. Due to some general system reliability issues, I have now upgraded to Ubuntu 20.04. Now I am having issues with challenge failures and renewal failures as above.

I originally used guidance from this document How To Acquire a Let's Encrypt Certificate Using DNS Validation with acme-dns-certbot on Ubuntu 18.04 | DigitalOcean
to set up my system.
The system was originally set up using certbot 0.31.0

I am hoping someone might have seen this behaviour and can offer some guidance.

Despite these issues, my website is basically running but I suspect I will have a problem when I need to renew the certificates in a a few months.



Hi @Tuftec, and welcome to the LE community forum :slight_smile:

That seems strange.

Please follow these directions to remove that version of certbot and install the latest version from snap:



I will give that a try and report back.





I have now followed the instructions and installed certbot via snap. It returns 1.29.0

Here is the output after doing a test renew:

sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/dipstik.info-0001.conf

Simulating renewal of an existing certificate for dipstik.info
Failed to renew certificate dipstik.info-0001 with error: Missing command line flag or config entry for this setting:
Input the webroot for dipstik.info:

Processing /etc/letsencrypt/renewal/dipstik.info.conf

Simulating renewal of an existing certificate for *.dipstik.info and dipstik.info

The following simulated renewals succeeded:
/etc/letsencrypt/live/dipstik.info/fullchain.pem (success)

The following simulated renewals failed:
/etc/letsencrypt/live/dipstik.info-0001/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

It appears that it is trying to use my original certificate (dipstik.info) and the new certificate (dipstik.info-0001).
There are problems with both.

When I navigate to the website, it appears to be secured with the original certificate (based on the expiry date). Is there some way I can confirm what certificate is being used.

Any assistance would be appreciated.


this is the response I got back from the new certbot when creating the new certificate:
Requesting a certificate for dipstik.info

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/dipstik.info-0001/fullchain.pem
Key is saved at: /etc/letsencrypt/live/dipstik.info-0001/privkey.pem
This certificate expires on 2022-11-04.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

How do I set up the .well-known directory.
I am not sure whether my simple DIY webserver is able to serve from this.
What exactly needs to be put into this directory?

Because of the simplicity of my web server, I made the original decision to set up DNS challenging using the acme CNAME entry on the DNS records. Is this likely to cause a conflict with the new webroot method? Should I change back to DNS? If so, how do I do this?


Your wildcard cert using the DNS challenge has the name dipstik.info in the /live/ folder in your system. Your -0001 cert name used webroot http challenge and is not a wildcard. Wildcards require a DNS challenge.

Your current server is sending out the wildcard. See SSL Cert Decoder site like this one

You will see your server cert fails to validate. That is because you send out only the "leaf" cert.pem file and not the "fullchain.pem" file.

We will need to clean up your cert folders now that you have two overlapping ones. We can start by you showing output of this:

sudo certbot certificates

And, let us know whether you want to proceed with DNS wildcard or the non-wildcard one.

I don't know how your server is configured so you will need to research how you make it send the fullchain rather than just the leaf. If you point me to docs that describe it I can probably help.
Update: I see from several google sources that you just replace the cert.pem file name with fullchain.pem. Not sure if there is a minimum version of SimpleHTTP to support fullchain though.


Thanks. I will dig into the certificates shortly.
One factor that might be of relevance to using the webroot method is that my simple server DOES NOT support POST!!! It only supports GET and HEADER requests.


1 Like

No worries. POST are not sent during http challenge



Output from certificates:

sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Found the following certs:
Certificate Name: dipstik.info-0001
Serial Number: 4982afa52ac7d89ec94413a1c76ab486122
Key Type: RSA
Domains: dipstik.info
Expiry Date: 2022-11-04 01:08:09+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/dipstik.info-0001/fullchain.pem
Private Key Path: /etc/letsencrypt/live/dipstik.info-0001/privkey.pem
Certificate Name: dipstik.info
Serial Number: 3809a0300903a542a30521e6aa449df106e
Key Type: RSA
Domains: *.dipstik.info dipstik.info
Expiry Date: 2022-11-03 05:56:11+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/dipstik.info/fullchain.pem
Private Key Path: /etc/letsencrypt/live/dipstik.info/privkey.pem

I need my certificate to cover dipstik.info, www.dipstik.info and wild cards *.dipstik.info I suspect.

And, you should quit requesting new certs for a while. You only get 5 per week with exactly the same name and you already got 5 for dipstik.info. You will be error about Rate Limited if you try that name again.

You have other name combinations with multiple but fewer than 5 so just beware. You don't have a problem getting certs. Just configuring your server.




So what do you suggest moving forward? Maybe I just focus on the certificate that has distik.info & *.dipstik.info. Does that sound sensible? Do I need to delete the other certificates when I get things going correctly?

What should my next steps be?


OK, then you need to use DNS challenge. A cert can have up to 100 names in it so if you have a fairly small number of names that don't change often an HTTP challenge non-wildcard is often sufficient. But, DNS is fine too if you prefer that.

So, two things. One, use the fullchain.pem file in your SimpleHTTP server config instead of cert.pem and test it using that SSL Decoder I linked earlier.

Second, delete the unused cert with:

sudo certbot delete --cert-name dipstik.info-0001

I will have a try to follow your suggestions.


Oh, just reviewing the entire thread we should also check that the remaining cert will properly renew. Would you show result of this?

sudo certbot renew --cert-name dipstik.info --dry-run

--dry-run is test only and will not create another cert.

If that fails, show contents of this file:


Hi Mike,

You are a champion.
That all seemed to work successfully.

sudo certbot renew --cert-name dipstik.info --dry-run
[sudo] password for dipstik:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/dipstik.info.conf

Simulating renewal of an existing certificate for *.dipstik.info and dipstik.info

Congratulations, all simulated renewals succeeded:
/etc/letsencrypt/live/dipstik.info/fullchain.pem (success)



1 Like

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