None of the preferred challenges are supported by the selected plugin

Dear Team,

We have setup the auto renewal using letsencrypt. It was working fine when we test.

It is a DNS Challange

It is now failed after two months when we execute below command.

Command: certbot renew --force-renewal

Error:
unexpected error: None of the preferred challenges are supported by the selected plugin. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/work.xxxxx.com/fullchain.pem (failure)


All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/work.xxxxxx.com/fullchain.pem (failure)


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

Kindly advise how to fix this issue

Thanks

1 Like

Hi @kumar.argentra

your complete setup is required, not only some parts.


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. crt.sh | 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:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

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

1 Like

Dear JuergenAuer

Here is required details.

I ran this command:certbot renew --force-renewal

It produced this output:
unexpected error: None of the preferred challenges are supported by the selected plugin. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/work.xxxxx.com/fullchain.pem (failure)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/work.xxxxxx.com/fullchain.pem (failure)

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

My web server is (include version):apache server

The operating system my web server runs on is (include version):"CentOS Linux 7

My hosting provider, if applicable, is:hostrocket

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

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

Thanks

1 Like

Can we have a look at?:
/etc/letsencrypt/renewal/work.xxxxx.com.conf

And using "--force" is hardly ever the answer to any conflict.

1 Like

Dear rg305

Thanks for the response. If the certificate is already expired, shall we call "certbot renew" command?
In my case, cert has been expired , when renewing the certificate by calling "certbot renew" command

Kindly advise us , how to call cert renew command for expired certs

Thanks

1 Like

Hi @kumar.argentra,

The --force-renewal option means that Certbot should try to renew even if the certificate has more than 30 days of validity left. If the certificate has fewer than 30 days of validity, including if it's already expired, --force-renewal has no effect because the renewal attempt will happen anyway.

The only purpose and effect of --force-renewal is that it can make Certbot renew certificates in circumstances that it considers to be premature.

I agree that it would be useful to see the contents of the renewal configuration file from /etc/letsencrypt/renewal in order to figure out which Certbot plugin is being used.

You can learn more about the details of the underlying issues that can result in this error from

and

2 Likes

Dear schoen,

Thanks for your response. Below are configuration from etc/letsencrypt/renewal

renew_before_expiry = 30 days

version = 1.10.1
archive_dir = /etc/letsencrypt/archive/xxxx.com
cert = /etc/letsencrypt/live/xxxxx/cert.pem
privkey = /etc/letsencrypt/live/xxxx/privkey.pem
chain = /etc/letsencrypt/live/xxxxx/chain.pem
fullchain = /etc/letsencrypt/live/xxxxx/fullchain.pem

Options used in the renewal process

[renewalparams]
authenticator = standalone
account = ccaca391a26d218f4f3250bbe05d79a1
pref_challs = dns-01,
manual_public_ip_logging_ok = None
server = https://acme-v02.api.letsencrypt.org/directory

Please help us to solve the issue

Thanks

2 Likes

This combination of authenticator = standalone and pref_challs = dns-01 is indeed inconsistent. Do you have any recollection of how it got that way? Do you know how you, or someone else, selected either or both of those options? (The standalone authenticator and/or the DNS challenge type)

2 Likes

Dear schoen

We have setup auto ssl by following below commands

  1. sudo certbot certonly --manual --preferred-challenges dns -d xxxxxx
  2. sudo certbot certonly --standalone --preferred-challenges dns -d xxxxx

the renew command was fine, when we run after setup was completed(certbot renew --force-renewal)

But renew is now failed with the error ( [None of the preferred challenges are supported by the selected plugin])

Thanks

2 Likes

Hi @kumar.argentra,

Thanks for the explanation.

It seems to me that you've found a subtle bug in Certbot, which I can understand as a former Certbot developer but which is not at all obvious from a user's perspective.

sudo certbot certonly --manual --preferred-challenges dns -d xxxxxx

This command succeeds because you manually completed the steps that Certbot instructed you to perform (by creating DNS TXT records).

sudo certbot certonly --standalone --preferred-challenges dns -d xxxxx

This command would normally not succeed, because --standalone is incompatible with --preferred-challenges dns. However, Certbot failed to detect this condition, probably because of something called a cached authorization (where the certificate authority is willing to give out a duplicate certificate within a short period of time after the original certificate without repeating the validation). Therefore, Certbot succeeded in getting this certificate, too, even though the command-line options you used would normally be inconsistent and unsuccessful (under other circumstances).

Unfortunately, since this request succeeded due to the cached authorizations, I expect that Certbot concluded that the --standalone and --preferred-challenges dns options "worked" (since the certificate was successfully issued) and therefore saved them into the file in /etc/letsencrypt/renewal to be used in the future.

