What is the difference between a SAN cert and a Wildcard cert?

I’m confused by what I’ve been reading regarding the new wildcard cert soon to be offered. How is it different from a SAN cert? For example, if I have two bindings for www.domain.com and domain.com right now I use a SAN and bind each domain name via SNI to that cert. What is different about a wildcard cert in that scenario?

Secondly, why is it only going to use DNS-01 validation? Those of us on hosted sites that don’t have (easy) access to our DNS settings are kind of hosed. Is there a technical reason why it can’t use HTTP-01 as well? Or am I just not educated enough to know the right question to ask (LOL)?

2 Likes

SAN certs are for a finite number of explicitly enumerated domains (not necessarily the same base domain, example.com, www.example.com, and othersite.com all can go on the same certificate for instance), whereas a wildcard is for any set of domains on a single base, like *.example.com, which will be valid for anything replacing the star. The star does not have to be the first subdomain layer either, *.blue.red.example.com is also a wildcard, with the same rules.

3 Likes

A wildcard certificate is considerably more powerful and risky because it can apply to an unlimited number of other sites. The idea of limiting it to DNS-01 has something to do with DNS-01 showing the most direct power to administer the DNS for a site, which is a kind of power and responsibility that someone responsible "for a domain as a whole" as opposed to someone responsible "for an individual site" would be more likely to have. For example, people who run individual web sites at a university should be able to receive certificates covering their individual sites (which they can do with HTTP-01 or TLS-SNI-01), but not receive wildcard certificates covering any site within that university domain.

3 Likes

There's a clever work around for folks in this situation as well. Often you can add a CNAME record for _acme-challenge.YOURDOMAIN.TLD. that delegates responsibility to a DNS provider that has easier programmatic access. This can be done once at your existing DNS provider and then you can use hooks to automate the DNS-01 challenges for the delegated DNS provider that handles the _acme-challenge lookups. (Though maybe when you say that you don't have easy access to DNS settings that also prevents being able to set a one-off CNAME... If so, apologies!)

A community member wrote a special purpose DNS server for doing the delegated lookups: GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely. This has the added advantage of keeping your ACME client from having access to updating all of your DNS records and instead limits it to those required for the challenges.

2 Likes

The risk of using wildcard certs can be limited by issuing them for specific subdomains, and designing your DNS naming conventions to group systems by security profiles into those subdomains.

For example, instead of issuing a cert for “*.example.net”, you can issue one for “*.www.gslb.example.net”. This wildcard will not apply to example.net, test.example.net, or citrix.gslb.example.net, but it will apply to host17.www.gslb.example.net.

If you have 30 identical boxes that are all clones of each other, then putting them in their own subdomains and sharing a wildcard cert among them – and no other hosts – makes controlling the risk easy.

1 Like

Another risk of wildcards certificates is "virtual host confusion attacks":

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.