| ▲ | z3t4 2 days ago |
| At some stage you need to update your TXT records, and if you register a wildcard domain you have to do it twice for the same request! And you have to propagate these TXT records twice to all your DNS servers, and wait for some third party like google dns to request the TXT record. And it all has to be done within a minute in order to not time out. DNS servers are not made to change records from one second to another and rely heavily on caching, so I'm lucky that I run my own DNS servers, but good luck doing this if you are using something like a anycast DNS service. |
|
| ▲ | Arnavion 2 days ago | parent | next [-] |
| You can have multiple TXT records for the same domain identifier, and the ACME server will look through all of them to find the one that it expects. So for an order that requests SANs example.org and *.example.org, where the server asks for two authorizations to be completed for _acme-challenge.example.org, you can create both TXT records at the same time. https://datatracker.ietf.org/doc/html/rfc8555#section-8.4 >2. Query for TXT *records* for the validation domain name >3. Verify that the contents of *one of the TXT records* match the digest value (Emphasis mine.) |
|
| ▲ | castillar76 2 days ago | parent | prev | next [-] |
| 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 2 days ago | parent [-] | | Wildcard Certificates are your friend if you don't want all of your hostnames becoming public knowledge. | | |
| ▲ | castillar76 20 hours ago | parent | next [-] | | 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 2 days ago | parent | prev [-] | | Having tried it myself, I can highly recommend a security posture that doesn't depend on the secrecy of any particular URL :) | | |
| ▲ | elric a day ago | parent [-] | | 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. |
|
|
|
|
| ▲ | 2 days ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | XorNot 2 days ago | parent | prev [-] |
| Or just use the HTTP protocol, which works fine. |
| |
