Let's Encrypt is an initiative from the Electronic Frontier Foundation (EFF), Mozilla, Cisco, Akamai, IdenTrust, and researchers at the University of Michigan that aims to automatically provide every domain owner with a recognized certificate that can be used for TLS.

In order to prove that you own a domain, you need to install a file with particular (randomly generated) contents at a particular (randomly generated) URL on that domain. The Let's Encrypt server will verify this by accessing the URL, before signing the certificate.

Now, suppose I have some attack which will make the domain awesomebank.example resolve to my server. Suppose I can also MITM some peoples' connections to https://awesomebank.example/. TLS is intended to prevent me from seeing or altering their communications to the server without being detected.

What prevents me from using this attack on the Let's Encrypt server, and obtaining a certificate for awesomebank.example, and then using it to MITM customers of AwesomeBank without being detected (because I have a valid certificate)? Doesn't the existence of a fully automated CA make the Internet less secure?

2023 edit: this has happened. Somebody has MITMed a server, at the server, and got a TLS certificate for that server.

  • 12
    "...some attack which will make the domain awesomebank.example resolve to my server". This is called DNS poisoning. Once you achieve this, why would you perform MITM. All the customer's data is coming to your server. It is game over then. But you can't pull this off easily unless you convince the DNS registrar of awesomebank.example to resolve it to your IP or you exploit a vulnerability in their DNS infrastructure. Even that can be mitigated through DNS change locking.
    – void_in
    Commented May 4, 2015 at 8:06
  • 23
    Many existing CAs are already automated. They only check if you can receive emails to [email protected]. Commented May 4, 2015 at 8:08
  • 2
    Even DNS (cache) poisoning only works if the cache is used. If the resolver is designed to specifically follow the delegation chain on each lookup, and perhaps even do so for all alternatives and make sure that the responses match, this attack can be mitigated easily to a high degree of confidence. Since certificate signing is a relatively low-frequency operation, something like that would not significantly affect other systems nor significantly increase the time required to get a certificate.
    – user
    Commented May 4, 2015 at 8:54
  • 3
    This is a flaw with this entire CA-based PKI. Alternative solutions like using a web of trust instead (like PGP) would be more resistant to this type of attack, because you'd need to fool multiple people into trusting your MITM identity, as opposed to a single CA.
    – user42178
    Commented May 4, 2015 at 12:42
  • 5
    @void_in "All the customer's data is coming to your server" would only be the case if the clients actually establish the TLS connection to your server. For that to work, you (normally) need to have a valid (signed by trusted CA) certificate for the domain name. And to get that you need to trick the CA during the verification process.
    – resistor
    Commented May 4, 2015 at 20:53

7 Answers 7


Same security as other DV certs

What prevents me from using this attack on the Let's Encrypt server, and obtaining a certificate for awesomebank.example, and then using it to MITM customers of AwesomeBank without being detected (because I have a valid certificate)?

Nothing. If you own the network, then you own the network. And DV type certs (see below) rely on the network for proof of domain ownership. There are usually no out-of-band checks. (Nobody will call your phone, nobody will check your photo ID, nobody will visit you at the place the company is registered to, etc.)

Doesn't the existence of a fully automated CA make the Internet less secure?

Nope. Same level of security as DV type certs.

There are (currently) three assurance levels for x509 certs:

  • DV, Domain Validation
  • OV, Organization Validation
  • EV, Extended Validation

DV is the cheapest. It basically means "If somebody can answer an email to [email protected], then that person gets a certificate for example.com".

There are additional checks for OV, EV.

More info about cert types: GlobalSign.com: What are the different types of SSL Certificates? (Archived here.) Wikipedia: https://en.wikipedia.org/wiki/Public_key_certificate#Validation_levels And a lot more background info in these slides here: RSAConference2017, Session ID: PDAC-W10, Kirk Hall, 100% Encrypted Web -- New Challenges for TLS

