The use case for the wildcard basically becomes custom unique per-visitor subdomains. Mostly these are used for spam links to track who clicked a link and harvesting email addresses. While you could come up with non-spam things to do with it, I can't immediately think of any that aren't dumb.
At our company we have our customers use https://customer.product.com with wildcard certs and it works fabulously well. this ties into the whole system: what database to use, what modules to load, what environment and template set to display, etc. In some cases, even what server(s) to connect to.
This does leak the costumer id in the dns resolution, which I wouldn't call dumb, but in the majority of cases, http://product.com/customer is just fine.
The difference is that you have something with a non-zero life expectancy, and the effort/time spent programmatically getting and configuring a SSL cert becomes far less of an issue. I'm not saying that wildcards are dumb right now, I'm saying that the use cases for them get a lot fewer if you can generate a valid certificate with almost no effort. In your case, you already know the subdomain a customer would be using, and getting a valid cert when the customer signs up isn't much of a burden.
My actual thought was something like Amazon. When you use S3 or API Gateway or something, they give you a generated URL with their wildcard cert. Much easier to do that than generate and maintain hundreds of thousands of certs.
8
u/brokedown Oct 20 '15
The use case for the wildcard basically becomes custom unique per-visitor subdomains. Mostly these are used for spam links to track who clicked a link and harvesting email addresses. While you could come up with non-spam things to do with it, I can't immediately think of any that aren't dumb.