My example domain is: www.*.example.com
Is it possible to have www for wildcard domains with Let's Encrypt?
Hi @Doorway, and welcome to the LE community forum 
No; the wildcard ("*") has to be the leftmost entry.
[a wildcard ("*") in the "middle" of an FQDN isn't allowed]
That said, you can get up to 100 entries in one cert.
And each entry can be a wildcard cert.
So...
You might be able to combine wildcard entries to cover all the names you need to cover - without explicitly naming them.
If you show a more detailed example, we might be able to better address your specific need.
On rethinking...
If you are going to hide:
www.super.secret.name
with:
*.super.secret.name
Then you really haven't hidden that name with a wildcard at all - lol
3 Likes
Is there a way to deny www.* on the DNS level with Bind9?
I'm not sure what the question is here. If you don't want www.*.example.com to resolve just don't put any records in.
1 Like
That's not entirely true or you didn't understand OP: in contrast with certificates, with DNS a wildcard in a zone file can actually take the place of multiple DNS labels. E.g., I can have * IN A 127.0.0.1 in the zonefile for example.com and then not only www.example.com would resolve, but also www.foo.example.com or even www.foo.bar.example.com.
Not sure if this is preventable.
1 Like
The question is unclear.
If a DNS request is made on an FQDN like: www.*.example.com
I'm not sure anything should be returned - unless you actually explicitly create an FQDN as "www.*.example.com" [which is possible in some DNS systems]
For any doubters, check: nslookup www.*.test.beer4.work
If the question is how stop such DNS entries from being created (not likely), just lockdown the bind zone files and paths or the entire server [use a separate system just for DNS].
If the question is about anything else (likely), please clarify the question.
2 Likes
As I said earlier, this is probably not the answer. When you have a single wildcard label in your zone file (e.g. *.example.com.), DNS perfectly accepts multiple labels for that single wildcard label. And AFAIK you can't prevent DNS to not resolve a request with an extra label left of the first "wildcard" match. E.g., you can't prevent www.foo.example.com. being resolved by the zonefile entry *.example.com..
1 Like
This is what I was referring to. How to prevent www.foo.example.com from being resolved when a wildcard is used in the zone record, this way browsers don't show an SSL warning.
Is there a foo?
I think you are confusing a wildcard certificate with a wildcard entry in DNS.
The first doesn't require the second.
If you require a DNS wildcard entry, and also require for some specific names (that would be covered by that wildcard entry) to NOT return any IP...
Then you would need to explicitly add those name exclusions by creating then as empty zones.
3 Likes
The thread has moved from wildcard certificates to wildcard DNS entries indeed.
Although it seems OP still seems to think both things are intertwined, while indeed that is not the case.
3 Likes
I don't think that's possible on the DNS level - you're trying to set a wildcard and prevent a wildcard at the same time.
Exactly what are you trying to accomplish with all this?
3 Likes
OP rather has users see a DNS error than a certificate error due to the fact it's not possible to have a www.* wildcard certificate. Makes somewhat sense: if a user sees a DNS error, they're more likely to think "I must have typed it wrong" or "This site doesn't exist" instead of "This site doesn't have its security in order", which might be something a user would think seeing a certificate error.
3 Likes
unless you have hsts on it, you may able to redirect on such name on http without answering on https so no certificate error
4 Likes
@orangepizza Chrome/Chromium nowadays prefers HTTPS. Not sure what it does when it finds a redirect on HTTP and an incorrect certificate on HTTPS.
2 Likes
Yes, I understood that. But why are they doing that? If they can explain what they are actually trying to accomplish, we may have better solutions.
I can think of a few reasons for wanting to implement an experience like that, and they each have different implementations.
3 Likes
I now remember caddy has something called on-demand TLS, which looks customer request clienthello and ask certificate for that FQDN from ACME server on the fly
4 Likes
Other projects call that "autossl". Utilizing that will address a handful of use cases, but is subject to rate limits. Another option is to use multiple certificates:
Certificate 1 - Desired: www.foo.example.com
Certificate 2 - Desired: www.bar.example.com
Certificate 3 - Failover: *.example.com
It's hard to tell what the OP is actually trying to accomplish, as the options may or may not be scalable to their needs. Describing the actual use case (is the domain level capped? are subdomains finite customers/projects or infinitely scalable nxdomain "typo marketing" options) would help immensely.
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.