Further reading

  • 2
    Note that the e-mail check, while common, is not the only automated check in use. In particular, many existing CAs give the option of exactly the same web-based proof that Lets Encrypt describe in their docs.
    – IMSoP
    Commented May 4, 2015 at 13:29
  • Yes. I've just never come across anything but the e-mail version in the wild. Commented May 4, 2015 at 14:00
  • 5
    Working in a web dev agency, I was heartily relieved when Comodo started offering DNS and HTTP verification, because it means we no longer have to explain the process to the non-technical staff who have access to the admin@ e-mail account. Or, worse, to the IT staff who need to create such an inbox especially for the purpose.
    – IMSoP
    Commented May 4, 2015 at 14:21
  • While DV and EV are industry standards (standardized by the CA/Browser Forum), as far as I know OV is GlobalSign only. For example both DigiCert digicert.com/ssl-certificate.htm, and Entrust entrust.net/ssl-certificates.htm offer EV and a bunch of their own variants (but not OV). Commented May 4, 2015 at 17:54
  • @MikeOunsworth While not standardised, I think the broad concept of OV as a step between DV and EV is fairly common; see e.g. Comodo's knowledgebase.
    – IMSoP
    Commented May 6, 2015 at 8:05

Yes, the protocol you describe only ensures that "the person who picks up the phone at awesome bank" when you call them, is the same person who picked up the phone at awesome bank when the Let's Encrypt server called them. If I have the ability to intercept calls to awesome bank both from Let's Encrypt and from you, then I can fool you.

Ideally what you'd want TLS to tell you, is that "the person who picks up the phone at awesome bank" when you call them is actually an employee of awesome bank. But this is difficult to automate, since computers can't just figure out who someone works for, so better-validated certificates cost more. Let's Encrypt isn't doing anything less secure than other CAs do already.

One hopes that Let's Encrypt will try to make it more difficult to intercept their calls to awesome bank, than it is to intercept yours. Some internet access points are easier to mess with than others (unsecure wireless scores low), and messing with multiple access points simultaneously is harder than just one (so perhaps Let's Encrypt will confirm that it receives the same file when it downloads it from many different places in the world, although I haven't looked whether they consider that necessary). With the exception of organisations like the NSA, MITM attacks in practice tend to be localised and temporary.

So, it will provide some measure of security only to the extent that it's harder to MITM Let's Encrypt than it is to MITM you. We suppose that it's easier to control your access to the internet than it is to control either that of Let's Encrypt or that of awesome bank, and that's why you "trust" Let's Encrypt as a CA.

Naturally none of this is really phone calls, it's inbound socket connections.

  • You could ensure that "the person who picks up the phone at AwesomeBank" is actually using AwesomeBank's phone, if DNSSEC was used. Commented May 5, 2015 at 3:31
  • 2
    @immibis: well, you can be "sure" you have the right IP address using DNSSEC. Your routing could still be hijacked. DNNSEC also allows for reliable CERT records, but I'm not up to date on what that wins you. Commented May 5, 2015 at 11:51
  • it happened Commented Oct 21, 2023 at 9:56

Let's Encrypt is designed to help against a range of attacks and to push the generalization of TLS usage to have a globally safer and more private internet. It is aimed more precisely to remove technical and financial constraints which may prevent some webmaster to use TLS certificates more broadly.

However, as any security measure, this will not be a miracle product solving all possible securities issues and allowing you to stamp your website as "100% secure website!" (even if some websites do not hesitate to use such stamps...). Security implies the combination of several layers, each one designed to address their own class of threats.

If one really manage to take ownership of your domain name, then most chances are that the fact that the Let'sEncrypt certificate delivery is automated will not have more impact in this case than in another situation.

As a reminder, all you need to get a cert from classical CA is to own an administrative address like "[email protected]" and pay some money. If you manage to get the domain ownership, then you are free to redirect the email to a mail server of your own, thus effectively owning the email address of your choice too.

