Modify certbot manually created certificate

Help
#1

My domain is: www.theartstory.org

I ran this command:

sudo certbot certonly --cert-name www.theartstory.org -d www.theartstory.org,theartstory.org

It produced this output:

Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.

My web server is (include version): Apache/2.4.25 (Debian)

The operating system my web server runs on is (include version): Debian GNU/Linux 9.12 (stretch)

My hosting provider, if applicable, is: Google Compute Engine

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.28.0

I’m moving my website to a new server (debian9+apache).

I’ve installed a certbot certificate for my domain via command:

sudo certbot certonly -d www.theartstory.org --manual --preferred-challenges dns

I’ve used this command insead of:

sudo certbot --apache

because at that date DNS records were configured to old ip adress.

Now I need to add not-www version to this certificate.

#2

Just ‘force’ the use of the Apache plugin again (but without certonly, because you didn’t use that the first time either, so that suggests to me you’d like the apache plugin to [re]install the certificate too):

sudo certbot --apache --cert-name www.theartstory.org -d www.theartstory.org,theartstory.org

#3

This doesn’t work:

sudo certbot --apache --cert-name www.theartstory.org -d www.theartstory.org,theartstory.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

You are updating certificate www.theartstory.org to include new domain(s):

  • theartstory.org
    You are also removing previously included domain(s):
    (None)
    Did you intend to make this change?

(U)pdate cert/©ancel: U
Renewing an existing certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.

#4

I don’t understand why
 :man_shrugging:

@schoen / @bmw Do you have any clue why the apache authenticator would complain about this, while there isn’t any wildcard hostname included? Is it perhaps a bug fixed since certbot v0.28?

#5

Hi @adrenalin

what’s the content of your certbot configuration file?

See

/etc/letsencrypt/renewal

and share the content of that file.

#6

renew_before_expiry = 30 days

version = 0.28.0
archive_dir = /etc/letsencrypt/archive/www.theartstory.org
cert = /etc/letsencrypt/live/www.theartstory.org/cert.pem
privkey = /etc/letsencrypt/live/www.theartstory.org/privkey.pem
chain = /etc/letsencrypt/live/www.theartstory.org/chain.pem
fullchain = /etc/letsencrypt/live/www.theartstory.org/fullchain.pem

Options used in the renewal process

[renewalparams]
server = https://acme-v02.api.letsencrypt.org/directory
installer = None
account = [ACCOINT_ID]
authenticator = webroot
webroot_path = /var/www/html

P.S. I think, I’ve changed this file to enable automatic renewal.
The initial content:


[renewalparams]
authenticator = manual
server = https://acme-v02.api.letsencrypt.org/directory
pref_challs = dns-01,
manual_public_ip_logging_ok = True
account = [ACCOINT_ID]

#7

Remove the last two rows - webroot can’t work with dns validation.

#8

@JuergenAuer I’m pretty sure you’d get an unusable configuration file if you’d remove the authenticator line.

#9

I rolled back old config file with content:



[renewalparams]
authenticator = manual
server = https://acme-v02.api.letsencrypt.org/directory
pref_challs = dns-01,
manual_public_ip_logging_ok = True
account = [ACCOINT_ID]

But get the same error


#10

Looks like your configuration is completely buggy. May be more then one Certbot, may be you have copied files from an older configuration.

  • Make a backup
  • Delete the config files
  • start with sudo certbot interactive
#11

What do you mean? A’ve created 2 certificates, one for desktop, one for mobile subdomain, but now I deal only with desktop one.

No. I made changes as written above, but now I revert them.

It will generate new certificate or just new .conf file? The website is live now and i don’t want to break ssl


#12

If I remember correctly, there was a bug that got inadvertently fixed around 0.31.0, yes. When Let’s Encrypt removed unused challenges from valid authorizations, older versions of Certbot would get upset if it reused an authorization that was made using a challenge type not supported by the current plugin. (Obviously, that’s wrong, which is why it’s called a bug!)

In that case, deleting your certificates and configuration files won’t help – the problem is the authorization. Deleting your account would work around the issue because authorizations are associated with accounts.

(Certbot’s renewal configuration files include an account ID, so deleting your account breaks renewal until you fix the files.)

If that’s the issue, would you mind waiting a few weeks to update your configuration? When you validate a name, Let’s Encrypt remembers it for 30 days, and doesn’t force you to validate it again. Once the old authorization expires, the Certbot bug won’t be triggered anymore. If you don’t mind waiting, it’s the simplest way to solve that issue.

1 Like
#13

Authorizations can be dropped manually, but I don’t know how easily with certbot.

(acme.sh has --deactivate)

1 Like
#14

Certbot doesn’t have a convenient way to do it.

(In recent versions, --dry-run automatically does it, though.)

#15

Thx, but I dont’t understand what to do now


  1. What have I done wrong? What actions (certbot commands) led to this situation?

How will this affect on the current certificate? And how to get new account/certificate?

No. I need to fix this issue ASAP. Any other ways to fix?

#16

production and staging use different accounts, though, so it’s not that useful here. :man_shrugging:

#17

Well, you haven’t done anything bad. If Debian 9 had a newer version of Certbot, you wouldn’t even have any trouble at all.

What’s happening (I think) is:

You validated www.theartstory.org using DNS-01 (You issued a certificate on 2020-04-12, so it was probably then.)

After an ACME account has validated a name, Let’s Encrypt (normally) allows it to reuse the same validation for 30 days.

Now you’re trying to issue a new certificate using the apache plugin, which only supports HTTP-01 validation.

Due to an issue in old versions of Certbot, and a recent change in the Let’s Encrypt’s API, when you run it again, Certbot thinks, “DNS-01 validation!? But I need to use HTTP-01 validation! Oh no!” and raises an error. (Even though, in fact, Certbot doesn’t need to validate the name a second time, and there’s no problem at all.)

So the simplest way to solve it is to wait until the authorization expires.

Another relatively simple option would be to use the manual plugin again to get your new certificate – of course, you’d have to switch to the apache plugin before it expires!

You might consider using certbot-auto to run the most recent version of Certbot just once to create the certificate. (The old version won’t run into this problem renewing it 2 monhs from now.)

#18

I think, that I dont’ need a new certificate?
I just need to add non-www version of my domain to existing one


Which command should I use?

Yes, but I wanted to get a certificate before DNS change


#19

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