Cerbot uses wrong subdomain when doing dns query

Im running a debian server using nginx as my webserver.
Cerbot works perfrect in manual mode.
However when I try certbot --nginx renew it seems to trip up on certain subdomains.

My domains are:
owncloud.xxxx.de and
cloud.xxxx.de
(Where xxxx my peronal name domain)
I ran this command:
certbot --nginx renew
It produced this output:


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/cloud.xxxx.de.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for owncloud.xxxx.de
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (cloud.xxxx.de) from /etc/letsencrypt/renewal/cloud.xxxx.de.conf produced an unexpected error: Failed authorization procedure. owncloud.xxxx.de (http-01): urn:ietf:params:acme:error:dns :: No valid IP addresses found for owncloud.xxxx.de. Skipping.    

My web server is (include version):

nginx/1.14.2

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

PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
2018100200

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

It seems like it's trying to renew the cloud.xxxx.de cert (which is correct) but when making the actual dns query uses the wrong (owncloud.xxxx.de deprecated) domain and correctly doesn't find a domain entry for it.
I suspect some part of the validation process using a regex that first matches the owncloud.xxxx.de (first in the alphabet) and uses it.
For me the fix is easy (Just removed my old owncloud config file) but for others that actually use subdomains that contain others this might be a problem.
I tried to find the part in the source code that could cause this behavior but wasn't successful.
Greetings

I'm not sure what you mean by this? What kind of regex? What kind of first match?

This could be due to erroneous symbolic linking in the /etc/letsencrypt/ directory tree.

Best is to start with the renewal configuration file: could you paste the contents of /etc/letsencrypt/renewal/cloud.xxxx.de.conf?

Please try (just):
certbot renew

Contents of cloud.xxxx.de.conf config file:

# renew_before_expiry = 30 days
version = 0.31.0
archive_dir = /etc/letsencrypt/archive/cloud.xxxx.de
cert = /etc/letsencrypt/live/cloud.xxxx.de/cert.pem
privkey = /etc/letsencrypt/live/cloud.xxxx.de/privkey.pem
chain = /etc/letsencrypt/live/cloud.xxxx.de/chain.pem
fullchain = /etc/letsencrypt/live/cloud.xxxx.de/fullchain.pem

# Options used in the renewal process
[renewalparams]
server = https://acme-v02.api.letsencrypt.org/directory
authenticator = nginx
installer = nginx
account = <account number>

I couldn't find any symbolic links in the letsencrypt directory.
Greetings

It comes up with the exact same error.
Greetings

What's the output of:

sudo ls -l /etc/letsencrypt/live/cloud.xxxx.de/

?

I don't exactly know where the problem was but i just removed and reinstalled nginx and certbot and now it works. Got rid of some old config files too. Thanks for the support anyways.

1 Like

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