I need a certificate for some subdomains/sites, like for exemple:
For this I need to request one certificate for each site7subdomain?
Or I can request a certificate for the domain, valid for all subdomains? For example:
*.mydomain.com
Thanks & regards
Hi @Rui
these are your options:
See
PS: There are some rate limits, but 7 subdomains aren't a problem.
As Jürgen says, all three options are available. There is a policy difference from Let's Encrypt's side about issuing the wildcard certificate—if you want a wildcard certificate, you'll have to use the DNS challenge method to prove your control over the domain name.
For non-wildcard certificates, you can also use other challenge types instead.
Before open this topic, I already get the certificate for www.mydomain.com, using the command:
certbot certonly –standalone
And now I read some here that:
“ both *.example.com and www.example.com would produce an error since the wildcard entry makes the latter redundant. ”
How could I request the wildcard certificate *.mydomain.com now?
Can I do something like this?
certbot certonly --cert-name www.mydomain.com -d *.mydomain.com
Thanks & regards,
Rui
You can request it with --manual, like
certbot certonly --manual -d '*.mydomain.com'
or if you want to include the apex domain mydomain.com too (which would not be covered by *.mydomain.com because it only has one .),
certbot certonly --manual -d '*.mydomain.com' -d mydomain.com
Certbot will tell you the DNS TXT records to create to satisfy the challenges, and ask you to press Enter to continue when ready.
This is not great because this can only be renewed by re-running the same command. (The automated renewal command certbot renew will give a note that a certificate obtained with --manual can't be renewed with certbot renew, because the renewal requires human intervention.) You will have a nicer experience if your DNS provider lets you make DNS updates from software via an API, and you can find Certbot integration for that API.
I have tried the command:
certbot certonly --cert-name www.mydomain.com -d *.mydomain.com
but get the error:
e[31mClient with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.e[0m
That's probably because your original cert has an authentication plugin which uses the http-01 challenge configured.
I think you should get the wildcard cert without specifying the previous cert with --cert-name. You'll get a new certificate, but that doesn't matter. Then, re-configure your webserver to use the new wildcard certificate. After that you may choose to remove the old www certificate.
Also, please be aware that your current commands, as said earlier, won't include the apex or "base" domain mydomain.com and as such, your cert won't be valid for that hostname. You should specify the apex domain too by adding a second -d option with that hostname.
Here you'll need to specify an authenticator (like apache or nginx or webroot -w /path/to/your/webroot or standalone) and an installer (like apache or nginx or null for none):
certbot run --cert-name mydomain.com -a authenticator -d "mydomain.com,www.mydomain.com,sub1.mydomain.com,sub2.mydomain.com,..." -i installer --keep
Here you'll need need to specify a DNS authenticator (DNS plugin or manual as schoen was mentioning above) and an installer (like apache or nginx or null for none):
certbot run --cert-name mydomain.com -a authenticator -d "mydomain.com,*.mydomain.com" -i installer --keep
There are more complex mechanisms (like using various "hooks"), but the commands above usually suffice for most people.
You can override that by explicitly adding --manual, although I think @Osiris's suggestion not to reuse the same --cert-name also makes sense here.
In the commands I gave I actually did specify a --cert-name for a very good reason. It enables knowing exactly under which certificate name the active certificate resides, which allows the use of certbot certificates to discover the names of all the cruft certificates and certbot delete --cert-name name to properly delete them in order to prevent massive headaches when certbot renew attempts to renew the cruft. The only problem I could foresee is if the specified --cert-name has other parameters tied to it. It is for this exact reason that I suggested the addition of a clear command here.
Unfortunately, I don’t have easy access to the DNS server, just have access to the server where are installed the sites. And as I understood to request a wildcard certificate, I need to have access to the DNS server, right?
So, for now I will create a certificate for the main domain and for the 2 subdomains.
Thanks,
Rui
Correct, you need to be able to add (and remove) TXT resource records.
Then use the first command I gave you and you should be fine. 