[castillar76]

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.

[elric]

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

[castillar76]

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.

[12_throw_away]

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

[elric]

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.