This is not a theoretical threat. You will find here and article written by someone whose domain has been stolen in order to take ownership of his email. In this precise case it was in order to access the password reset emails sent from third-party societies, however in his position the attacker would as well been able to generate new certs for this domain and build a phishing site which will be considered secured by the browsers.

  • 1
    You would not only need to poison the cache of the CA DNS resolver (whether it is Let'sEncrypt resolving your website address or another CA resolving your mail server address does not matter here), but you would also need to poison the cache of each and every visitors you want to redirect to your phishing site when they go to the https://awesomebank.example URL (otherwise having the cert will be useless if you cannot impersonate the website). Might be doable to some extent as a part of a very targeted attack, but remains clearly limited and not doable at a large scale. Commented May 4, 2015 at 9:25
  • 2
    If MITMing a website was so difficult, then surely we wouldn't need TLS to prevent it? Commented May 4, 2015 at 9:32
  • 2
    If we were only concerned about eavesdropping, browsers would accept self-signed certificates. Commented May 4, 2015 at 21:35
  • 2
    @immibis: Self-signed certificates only protect against passive MITM attacks. An active MITM attacker can create a self-signed certificate.
    – Brian
    Commented May 5, 2015 at 13:21
  • 2
    @user54609: An active MiTM attacker only gets one chance (per certificate) to compromise Let's Encrypt, and must do so by compromising connection to Let's Encrypt (which is signed by a trusted CA). With a self-signed certificate, every connection is vulnerable to active MITM attack.
    – Brian
    Commented May 6, 2015 at 7:39

The use of an automated check is not unique to this CA, but is common for entry-level certificates. As stated in other answers, there are 3 levels of certificate in use:

  • Doman Validation proves only that you had control of the domain at the time the certificate was issued. (And that the certificate hasn't been explicitly revoked since then.)
  • Organisation Validation involves an extra check that the company name listed in the certificate is valid.
  • Extended Validation includes a much stronger audit of the company applying for the certificate.

For a basic DV certificate (and as the first step in OV and EV applications), most CAs will use some form of automated "Domain Control Validation". For instance, Comodo offers 3 options:

  1. An e-mail must be received by one of a short list of generic addresses at the domain, such as "admin@", on the assumption that only authorised staff would have access to these mailboxes.
  2. A specific CNAME record must be added in the DNS zone for the domain, proving that the applicant has DNS control.
  3. A URL must be added with specific content in the root of the domain's HTTP, proving that the applicant has control of the web server pointed at by the domain.

The ACME protocol being developed as part of the Lets Encrypt effort is to automate the client side of this check. Their Technology Overview actually mentions both the DNS-based and HTTP-based checks as examples which could be automated in this way.

The idea is that the software you install can automatically determine how to meet these challenges based on the configuration it has access to. If it can find and write to the Document Root of the domain to be validated, then the HTTP-based challenge is very easy to automate. The more traditional e-mail based validation method would be trickier to automate, due to the complexities of mail delivery, but doesn't actually differ in the amount of proof it provides.


The primary defense against MITM attacks during issuance is to perform the validation check -- observing the server or its DNS -- from many geographically dispersed locations. This is how many CAs today operate for automated web checks to detect forgery and fraud.

From what I heard in the IRC room, Let's Encrypt will be doing the same for all of the validation checks.

  • It does not help if MITM is near your server (if only single route is available).
    – Maxim
    Commented Feb 5, 2017 at 23:46
  • @Maxim indeed Commented Oct 21, 2023 at 9:58

Remember you need to MITM not the users of the site, but Let Encrypts validation servers to be able to get that certificate, its going to be much harder.

Lets Encrypt has recently talked about how they use Multi-perspective validation to help protect themselves against such an attack - the idea being that they will validate your ownership of the domain from different places in the internet, such that you would need to MITM multiple data centers around the world.

In this case I think Lets Encrypt is more secure than other certificate providers that are not going to such lengths to protect themselves. This is nothing unique to Lets Encrypt - if you can MITM the certificate provider, you can use any of them, it just might be more expensive for you.

  • Well, some certificate providers do attempt to verify your real-world identity. Not so much since LE started existing. Commented Sep 3, 2020 at 11:22
  • 1
    For EV certificates they should do this, but for DVs that Lets Encrypt give you, other providers are similar and tend also to be automatic, but in a less structured way that ACME protocol.
    – mcfedr
    Commented Sep 3, 2020 at 11:28

To get practical on this in 2020 - I ran the following test with SSL labs https://www.ssllabs.com/ssltest/analyze.html?d=certbot.eff.org and they report eff.org (a site which enables you to integrate LetsEncrypt with your server) as A+ - this is their highest level available. So as long as you setup your server correctly it is possible to achieve the same results as for paid certificates.

From my understanding self-signed certificates offer the same level of encryption as CA signed its just that people recognise the authority. With LetsEncrypt they've become a recognised authority with the browsers hence how they can operate.

Furthermore they have a 90 day limit which means that in the event your keys are hacked they are issued more regularly. As this is done automatically it shouldn't be as painful as normal renewals!

  • That just shows that SSL Labs trusts LetsEncrypt. It doesn't really show why LetsEncrypt is trustworthy. Commented Sep 15, 2020 at 10:49

You must log in to answer this question.

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