Let's Encrypt Hits New Milestone: Over 100,000,000 Certificates Issued (letsencrypt.org)

Josh Aas, the executive director of Internet Security Research Group (ISRG) writing for Let's Encrypt: Let's Encrypt, a free, automated, and open certificate authority has reached a milestone: we've now issued more than 100,000,000 certificates. This number reflects at least a few things: First, it illustrates the strong demand for our services. We'd like to thank all of the sysadmins, web developers, and everyone else managing servers for prioritizing protecting your visitors with HTTPS. Second, it illustrates our ability to scale. I'm incredibly proud of the work our engineering teams have done to make this volume of issuance possible. I'm also very grateful to our operational partners, including IdenTrust, Akamai, and Sumo Logic. Third, it illustrates the power of automated certificate management. If getting and managing certificates from Let's Encrypt always required manual steps there is simply no way we'd be able to serve as many sites as we do. The total number of certificates we've issued is an interesting number, but it doesn't reflect much about tangible progress towards our primary goal: a 100% HTTPS Web.

Comments

Value?

[Frosty Piss]

I'm not sure that one of these certs is any better than a self-signed cert...

Re:Value?

[Qzukk]

It's trusted by the browser by default, so it has that going for it.

Also, unlike self-signed certs it demonstrates that the person requesting the cert has control over the hostname(s), which is pretty much all I ever had to do when I paid for a non-EV certificate.

Re:Value?

[Anonymous Coward]

It's considerably better than a self-signed cert. Browsers don't accept self-signed certs by default, throwing up big nasty warnings. Lets Encrypt is a fully-accepted CA.

It also costs as much as a self-signed cert. That is, nothing. Higher utility at the same price is higher value.

Re:Value?

[Opportunist]

It demonstrates that the one holding the cert also holds the domain name. Nothing else. And nothing else is implied by the whole deal.

Contrary to popular belief, a certificate isn't a government ID. All it means is that whoever claims to be www.whatever.tld is actually www.whatever.tld, and that no man in the middle attack is happening.

And once people learn this, we could maybe start establishing some sort of security. The fact that https:/// isn't crossed out by your browser doesn't mean that www.bank0famrika.com is a good place to enter your online banking credentials.

Re:Value?

[Anonymous Coward]

Im not that poster but I do have to look after a lot of servers with sites that have letsencryprt certs.

Basically it requires the same level of domain validation as any standard, non EV cert (including revocations) and provides the same level of protection for on the wire data interception with the disadvantage that certs are only issues for 90 days instead of 1+ years.

Look here for a overview of the the process, its pretty simple and the same as any other non EV cert:
https://letsencrypt.org/how-it-works/

Re:Value?

[AikonMGB]

This isn't about the basics of PKI it's the basics of establishing TRUST that's the heart of my question regarding LE.

The basis of any secure system is TRUST not alphabet soups of cryptographic jargon. It's asking the basic question "WHY SHOULD I TRUST YOU?" and receiving a reasonable, verifiable response.

Trust whom, the site owner? LE? Their CA? If you don't trust root CA, then you are SOL. Better unplug your computer. Otherwise, there's your trust chain: root CA vets LE to a level sufficient to grant them an issuing certificate, LE vets the site owner to a level sufficient to grant them a hostname certificate.

How does LE vet ownership to even assign certificates in the first place?

Ownership of what, the hostname? The client requesting the certificate has to satisfy a challenge, for example placing a file with specific contents at a specific location controlled by the hostname, or populating a specific DNS record with a specific value for that hostname's zone. If the client is able to satisfy those challenges, then it already has complete control over the hostname and the content it serves.

What makes this process secure and trustworthy? If there is no good answer to that question all the cryptography in the world means nothing.

If you aren't willing to engage in a discussion about public keys and cryptographic signatures, there's no way to answer this question for you. The cryptography is how the process is secured, and the public key nature (combined with satisfying the challenge above) is how the CA establishes trust.

Re:Value?

[GameboyRMH]

I agree with you, but I think browsers should treat HTTPS connections with self-signed certs the same as HTTP connections, as in not halting the connection with a giant warning page and forcing the user to jump through hoops before getting to the site. Let them through with the same little warning symbol now displayed for an HTTP connection. An HTTPS connection with a self-signed cert is in no way more dangerous than an HTTP connection.

Re:Value?

[Junta]

The point being you connect to http, and no worries, it's all cool. It's warm and fuzzy and not at all something to fret about.

You connect to https with self-signed cert, *IT'S THE END OF THE WORLD*, you are horribly insecure, it's dangerous, you shouldn't even *try* to talk to the server, if you really want to you should click through 2 or 3 dialogs, and also you should be forced to do that every time you reconnect to the same server, without even a hint of whether the certificate changed from last time.

It's just such a strange disconnect. I have seen web server operators opt to prefer http rather than https so as not to scare off users, even if they may be handling potentially sensitive information.

Self-signed certs should be treated more like ssh keys in general.

Re:Value?

[dissy]

Also, unlike self-signed certs it demonstrates that the person requesting the cert has control over the hostname(s), which is pretty much all I ever had to do when I paid for a non-EV certificate.

How does it demonstrate that?

Because one must create a file under a name specified by LE, with contents specified by LE.
Only one with control over the webhost has access to create files on the webhost.

Can you explain specifically what makes this better than self-signed certs?

Anyone can create and sign a self-signed certificate with any domain(s) in it they wish.
You can not easily verify the website owner is the creator of the private key, and in fact the only one way to do so is to compare the certificate signature/hash you see with the website owner, which requires another form of secure out-of-band communications.

With LetsEncrypt, you personally for example can not issue a certificate for my domain.
I personally can not issue a certificate for your domain.

Additionally with self signed certificates, you would need to have end-users install your self signed public key in their browsers manually, and to actually be secure it would have to actually be the one you generated.
As an attacker I can provide my own public key to your users to trust, with your domain in it, and there is little chance they wouldn't know it was my key instead of yours.

Certificate Authorities have their public keys in the browser already.

What is the basis of trust used to establish ownership?

Access to a web servers files or DNS zone for the domain in question is required.
This is the exact same identical process any other CA in the world uses for class-1 certificates.
In other words, if you know how any CA handles class-1 certs, you know how LE handles them. It is identical.

What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?

What prevents a person with control over the domain from requesting a certificate for that domain?
The exact same thing that prevents an attacker from getting a certificate from any CA issued for that domain - nothing.

If I was an attacker in that position to have control over a victims web host or DNS, I could get a certificate issued from Lets Encrypt, or GoDaddy, or ICANN, or any of the many hundreds of certificate authorities out there.

Re:Value?

[tattood]

The way that you get a cert issued by LE is the same as with any other CA company. So if some bad guy can register any domain, and put up a website, they can purchase a cert that is trusted by your browser. How can you TRUST that this website is not bad, just because their certificate was issued by GoDaddy, or some other CA?

The CA is not verifying that you are not doing anything bad, just that you control the web server. The same is true for LetsEncrypt certificates.

Re:My certs expire every 30 days...

[ls671]

No! It expires every 90 days and you can renew after 60 days. RTFM.

Re:My certs expire every 30 days...

[__aaclcg7560]

No! It expires every 90 days and you can renew after 60 days. RTFM.

I stand corrected. After double checking my configuration, I have a different set of certs (five or so) expiring and renewing each month.

Why so many negative comments?

[fabriciom]

This thing is the best thing since sliced bread. I use it on all my servers, it saves me money and head aches.

Re:Wonder...

[CrashNBrn]

Good Riddance. About time we get rid of the gouging "middle-man" to protect us from the man-in-the-middle-attacks.