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

Fortunately that’s only needed if you’re using the DNS validation method — necessary if you’re getting wildcards (but…eek, wildcards). For HTTP-01, no DNS changes are needed unless you want to add CAA records to block out other CAs.



Wildcard Certificates are your friend if you don't want all of your hostnames becoming public knowledge.


You're not wrong: there's definitely evidence, for instance, of savvy attackers watching the CT logs for things like newly-instantiated WordPress servers and then attacking them before the admins have set the initial password on them. (Which is really a WP problem, but I digress.) So there's benefit in not having the internals of your infrastructure writ large in public CT logs.

My problem is with the selected solution: wildcard certificates are a huge compromise waiting to happen. They give an attacker the ability to impersonate _anything_ in my infrastructure for as long as the cert is valid (and even a week is _long_ time for that). Worse, if I'm then distributing the wildcard to everything on my internal network that needs to do anything over HTTPS, that's a lot of potential attack points. (If it's just one TLS-terminating bastion host that's very tightly secured, then...maybe. _Maybe_. But it almost never stays that way.)

To me, it's a much better security tradeoff to accept the hostname problem (or run my own CA internally for stuff that doesn't need a public cert) and avoid wildcards entirely.


Having tried it myself, I can highly recommend a security posture that doesn't depend on the secrecy of any particular URL :)


Ah yes, that old chestnut again. Because there's only ever one way to secure anything, and defense in depth is apparently meaningless. Comments like this are not helpful.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: