Its up to the client to setup the SAN list in the CSR. If you only request a certificate for *.example.com without adding example.com to the SANs, it's most probably your fault.
You'll get one challenge and this
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Error finalizing order :: Order includes different number of names than CSR specifies",
"status": 403
for csr with both domain itself and *. for subdomains.
If you have a server that handle request for * .example.com and another for example.com it may create some security issues if you can't have a certificate valid only for "*.example.com".
I think this is not an bug but an feature that shows another point why the challange for
wildcard and domain should be different. For example and company have an Hosting Location where customerXY.domain is hosted on one server and another location with only domain for the company representation and they maybe like to separate this two certificates. But it should be mentioned prominently that often both names should be included.
So that it over more flexibility to the users.
Thank you guys, I got the point.
I successfully received the cert for *.domain.example and domain.example
using a .csr with cn=domain.example and
both
X509v3 Subject Alternative Name:
DNS:domain.example, DNS:*.domain.example
# INFO: Using main config file /etc/dehydrated/config
+ Requesting new certificate order from CA...
+ Received 2 authorizations URLs from the CA
+ Handling authorization for domain.example
+ Found valid authorization for domain.example
+ Handling authorization for domain.example
+ Found valid authorization for domain.example
+ 0 pending challenge(s)
+ Requesting certificate...
+ Checking certificate...
+ Done!