Throwing shade if you’re a “platform” using a wildcard for all the things
Wildcard certs are awesome (RFC6125). They allow you to easily use HTTPS/SSL on any number of subdomains, meaning your all your development subdomain endpoints can use a bare minimum of in-transit encryption without having to worry about cert provisioning via Let’s Encrypt et al.
Unfortunately, there is a dark side to wildcard certs — using them in production environments. Particularly production environments on “platforms.”
For example, CMNTY¹ uses the same wildcard cert for their organisation, as well as all of their hundreds (thousands?) of customers that use
I understand the utility (and administrative effectiveness) of using a wildcard certs for for “low value”, “high volume” customers.
So have cake, eat too. Just use a separate cert for your organisation,² i.e. cert-up the bare name
cmnty.com and use it for the “official” organisation.
Could even take things one-step further with a separate cert for your dev/staging resources (
*.dev.<domain>.com), on the off chance they’re publicly accessible for a preview or some such.
This little rant wouldn’t be complete without some props and drops…
Brownie points if you bend it like GitHub and use an EV-cert. Questionable utility for non e-commerce sites, but what can I say, they look cool. How’ bout that “brand statement” on “security.”
 Yal just happened to be the unlucky site I was working with. No bone to pick with CMNTY…yet, working on more complete tear-down (insert: muhaha).
 CMNTY uses
www.cmnty.com as their canonical name. Causes a bit of a problem because the wildcard would cover…meep. At the risk of igniting a flame war on the merits of www vs non-www, suffice to say that unless you want to deal with writing custom ngnix rules, use non-www if you intend to use a wildcard for customers.
 To my surprise, it’s not just the www-folks who wildcard all the things.