0

I'm trying to update my letsencrypt wildcard certificate with certbot, but I noticed it behaved strangly when I ran the command. It said it'd add a subdomain name and remove the wildcard as follows:

You are updating certificate example.org to include new domain(s):
+ oma.example.org

You are also removing previously included domain(s):
- *.example.org

Since this is obviously wrong and should not be happening I started searching where the problem might be. I noticed quite quickly that for some reason when I'm trying to resolve the hostname for the wildcard, it instead thinks I'm resolving the hostname for that singular host oma.example.org as follows:

tuki@*****:~$ host *.example.org
oma.example.org has address ***.***.***.***

When using dig, it looks like this:

tuki@*******:~$ dig *.example.org

; <<>> DiG 9.11.3-1ubuntu1.17-Ubuntu <<>> oma.example.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42845
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;oma.example.org.                    IN      A

;; ANSWER SECTION:
oma.example.org.             194     IN      A       ***.***.***.***

;; Query time: 0 msec
;; SERVER: 192.168.1.8#53(192.168.1.8)
;; WHEN: Mon Jun 20 12:59:04 EEST 2022
;; MSG SIZE  rcvd: 55

Why does my server change the wildcard indicator to a hostname? It's not even the hosts own name, but completely unrelated host. I checked the /etc/hosts file, but there was nothing pointing to either the wildcard or that particular host "oma". The query goes correctly to our internal DNS server, but since it asks for the wrong host it receives the wrong answer.

How do I tell the system that the wildcard is supposed to be a wildcard and not some unrelated host?

Thanks in advance for any help you can offer!

EDIT: I'll include my /etc/os-release here for additional information.

NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

EDIT 2: This is the command I'm trying to use to create the wildcard certificate:

 sudo certbot certonly --manual --preferred-challenges dns --cert-name example.org -d *.example.org

EDIT 3: The solution:

Looks like all I needed was to wrap the domain name inside single quotes to make this work. Apparently thats a way to make certbot take the domain name at face value.

sudo certbot certonly --manual --preferred-challenges dns --cert-name example.org -d '*.example.org'
nyoatype
  • 65
  • 1
  • 9
  • Do `***.***` in all cases represent the same thing (say, `example.org`)? – Nikita Kipriyanov Jun 20 '22 at 10:25
  • Yes Nikita, they all represent the same "example.org". I changed my original question to reflect this. – nyoatype Jun 21 '22 at 06:39
  • Better not put a solution into a quesiton, but add an answer to your own question and accept it right away, with all explanation why you went that way. It will show as solved and might help other people who have the same problem to see that this question has a solution. – Nikita Kipriyanov Jun 21 '22 at 10:43

2 Answers2

1

A host name oma.example.org falls within a wildcard *.example.org. Technically it is possible to make a certificate with SAN field containing redundant value DNS:*.example.org, DNS:oma.example.org, but that's pointless, because specific host name is already covered with the wildcard and so the certificate would be equally valid for that host name even if you omit its explicit declaration from the SAN value.

Let's Encrypt went further, they don't even allow this; so it declares *.example.org and oma.example.org to be mutually exclusive and that you are going to drop a wildcard. If you have a wildcard for some domain, you shouldn't specify individual host names within that domain.

This has nothing to do and nothing in common with DNS. There are no wildcards "on the wire" in DNS. A wildcard in DNS is only the way to avoid scripting answers or it can be considered as a simple synthetic record generator.

When you ask for some name, say, oma.example.net you get an answer for that name oma.example.net whatever way it was configured in the server. Even more, it is not possible to determine whether your name was answered in a particular way because it falls within some wildcard of it was set explicitly or the answer was generated by some script; the answer your DNS client would receive will look exactly the same in any case.

Nikita Kipriyanov
  • 10,947
  • 2
  • 24
  • 45
  • This makes sense. How should I go around making letsencrypt wildcard certificate in this case? I have been able to use the same command before, but for some reason it no longer works as expected. – nyoatype Jun 21 '22 at 06:57
  • If you have a valid certificate for `*.example.org`, just use it for `oma.example.org` virtualhost. No need to have a certificate for precisely `oma.example.org`. I mean, you don't need to reissue anything, you already have a valid certificate. It will just work. – Nikita Kipriyanov Jun 21 '22 at 07:00
  • I'm trying to renew my `*.example.org` certificate, but for some reason instead of renewing `*.example.org` it converts the `*.example.org` to `oma.example.org`. I'm not trying to get certificate to `oma.example.org`. As far as I know this command should definitely get a wildcard certificate? "`sudo certbot certonly --manual --preferred-challenges dns --cert-name example.org -d *.example.org`" – nyoatype Jun 21 '22 at 09:18
  • it was absolutely not clear that you just renewing a certificate. Simple `certbot renew` should never trigger such a drastic change. Everything looks like that reissue was triggered by changing configuration (i.e. not just renew, but update with changes). Speaking of which, did you change anything in `/etc/letsencrypt/renewal`, or have you updated certbot since the certificate was last issued? – Nikita Kipriyanov Jun 21 '22 at 09:22
  • Yes, this command will *request a new* certificate. But you already have one, so it should throw an error. Also, the use of `manual` with Let's Encrypt is discouraged; better set up proper automation. – Nikita Kipriyanov Jun 21 '22 at 09:26
  • I think I definitely could have explained the situation in question more clearly, because my situation is a bit different from normal procedure. The crux of the problem is that my DNS provider doesn't offer any way of automatically creating records (not ideal) and thats why I'm unable to automate the DNS challenge. Also, because this is a wildcard certificate it specificlly requires the DNS challenge and doesn't accept other challenges that could be used locally, I think? However, your comments helped me dig a little deeper and I found the fix for this problem. Thanks a lot for your help! – nyoatype Jun 21 '22 at 10:32
0

It looks like in this case I needed to wrap the domain name inside single quotes in order to make certbot take it at face value without trying to resolve it.

Here is how I ended up formatting the command in this case:

sudo certbot certonly --manual --preferred-challenges dns --cert-name example.org -d '*.example.org'

nyoatype
  • 65
  • 1
  • 9