Comment by csense
5 days ago
To get a Let's Encrypt wildcard cert, I ended up running my own DNS server with dnsmasq and delegating the _acme-challenge subdomain to it.
Pasting a challenge string once and letting its continued presence prove continued ownership of a domain is a great step forward. But I agree with others that there is absolutely no reason to expose account numbers; it should be a random ID associated with the account in Let's Encrypt's database.
As a workaround, you should probably make a new account for each domain.
Your account ID is exposed in the certificate generated; what's the real difference?
The ACME account URI does not appear in issued certificates. X.509 certs contain the subject, issuer, SANs, validity period, SCTs, etc., but no ACME account identifier. You can verify this by inspecting any Let's Encrypt certificate. What CT logs do reveal is which CA issued certs for which domain(s), and multi-domain certs group SANs together, so some correlation is possible. But the account URI itself is not exposed — dns-persist-01 records in DNS would be a new exposure surface for that identifier. That's a real tradeoff, which is why the draft supports using separate accounts per domain if isolation matters to you.
You bothered to manage your LE accounts? I only say because when using the other two challenge types with most deployment scenarios you were generating a new account per cert so your account ID was just a string of random numbers.