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 <customer>.cmnty.com
addresses.
Platform customer using wildcard…could be ok.
Main organisation on same wildcard…erm.
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.”
EV for the win
[1] 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).
[2] CMNTY uses [www.cmnty.com](http://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.
[3] To my surprise, it’s not just the www-folks who wildcard all the things.