Is issuing multiple wildcard certificates for a TLD considered duplicate certificates from the perspective of rate limiting and limited to the 5 certificates per week?
If so, this seems to limit the value of Let’s Encrypt wildcard certificate as an alternative to having to list a bunch of subdomains in certificates.
Hi,
For TLD, do you actually mean domain?? (xxx.xyz as tld??)
You can have up to 100 hostnames per certificate, which can be none, part, all wildcards.
If you really want to use one certificate per subdomain wildcard (aka contain one and only one wildcard domain per certificate, you will hit certificate rate limit soon)
THank you
A reasonable strategy might look like this:
Let’s say you own example.com and wanted to issue, for some strange reason, 6 total wildcard certificates that include *.example.com and example.com without hitting the exact duplicate certificate limit of 5.
The first instinct is just to include an extra name in the certificate, such as:
wildcard-1.example.com
*.example.com
example.com
This will fail, however, because wildcard-1.example.com is an overlap for *.example.com.
What you can do, however, is take advantage of the wildcard depth-matching of 1 property to overcome this.
Request 6 certificates with names as such:
Cert #1:
a.wildcard.example.com
*.example.com
example.com
Cert #2:
b.wildcard.example.com
*.example.com
example.com
Cert #3:
c.wildcard.example.com
*.example.com
example.com
Cert #4:
d.wildcard.example.com
*.example.com
example.com
Cert #5:
e.wildcard.example.com
*.example.com
example.com
Cert #6:
f.wildcard.example.com
*.example.com
example.com
You could then, for example, take those 6 certificates and key-pairs and utilize them on any number of servers/services for the duration of their validity period.
Commonly, many systems do something similar to this (though usually with only 2 or 3 certificates total):
Use Certificate #1 on all my servers.
Immediately deploy Certificate #2 across all non-compromised systems if Certificate #1 should be revoked or key compromised.
The reason to issue multiple wildcard certificates is having many servers each hosting one or more distinct sub-domains. Wildcard would be more convenient for quickly turning around new sub-domains. And, it would be more secure to generate distinct certificates (private keys) at each server rather than sharing a certificate that, if compromised, would compromise all the servers.
Your idea is very clever, hadn’t thought of that because the extra domain in the cert didn’t seem necessary, but great approach to have distinct certificates. And, that extra domain could be a machine hostname for direct administrative access.
I like it!
Fail in what way? Fail to issue or fail to evade rate limit? I'm sure the former is possible, having issued such a certificate previously.
I'd read that Boulder refused to issue certificates with overlapping names like that, but I just got one from staging...
Certificate Name: letsencrypt.mattnordhoff.info-0001
Domains: *.letsencrypt.mattnordhoff.info redundant.letsencrypt.mattnordhoff.info
Expiry Date: 2018-06-18 00:28:38+00:00 (INVALID: TEST_CERT)
Edit the third: Blocking overlapping names is a recent change. It was temporarily deployed to staging, there was a bug (users got the wrong error message), the bug was fixed, but currently it's disabled.
Huh, thanks. Lucky I saw this thread now, this is a very breaking change for me 
.
Should it perhaps go to API Announcements? There are some environments (like control panels) where I imagine this might come up often, especially if the behavior is kinda undocumented.
I think an API announcement post is a good idea. I'll put one together shortly.
We also mentioned this in the API announcement post for V2 in the "Wildcard certificates" section:
Orders that contain both a base domain and its wildcard equivalent (e.g. *.example.com and example.com) are valid. In that case, there will be two authorization objects in the order for “example.com68”, one of which represents the wildcard validation and one of which represents the base domain validation. Redundant entries will produce an error. For instance, and order containing both *.example.com and www.example.com would produce an error since the wildcard entry makes the latter redundant.
There was a lot of text to process there and we didn't land the change in time to enforce at launch so I can definitely see how this would get missed.
As promised:
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.