Subdomain certificates

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

3 Likes

Hi @Rui

these are your options:

  • one certificate per subdomain -> 7 certificates
  • one certificate with all domain names -> 1 certificate, used with all subdomains
  • one wildcard certificate

See

PS: There are some rate limits, but 7 subdomains aren't a problem.

6 Likes

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.

4 Likes

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

2 Likes

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.

3 Likes

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

2 Likes

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.

3 Likes

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.

1 Like

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.

2 Likes

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.

1 Like

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

1 Like

Correct, you need to be able to add (and remove) TXT resource records.

1 Like

Then use the first command I gave you and you should be fine. :slightly_smiling_face: