Failed to renew certificate, there may be problems with existing configuration (Docker, nginx, certbot)

I'm using Docker to run multiple applications using containers and nginx as reverse proxy.

My domain is:
internobis.com and I also want the certificate to work with cms.internobis.com (and any subdomain).

I ran this command to create the certificate the first time:

docker-compose run --rm  certbot certonly --webroot --webroot-path /var/www/certbot/ -d internobis.com

After I realized that the certificate didn't work with a subdomain, I ran this command:

docker-compose run --rm certbot certonly --manual --preferred-challenges=dns --email test@gmail.com --agree-tos --expand -d internobis.com,*.internobis.com

My web server is:
nginx:1.21.5-alpine

The operating system my web server runs on is:
Ubuntu 20.04 LTS

My hosting provider is:
Amazon AWS Lightsail

I can login to a root shell on my machine:
yes

I'm using a control panel to manage my site:
no

The version of my client is (certbot --version):
certbot 1.22.0

The certificate is working good and no problem with the generation of it.


My problem now is trying to test if the renew process is successful using "--dry-run".

I ran this command to renew:

docker-compose run --rm certbot renew --dry-run

Output:

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/internobis.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Failed to renew certificate internobis.com with error: The manual plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively.')

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/internobis.com/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

I have also tried using this command:

docker-compose run --rm certbot renew --preferred-challenges=dns --webroot --webroot-path /var/www/certbot/ --dry-run

Output:

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/internobis.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for internobis.com and *.internobis.com
Failed to renew certificate internobis.com with error: None of the preferred challenges are supported by the selected plugin

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/internobis.com/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

My goal is to be able to renew my certificate for my domain and all its subdomains successfully.

You say your first command using the http-01 challenge (webroot) didn't contain a subdomain.

Next, you're getting a wildcard certificate which makes your life very difficult, as it requires the dns-01 challenge.

Is that wildcard even necessary? How many subdomains are we talking of? Just one? A few? Thousands?

2 Likes

Hi,

Thanks for your reply.

For now, I just need 1 subdomain "cms.internobis.com". I also would like the certificate to work with www.

Example:

In the future, maybe in about 2-3 months I will need to create another subdomain for another application.

I thought that getting a wildcare certificate now would save me time in the future and I wouldn't have to worry about it.

These can easily be added to a certificate with the --webroot plugin, which is easily automated, compared to the not-so-easily automated dns-01 challenge, as you've figured out now.

Your *.internobis.com wildcard certificate does NOT include this subdomain. You'd need a *.cms.internobis.com wildcard for that, as the *. of a wildcard certificate will only cover a single DNS label, not two or more. It probably is way easier to just include this hostname into a non-wildcard certificate too.

Then in about 2-3 months you can add the other subdomain(s) again. A Let's Encrypt certificate is limited to 100 (!) hostnames in total, so plenty of room for a few more subdomains :slight_smile:

Sometimes it is, sometimes it isn't. Knowing the consequences of certain choices is paramount when making those choices.

2 Likes

To see if I understood, you are saying that I should create a new certificate using just cms.internobis.com and *.cms.internobis.com to cover www?

If this is the way to go, I think the commands that I need are:

certbot certonly --webroot --webroot-path /var/www/certbot/ -d internobis.com,*.internobis.com

and for the subdomain:

certbot certonly --webroot --webroot-path /var/www/certbot/ -d cms.internobis.com,*.cms.internobis.com

am I right?


In addition, won't be easier to maintain if I keep all of them in a single certificate? Due to I have a certificate now, maybe using the --expand flag to add the subdomain...
(maybe my issue here is what is the best practice and the easiest way)

Still, I'm freezed about how to renew it correctly. What should I do? I don't understand why with my existing configuration the renew process is failed.

this is my first time using certbot and let's encrypt, forgive me for any ignorance

I'm saying, to make your life easier, forget about the wildcards altogether, unless you have hundreds to thousands of subdomains.

Not at all close.

Even if you wanted to use wildcards, why run two commands for two separate certificates? Why not just include everything in a single certificate? That way cms.internobis.com would be covered by *.internobis.com.

Further more, as I said earlier, you cannot use the http-01 challenge provided by the --webroot plugin to get a wildcard certificate. A wildcard certificate mandates the dns-01 challenge, which gives you the trouble you're having now with renewal to begin with. (I'm sounding like a broken record repeating myself..)

My advice would be a single command without a wildcard:

certbot certonly --webroot --webroot-path /var/www/certbot/ -d internobis.com,www.internobis.com,cms.internobis.com,www.cms.internobis.com

That way no pesky DNS challenge but the http-01 challenge with the --webroot plugin, so you can easily run certbot renew to renew the certificate.

2 Likes

Understood.

If i'm not wrong, I cannot request a new certificate for a domain that already has one and is not expired.

If I run right now:

certbot certonly --webroot --webroot-path /var/www/certbot/ -d internobis.com,www.internobis.com,cms.internobis.com,www.cms.internobis.com

It will create another certificate in another folder, for example:
/etc/letsencrypt/live/internobis.com-0001

My question is:

  1. If I delete my current certificate, will I be able to create a new one ? (I will use the command that you shared with me that ran good using dry-run)
  2. Will be better to just use the new certificate and ignore the first one? (this way the renew process will just succeed, but I will have two now and one of them unused)
  3. Or what is the best way to do this changes for my case?

I'm sorry, but you're wrong: it's perfectly possible to request and get a certificate for a domain that already is included in another certificate. The only thing to worry about is running into rate limits, but with just a few certificates, that's not an issue.

That's possible, yes. Using the --cert-name option it's possible to overwrite existing certificates. Overwriting the existing certificate also makes it easier regarding webserver configuration updates and you also don't need to delete anything. Just make sure all the required hostnames are included in the certificate.

You can create a new one already.

If you don't have a way to automate the dns-01 challenge (as is the case here, it seems), I think it's better to use the new certificate without wildcards, yes.

3 Likes

Thanks for all my friend, all is working good, also the renew process. Your explanations helped a lot.

4 Likes

I can confirm your 4 hostnames all serve the same certificate with those 4 hostnames in it. :+1:

However, I see you've issued that certificate twice today: https://crt.sh/?Identity=internobis.com&deduplicate=Y

Can you check to be certain that Certbot only has one certificate listed by running:

certbot certificates

Maybe you've got a duplicate.

3 Likes

Hi,

Before doing your recommendation, I ran accidentally without --dry-run:

certbot certonly --webroot --webroot-path /var/www/certbot/ -d internobis.com,www.internobis.com,cms.internobis.com,www.cms.internobis.com

it was successful and the output was the creation of another certificate in the path: /etc/letsencrypt/live/internobis.com-0001

Then, I just delete that one using

certbot delete --cert-name internobis.com-0001

Now to check the current certificates:

certbot certificates

The output is:

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: internobis.com
    Serial Number: 3fe47b0dd325a22ac40a255dd8afba4e7cc
    Key Type: RSA
    Domains: internobis.com cms.internobis.com www.cms.internobis.com www.internobis.com
    Expiry Date: 2022-04-30 12:35:15+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/internobis.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/internobis.com/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Right now, I just have one certificate.


Watching the link that you provided, this one, I'm curious about why there are subdomains that I don't know about. For example: autodiscover.internobis.com and cpcalendars.internobis.com.

Looks like that cert was issued from cPanel. Maybe your hosting provider has set that up, I dunno.

3 Likes

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