Certificate issued without domain holder permission

#1

I own a domain. Let encrypt has issued an ssl certificate without my permission on the domain. Is there anything I can do to control this?

#2

Can you provide more information, like your domain and hosting environment?

It was probably issued by your control panel or hosting company or something.

Is your domain a target of spies or cryptocurrency criminals?

You could try revoking the certificate and setting CAA DNS records to stop Let’s Encrypt from issuing more (which will not help if someone is hijacking your DNS).

Can you guess who might have done it?

If you provide your domain or other information, Let’s Encrypt staff might respond to this thread with more. You could also email them, probably at cert-prob-reports@letsencrypt.org.

#3

Hi @mnewnham

which nameserver do you use?

There are some free nameservers. If there is a main domain example.com registered, everybody can create own subdomains myname.example.com.

PS: Next step, these users create a certificate myname.example.com. Result: The domain owner can’t create a certificate because the 50 certificates limit / week is hitted.

#4

On this forum we’ve seen this happen especially often with people using the afraid.org name server.

#5

I apologize, I should have expanded my original posting. This isn’t a situation where the domain has been stolen or misused, its more a situation of notifications and authority:

The domain is in use with permission, and the site is being run on my behalf by another person. That person has the rights to use the root level domain. I however control the DNS and the uses of the domain, for example, whilst they can run the www server, they cannot, for example , create a mail service with the same domain. There would be no reason that, if they has asked, I would have obtained an SSL certificate.

My understanding, perhaps misguided, was that only the owner of a domain could obtain an SSL certificate for that domain. This is to prevent misuse by third parties. The person who runs the site/obtained the SSL certificate has no access to the ownership of the domain.

#6

Anybody that can prove control of the domain.

For Let’s Encrypt, that can be done using DNS or an http challenge, so if that person can respond anything to http requests on port 80 he can generate a certificate, but only for that domain (not for subdomain)

#7

To add some more clarity.
The word “Domain” is used synonymously with FQDN.
[But may be confused with the “base/root Domain”]

In order to get a cert for an FQDN, one need only have control of the site(http) at that FQDN.
In order to get a cert for the “base/root domain”, one would have to control the site(http) at that root domain.
In all cases, when one controls the DNS zone, then one can get a cert for any name from that domain (to include wildcard certs).

#8

I hope this is a typo because if someone is running a website on your behalf, you really should allow them to secure it with HTTPS!

However, if you really want to, as long as you have exclusive control of the DNS settings, you can prevent them getting a cert or (better) restrict them to using the certificate authority of your choice, by using a CAA record as mnordhoff mentioned above.

#9

Again, it is simply a matter of authority and responsibility. I’m not disagreeing at all that the site should be secured, but from a paperwork perspective, there is no audit trail on who acquired the certificate and when. If, heaven forbid, you announce next year that there is a problem with the certificate (see Symantec), there is no record that the site was secured with the product, because the person who acquired it had no authority to do such a thing (from an internal business perspective, not your rules of acquisition).

#10

There were plans for an expansion of the CAA record semantics to allow specifying a particular validation method and/or ACME account, so that you could for example retain the ability to issue a certificate yourself, but prevent the person running your website from doing so. Unfortunately it got stuck on some ambiguity in the relevant RFC and I’m not aware of it having progressed since then (though I’d love to be wrong about that).

I suppose you could keep a CAA record in place most of the time, and remove it temporarily while issuing a certificate; meanwhile monitoring the Certificate Transparency logs for any unexpected issuance which, as the domain owner, you can always forcibly revoke.

#11

This post was flagged by the community and is temporarily hidden.

#12

This is a good point in the sense that certificate issuance used to involve a lot more paperwork than it does now. In fact, you could say that Let’s Encrypt exists to help reduce the amount of paperwork involved with certificate issuance and to try to completely automate the process, taking human beings out of the loop.

To compensate for this, we do have technologies like Certificate Transparency and Certificate Authority Authorization, which you can use to monitor certificate issuance for subdomains of your domain, as well as to set policies about issuance under your domain. We hope to have more fine-grained forms of the latter in the future so that these policies can get more specific. You can also sign up for monitoring services that let you know about certificate issuance and expiry status.

There’s no way that we could proactively check with domain registrants before issuance certificates because we don’t have any reliable and automated way to do so. But where protocols exist to give you more visibility and control within an automated system, we’ve tried to adopt them, and we’ll presumably try to keep adopting others in the future. As other people have pointed out, our practices have been consistent with industry rules—but the fact that administrators of devices pointed to by subdomains can issue certificates directly might be much more obvious now that they don’t have to pay for those certificates! (E-mailing a contact from the whois database, for example, is only one method of several that have been used for domain control verification for many years.)