Certbot only wants to renew existing certs and not new domains

[icelava]

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: *.icelava.net

I ran this command:
certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d *.icelava.net

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/le.icelava.net.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1

My web server is (include version): Nginx 1.14.0-0ubuntu1.6

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

My hosting provider, if applicable, is: N/A

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

I had successfully tested requesting for static certificate via auto inspect of Nginx config files to determine the FQDN (i.e. le.icelava.net).

Now I am testing converting le.icelava.net into a sub-domain with its own delegated DNS server (with ACME-DNS), to try wilcard certificate requests and the ability to dynamically insert TXT records into the sub-domain.
https://github.com/joohoi/acme-dns + https://github.com/joohoi/acme-dns-certbot-joohoi

Howerver on executed the long command chain, even though I never specify the --nginx option, and even declared the domain name to be *.icelava.net, Certbot only seems to want renew the old le.icelava.net cert. I’m confused what must I really do to get Certbot honour the -d parameter that is explicitly there? And to ignore any other domain certs that may exit in the system?

[schoen]

Hi @icelava,

The name of the certificate on disk does not necessarily reflect its domain coverage. Here le.icelava.net is just what Certbot uses to refer to the certificate. If you run certbot certificates to see its actual coverage, I predict that it does include the wildcard coverage in the actual certificate itself.

[schoen]

@icelava

-d *.icelava.net

Alternatively, if you're running this command in a directory that contains a file named le.icelava.net, the Unix shell is expanding your wildcard and actually replacing the *.icelava.net with le.icelava.net. The correct practice when referring to names that contain the * character in a Unix shell is always to escape or quote the wildcard character, like

-d "*.icelava.net"

or

-d \*.icelava.net

This issue could also be producing the result that you're seeing.

[icelava]

Ok I escaped the * character and Certbot was able to proceed in a more expected manner. However it then seems like the Python script acme-dns-auth.py to interact with ACME-DNS has a connection problem

Are you OK with your IP being logged?

---

(Y)es/(N)o: y
Hook command "/etc/letsencrypt/acme-dns-auth.py" returned error code 1
Error output from acme-dns-auth.py:
Traceback (most recent call last):
File "/etc/letsencrypt/acme-dns-auth.py", line 144, in
account = client.register_account(ALLOW_FROM)
File "/etc/letsencrypt/acme-dns-auth.py", line 46, in register_account
res = requests.post(self.acmedns_url+"/register")
File "/usr/lib/python2.7/dist-packages/requests/api.py", line 112, in post
return request('post', url, data=data, json=json, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/api.py", line 58, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 520, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 630, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 508, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='192.168.0.21', port=8080): Max retries exceeded with url: /register (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f4d1996cfd0>: Failed to establish a new connection: [Errno 111] Connection refused',))

Previously when I attempted according to instructions manual curl POST to ACME-DNS /register and /update endpoints (port:8080) they appeared fine. So I'm wondering what type of connection is really happening here. I inserted a new entry for port 8080 into ufw just to be sure but that didn't help. Hmmm...

UPDATE
Ah ok, the problem was when I setup ACME-DNS last night, since it was every software hosted within a single test VM, I simply set ACME-DNS to bind to loopback 127.0.0.1:8080 so nobody outside can make those REST API calls other than internal Certbot. Adjusting to 127.0.0.1 explicitly works. Thanks.