What prevents an attacker from registering a TLS certificate for an existing site?

Question

This would be used in a phishing attack for example - coffee shop attack where google.com becomes a website controlled by the attacker completed with the magic lock next to the URL. Can I use letsencrypt to create a valid cert for any website that browsers will trust?

Answer 1

What prevents an attacker from registering a TLS certificate for an existing site?

Certificates are issued by Certificate Authorities (CA's), which are inherently trusted by the major web browsers. The job of the CA is to prevent exactly what you describe in your question. They do this by validating that you own/control the domain that you are asking them to issue the certificate for. This is often done by way of Domain Validation. Typically, it requires the domain owner to do one of the following:

• Publish a string provided by the CA at a URL at the site for the domain
• Click a verification link sent to an administrative email address for the domain
• Publish a string provided by the CA in the domain's DNS

It is very much in the interests of CA's to perform this validation procedure accurately, in order to prevent issuing certificates to attackers who do not in fact own/control the domain that they are requesting a certificate for. If a CA issues a certificate to an attacker, users may no longer trust this CA, and browser could take the step of revoking their trust in this CA as well. This is what happened with DigiNotar in 2011.

Answer 2

In addition to the DV checks described by mti2935, and some higher validations of the requester that can be done -- commonly OV Organization Validation and EV Extended Validation -- but are not so popular nowadays(*), which have remained largely the same since the CA system (aka PKI) was first envisioned, there are two or three significant additions in recent years:

• CAA allows the (legit) domain owner -- more exactly, the DNS adminstrator -- to limit which CA(s) will issue certs. Google in particular has its own CA so it sets CAA to allow only itself to issue certs; even if you can somehow convince LE you control a google domain (which you almost certainly can't) LE still won't issue you a cert for that domain unless you can also change the CAA record.

  If you pick a site to spoof whose legitimate owner does use LE, they can use CAA to require a particular LE account -- which you won't be able to access -- though I suspect not many do this.

• Certificate Transparency works at the other end to promptly detect fraudulent certificates rather than preventing them. Many CAs now, including LE, automatically log all issued certs to publicly-visible logs; this may be done before issuance (using a 'precertificate') or immediately after (or both). Transparency viewers like https://crt.sh allow you to easily find all certs issued for a given domain (or other) name, and if you find one that is not legitimate you can report it to the issuing CA who will revoke it (at least if they follow CABforum rules or any decent policy, and if they don't they won't be trusted anyway).

• DANE uses DNS info directly to help validate certs but is not much used (although you can find some Qs/As about it here and maybe some other Stacks)

(*) in the noughties EV in particular was widely promoted as the way to make ecommerce safe (or safer) and got special preferential treatment in browsers, but also fairly widely criticized as "paying CAs lots extra to do the job they should already be doing"; see Does Google use extended validation certificates?