2 ms·
Yes, this is a downside of certificate transparency. Also, using Let’s Encrypt certs for internal hosts, as some do for convenience, means you’re publishing you
by wrs 2y ago
Yes, this is a downside of certificate transparency. Also, using Let’s Encrypt certs for internal hosts, as some do for convenience, means you’re publishing your internal hostnames. Use an internal CA if that worries you.
- singron 2y agoIf you care, you can use a wildcard cert. E.g. instead of getting a cert for foo.example.com, get one for *.foo.example.com, and then use an obscure subdomain. AFAIK, nobody is bruteforcing subdomains on wildcard certs.
- bradtheappguy 2y agoThey are
- thwarted 2y agoAre they brute forcing them, or are they relying on the fact that most users of wildcard certs also have wildcard DNS entries, so it's just that everything is actually available. Wildcard DNS pointing to a web server with a wildcard cert will pass through to the web server, and at that point the web server responds with a 404 if the host header isn't one configured for virtual hosts.
- ffsm8 2y agoDidn't the wildcard cert still need the alt-names specifying the host for the browser to accept the certificate as fully valid? I remember being annoyed by warnings until I added them a decade ago while playing around with a private CA at a previous job
- dilyevsky 2y agoYes, /cn is deprecated. But letsencrypt adds your wildcard into subjAltNames as well and it works great.
- kstrauser 2y agoGreat point. This was no big deal for me today. I was prepared for it. I mainly posted this to warn others: if you put a server online, it will be attacked, and it's going to be way sooner than you would have believed. You can't get away with, "yeah, I know I left some extra files laying around, but I'll clean them up and lock everything down as soon as I'm finished with the setup." Nope. That's not an option.