Q. If you connect to google.com, how do you know you are talking to google.com, and not bing.com? A. You find the CA of the certificate that google.com send you, and you ask that CA if the certificate is valid.

Q. How do you know that the CA is actually the CA, and not some fake actor? A. You find the CA of the CA, and ask it to validate the certificate of the CA.

Q. How do you know that the CA of the CA is actually the CA of the CA? A. After several layers of this recursion, there is a hardcoded set of trusted certificates on your PC.

If someone self-signs a certificate, then this chain of questions ends well before you end up with a hardcoded (and thus trusted) certificate.

Let’s encrypt verifies that a certificate is created from a specific domain. Therefor it can tell is whether the cert belongs to a domain with certainty.

There’s some great answers already here, but I want to add a detail fir some context. Like others mentioned, Let’s Encrypt does just the bare minimum of verification. They aren’t really verifying that you are who you say you are, they are verifying you control the website. The reason is due to their goal.

They want as many people as possible using a secure Web protocol, and that requires as many people as possible have a certificate for any websites they run. There is minimal verification of identity, but the benefit of encrypted communications and even that bare minimum id is a huge step up in consumer security from old unprotected protocols.

On top of the other points raised here, it’s worth noting that LetsEncrypt is relatively new and until recently had another company higher in the signing chain so that they could provide their certificates without folk having issues with their local cert store.

It’s less about the trustworthiness of the site and more about confirming the site’s identity. Maybe the original is a scam site, but at least you know it’s the original.

You still have to provide some proof that you are who you say you are by publishing a specific webpage on the site that will get the certificate or by publishing a specific DNS record on the domain. Self-signed certs don’t have that requirement so people could make certs for google.com if they wanted to.

Signed by whom? The CA.

The CA is the certificate authority.

You can create your own CA and sign your own certs for free, but people would need to have your CA root cert in their browser for them to be able to trust your signed certs.

Let’s Encrypt is a real CA bundled with browsers, and it signs free cert signing requests when specific criteria is met. This is done because TLS is an important privacy mechanism that works best if many certs are in use and not just a few wildcard certs.

Why not trust self-signed certs? Because there are no checks. When miicrosoft.com (the people who make the miis on your wii) gets a free cert signing from Let’s Encrypt, its because the owner of miicrosoft.com proved that they owned the domain miicrosoft.com by means of a lets encrypt / acme challenge. When you create your own CA and sign your own certs you are beholden to your own rules. You could sign a free cert for microsoft.com (the people who make minecraft) but then you would also need to convince users to install your CA, and then you can steal their blocks and grief their builds.

If you look in the certificate store of your browser there are a number of issuing authorities that the browser will treat as valid source-of-truth providers for SSL certs. If a certificate doesn’t come from one of those, or is expired, or revoked the browser will throw up an alert to let the user know of the problem. Let’s Encrypt is a group created to issue these certs in an automated fashion just like the traditional CAs. Really it’s just a matter of which CAs are acceptable. Some organizations will remove trust for certain entities (Symantec for a while had removed the US Gov from the trusted issuers bundle for their Bluecoat proxies) if they deem an authority as suspect or potentially compromised. There wad also an incident several years ago where a major issuer had sent out an intermediate CA pair that a buisines ended up putting on a proxy that routed a big chunk of public traffic through effectively breaking the user’s encryption. That CA got banished from the common browsers shortly after.

Because of the man in the middle attack.

A self signed certificate could be a fake certificate created to trick you. Let’s Encrypt checks the domain name to make sure the certificate is owned by the domain name at least.

For example, if your Dad decides to run a man in the middle attack with the router to check if you are looking at porn, your Dad only has to issue self signed certificates. When you visit a webpage, he can program the local router to send you to his computer before going to the internet.

Kids Computer -> Dad’s computer -> Real Website.

Dad’s computer will make a self signed cert to interact with your computer, while decrypting the data from the real website. It then reencrypts the data with a self signed cert, that you suddenly decided to accept.

Now your dad / company you are working for knows you are browsing Porn and fires you. This may or may not have been inspired by real life events.

Except it turns out that it was the Bosses / Grandparents who were browsing Porn so nothing happened.

Anyway, Dad’s computer on this network setup cannot get a Let’s Encrypt certificate. The Sysadmins will go around to everyone’s computer or use Windows Group Policy to force the computers of the organization to trust a CA under control of the Sysadmins to get this man in the middle working.