A wildcard cert is an unnecessary risk, though.
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.
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.
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.
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.
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.
Yours is not an argument against wildcard certificates! Yes, like, everything else ever, wildcard certificates can be misused.
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).
> 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.
Dave can test his stuff on a newly bought domain for testing or the internal domains.
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.
every branch
* several test data sets
* several feature flag / configuration sets
* ...
Having domain-constrained sub-CA certificates granted by the exact same mechanism we use for wildcard certs today would combine the advantages of both.