Because if your one wildcard cert gets compromised somehow, the attacker can now impersonate every subdomain of yours. Consider what happens if there's an old test box called daves-test-box.example.com that has a copy of the wildcard cert valid for *.example.com. Dave quits and never updates his box. Eventually an unpatched CVE gets used to steal the cert. Now the attacker can phish or MitM your users of www.example.com using the stolen cert and browsers will trust it. If you'd instead of wilcard certs used specific ones, then the only thing the attacker can do with it is MitM or phish the users of Dave's test box, which is approximately zero.
There are certainly other strategies and best practices that can mitigate the risk in this scenario, but not using wildcards is a good one to include.
It depends on the system design. If I have an organization like Google, with many employees, *.google.com would be a horrible cert.
That's not every organization.
I maintain many groups of /related/ servers (including dynamic ones which appear and disappear at whim). There, a wildcard makes a lot of sense. If I have https://[username].[domain]/, https://[git project].[domain]/, https://[client].[domain]/ or similar, that integrates nicely with a lot of security infrastructure in ways which http://[domain]/client/ don't.
E.g. A network can filter https based on domains, but can't look inside the envelope. A browser will highlight domains to users who want to know where they are. Etc.
There are also many good reasons why managing one credential per server (which can map to many domains) is better practice than managing a dizzying array of credentials.
So I agree about the general best practice, but there are exceptions. Mandating (as opposed to recommending / encouraging) non-universal best practices is usually bad practice.
Yes, I could not agree more. I've been in both the dynamic servers and the dizzying array situations and those are absolutely good reasons to use a wildcard. I worked for a company that white-labelled services so every customer had a vanity subdomain, and managing certs because an utter nightmare until we finally just bought a wildcard.
Recommending encouraging non-wildcard certs is the optimal strategy. Only thing I would add, is recommending default to non-wildcard and evaluate deviations case by case.
I don't think you realize the ammount or scrutiny and approvals required to allow an exployee to use a sub on the main domain in corp..
A very very.. very limited ammount or people can do DNS changes for the main domain with a crap ton of signatures and eyes monitoring the whole thing.
Dave can test his stuff on a newly bought domain for testing or the internal domains.
They were proposed here as an alternative to domain-restricted sub-CAs, but GP and me have given counterexamples as to why they're not (or at least not without downsides).
You're arguing against a strawman (an argument that nobody is making).
> No one is saying wildcard certificates should be mandatory.
Nor am I saying they shouldn't ever be used.
You may interpret it differently, but to me:
> Why? As I understand it, the domain owner can assign the name you “trust” to any server already. Might as well trust all names by that domain owner.
Essentially means "default to a wildcard." My example is absolutely a good reason why you should not default to a wildcard. There are situations where they make good sense. I use them myself. It's a terrible idea to use them everywhere and always, which is usually what ends up happening when wildcard certs are the default approach.
As with most things, it's a tradeoff of security vs convenience/usability. The CIA Triad comes to mind. I advocate for using separate domains for dev, staging, and prod (at least prod vs. non-prod) and for a wildcard cert for a non-prod domain, the convenience far outweighs the security risk IMHO.
But yeah generally speaking, it's best to avoid wildcards unless there's an actual benefit to using them, even when it's not a prod domain.
A cert for .test.domain seems reasonable, for example, especially if the test infrastructure is dynamic, and you e.g. have CI/CD for a Cartesian product of:
A server allowed to hold preview.example.com (and its associated DNS records) cannot pass dns-01 for *.example.com. Unless you have no authz on your DNS configuration, in which case this server is allowed to hold prod.example.com since it can edit that record.
I know, but what I mean is that just getting a wildcard cert and handing it to all servers that need it comes with some tradeoffs, as does requesting a single-host cert publicly for each host (mainly that I need to talk to a CA, which needs to be available, and it'll publicly log a possibly internal-only, preview etc. hostname).
Having domain-constrained sub-CA certificates granted by the exact same mechanism we use for wildcard certs today would combine the advantages of both.
The main point of DNS-01 is that it doesn't have to be the same machine requesting the cert and using it. You can easily use DNS-01 from your laptop to get a cert for prod boxes. I have a script that runs as a k8s cron job that uses DNS-01 to renew all the certs and stick them in k8s secrets automatically.
Just because I trust a server to hold the cert for preview.example.com doesn’t mean I’d want it to be able to pose as prod.example.com, for example.