But once the cached authorization expired on the certificate authority side, the renewal could no longer succeed. Nonetheless, the /etc/letsencrypt/renewal file had an unhelpful set of non-working defaults saved because they appeared to have worked before.

My short-term recommendations would be:

(1) If you just need to perform the renewal right away, repeat this command

sudo certbot certonly --manual --preferred-challenges dns -d xxxxxx

Note that it will require you to create new DNS TXT records. This is always the case after cached authorizations expire, which is why this form of the certbot command doesn't work for setting up automated, unattended renewals. However, it will still work manually.

(2) Decide whether --preferred-challenges dns is really what you want. Normally this is only useful if you're requesting a wildcard certificate, or running Certbot on a machine that can't receive incoming connections from the public Internet, or running Certbot on a machine that isn't authoritative for one or more of the names on the certificate, at least as seen by the public Internet.

(3) If you need --preferred-challenges dns, you'll need an --auth-hook shell script or a DNS API plugin for Certbot in order to get automated renewals. The TXT records that must be posted for domain ownership confirmation are different for every renewal, so it must be possible to create them purely from software.

(4) If you don't need --preferred-challenges dns, you can switch to a different authentication method, including --standalone, --webroot, or whichever method is most suitable for your environment. In that case, you can delete the preferred challenges line from the file in /etc/letsencrypt/renewal.

4 Likes

@_az, do you think my diagnosis is plausible, and do you happen to know if this is a known bug? I'm a little unsure conceptually about what the right Certbot behavior would be in this case (since people might sometimes intentionally force an early renewal using cached authorizations, with the goal of changing the renewal configuration file).

1 Like

@kumar.argentra if you don't understand why this is so, the pair of documentation links that I posted above (beginning "You can learn more about the details of the underlying issues") will explain it.

2 Likes

Yes, I recall something similar with a user believing --standalone would succeed while their webserver was still running, due to the same behavior.

Fixing #5342 may have exacerbated this problem. At least before, Certbot's (pointless) effort to fulfill the challenge served as a basic sanity check of the authenticator setup.

It's hard to know what to do about this, but to me it seems to largely fall into a broader "provide an better way to modify existing lineages" project. Having to re-issue the certificate (or modify what is an internal file) is too much.

Perhaps this would lead to something like "you are changing the authenticator, do you want to test this change with a dry-run first?". (Dry-runs force fresh authorizations).

That said,

I would love to understand why @kumar.argentra landed on this pair of commands. Why two different certificates? What do the xxxxx represent? Could you restate this by using example.com instead of totally obscuring the domain?

2 Likes

Dear schoen and _az

Thanks for your responses. It is more valuable to me to understand the concept of letsencrypt

Thanks

1 Like

Dear _az

We have setup auto ssl by following below commands

  1. sudo certbot certonly --manual --preferred-challenges dns -d work.argentra.com
  2. sudo certbot certonly --standalone --preferred-challenges dns -d work.argentra.com

the renew command was fine, when we run after setup was completed(certbot renew --force-renewal)

But renew is now failed with the error ( [None of the preferred challenges are supported by the selected plugin])

Thanks

1 Like

Dear _az,

Please take a note that our work.argentra.com is internal and commands are being called in private virtual machine and work.argentra.com online is just dummy site which is available from internet for dns challenges . Kindly advise, how we can automate

Thanks

1 Like

When speaking directly with other community members you need to use the @ symbol in front of the name.

Like:
@_az @kumar.argentra

Not just the name:
_az kumar.argentra

1 Like

The best way to test renewal is with

certbot renew --dry-run

This will be a more accurate test than --force-renewal, as it's not subject to cached authorizations.

I see. Are you running these commands on different servers? One on the internal server, one on the dummy site?

Yes, I think this is the right question to ask.

For DNS challenges, the idea is usually to find an ACME client that supports your DNS host. I'm not familiar with hrnoc.net, are those your own self-hosted nameservers? Can you use nsupdate/RFC2136 to automatically create TXT records on it?

You might also be able to automate HTTP challenge instead, if you can copy files to the dummy site under /.well-known/acme-challenge/. For example, by using a script from the internal server to connect to the dummy site.

3 Likes

@_az Thanks for response.

For manual http challange, we have to call below command and followed the instructions such as uploading http challange file to complete the process

sudo certbot certonly --manual --preferred-challenges http -d work.argentra.com

For Auto HTTP Challenge, where do we need to call the script to copy file under /.well-known/acme-challenge/. Kindly advise

Thanks

2 Likes

@_az , Please find my answer below for your question

Question: I see. Are you running these commands on different servers? One on the internal server, one on the dummy site?

Answer: We are running on different internal server. not on the dummy site or server

Thanks

2 Likes