Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'd say that load balancers (one-address-to-N-servers) count as a common practice, but I otherwise agree in that regard.

Regarding wildcard certs, eh. I wouldn't say they have a bad reputation. Sure, greater blast radius. But sometimes it can certainly simplify things to use one. Your ACME client configuration is easier and your TLS terminator configuration often becomes easier when the terminator would otherwise need to switch based on SNI.





one-address-to-N-servers is perfect if the N servers don't all terminate TLS. If not, it becomes impossible to actually test what certificates are actually served. I've seen this fail before (TLS tests flip/flop between good/bad between checks).

As for wildcard certs, I agree there are use cases where we really need them like dynamic subdomains {customer}.status.com

Can you share how they make ACME client configuration easier?


> Can you share how they make ACME client configuration easier?

It's not a profound difference, but you don't need to add each name to your config. Depending on the team's tooling and processes, that may be inconsequential. But in a setting where config management isn't handled super well, where the TLS terminator is a resource shared by multiple, distinct teams, this is a simplification that can make a difference at the margin.

Think less Cloudflare-scale, and more SMB scale (especially in a Windows shop or recovering Windows shop with a different kind of technical culture than what we might all be implicitly imagining).


I'm working on something that could help: linking sslboard with software that's making issuance and distribution of certs easier, ie. a proper CLM. It's not cloud based for security reasons. In that context, we know your wildcard certs because we issue them, and we could know where they are if we distribute them... Please get in touch with me (chris@sslboard.com) if you're interested in early access and having a word in the development of the product!

I didn't realize you were behind SSLBoard. I think you should've disclaimed that involvement at the beginning. I see now that it's in your bio, but disclaiming is still on you.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: