32

I often use a random ingress eg. jhjhtdf76753.example.com, working away quietly developing code on this subdomain for months, never creating a public DNS entry for the subdomain.

The example.com domain points to our load balancer and nginx domain controller. The ingress logs are quiet except for my activity.

If I generate a LetsEncrypt certificate for this "new" domain, the hackers arrive in force, kiddie scripts and all.

What's up with that?

Improve this question
11
  • 23
    Yes, issuing of new certificates is traceable (unless you use your own CA). Let's Encrypt like other CAs submits new certificates to public Certificate Transparency logs which can be queried by anybody.
    – Ja1024
    Commented Oct 6 at 12:12
  • 1
    *never creating a public DNS entry for the subdomain. Yes. It appears the logs are surveilled or streamed to add as new targets. I'm going to do a test to see how long it actually takes.
    – ophthal
    Commented Oct 6 at 14:35
  • 1
    You can click on the padlock logo, next to example.com > More information > View certificates. You'll see the subdomains.
    – Eric Duminil
    Commented Oct 7 at 20:00
  • 2
    @EricDuminil The fact is your comment is wrong, exactly by following your instructions on this site. The certificate does not list all stackexchange.com subdomains by the use of wildcards, so OP should use wildcards.
    – user71659
    Commented Oct 8 at 19:02
  • 4
    @Criggie: Let's Encrypt does issue wildcard certificates (for free). It's right in their FAQ.
    – Ja1024
    Commented Oct 9 at 10:40

2 Answers 2

Reset to default
50

New certificates end up in certificate transparency logs which are visible to the public. This can be used to detect seemingly hidden domains, which are not linked from somewhere, might not be even publicly reachable but still have a publicly issued certificate. For example you can simple use crt.sh to search the public logs.

Improve this answer
6
  • 39
    A potential workaround is to generate a wildcard cert, that way you can get a cert without revealing the full hostname.
    – Peter Green
    Commented Oct 6 at 23:45
  • 6
    @PeterGreen Though for the security of the rest of the system, it may be appropriate to do that on a dedicated domain or subdomain rather than on a domain which has other non-test uses.
    – jcaron
    Commented Oct 7 at 9:59
  • 3
    @jcaron for private certs you can set up your own cert authority and have its root cert added to each machine on your network (and potentially the few parties that need to talk to those private servers outside your network).
    – jwenting
    Commented Oct 7 at 10:03
  • @jwenting I believe Peter Green was talking about a wildcard public cert (issued by LE for instance). If it's a cert issued by one's own CA then there are no issues with CT, and no need for a wildcard (though it may be useful for other reasons).
    – jcaron
    Commented Oct 7 at 10:06
  • 3
    @jcaron possibly. I meant that with a private cert authority for internal use there's no risk of the (sub)domains becoming public through the cert authority. With a wildcard cert part of the domain name is still public. E.g. if I get a wildcard cert for *.testserver.mycompany.com the world knows I have machines on that subdomain and can just do a brute force DNS attack to find them.
    – jwenting
    Commented Oct 7 at 13:49
3

As previous already stated, certificate transparency logs provide a list of domains for which the certificates are provided. If you use these domains only for internal purposes, I would suggest to run you own CA that is set up to be trusted on all machines accessing these domains. This can impose some security risks, such as that someone who can get access to your CA's private keys could generate certificates trusted by your client machines.

As a simple workaround, wildcard certificates can be used. But this means that you will have to use the certificate for all your servers – and I assume that you create the temporary domains because you want to use different certificates for them.

And also note that a “random” identifiers, especially in domain names which are often transferred in clear-text over the Internet (in DNS, SNI etc.) is not a real security measure. Consider setting up proper authentication scheme for the service. For development purposes, HTTP Basic auth is frequently the best choice, since it can be handled by many webservers and reverse proxies and it is therefore transparent for your app.

Improve this answer
1
  • 1
    You make an excellent point in the last paragraph. Using cryptic subdomains and hoping they'll stay private isn't a good approach in the first place.
    – Ja1024
    Commented Oct 9 at 10:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .