Dev rant: Stop abusing wildcard certs

Written by rmharrison | Published 2017/09/20
Tech Story Tags: ssl | https | security | ssl-certificate | rant

TLDRvia the TL;DR App

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 <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…

Props

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

Drops³

Footnotes

[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.

[4] For more on Auth0.


Published by HackerNoon on 2017/09/20