This doesn’t replace the expensive certificates, it’s an alternative when you’re just shooting for encryption. There is very little verification of who you are. This will help create a more secure internet, but does not verify that the server you’re connecting to is necessarily the bank you intended to contact. The Expensive certificates provide verification that the server is who it says it is. In order to get one you have to verify lots of things, and the high cost is part of the verification. That’s why there are different levels of certificates, depending on how important it is to verify the servers identity.
In a way, creating a free certificate, with little verification, they have created a market for higher level certificates, in order to differentiate oneself from the free ones.
I see Lets Encrypt as an alternative to self-signed certificates, which are PERFECTLY SAFE, but browsers hate them. Now I/You/We can easily generate a certificate for small projects without a budget/time to get a “real” certificate, and still have a trusted certificate. I will be issuing 4-5 the first day i get my hands on it.
EDIT: I want to add, i’m not saying these certs are unsafe or anything. It seems like there is a decent system in place to prevent malicious use. but it’s just not the same as a $100+ EV certificate. If you’re going to be accepting credit cards, and users don’t have any special reason to trust you (church/community website), you should probably have a better cert, or offload your card collection to a trusted entity (payment processor).
(Many) more expensive certs do indeed verify the identity of the requester more thoroughly, but I don’t really thing normal people open the certificate detail view to see if the organization name is listed or not.
EV certs show the organization name directly in/near the address bar, but there’s really no way of knowing whether the site “should have” an EV cert or not…
Self-signed certs may provide the same crypto, but if the attacker can also generate an identical-looking (for the user) certificate, real world security is greatly reduced.
I do agree that for-pay cert providers will probably be fine for a long time, providing additional support etc; but — to me — the “added security” of expensive certs seems to be 99% marketing, with no real benefits.
And the other certificates (a normal one-domain cert and SAN certs) are also offered by Let’s Encrypt.
And they are not really cheap BTW too there: The cheapest one costs $66.
The only thing they offer is a ‘Warranty coverage of up to $10 Million’, but I don’t really now what they have to cover there. Nearly every HTTPS issue is caused by bad server config so I doubt they extend warranty for this.
Besides this the only benefit for IdenTrust are a few backlinks and a bit advertising (I mean their logo and their name mentioned at several places of Let’s Encrypt), but I don’t think that outweighs all the disadvantages.
So to conclude this: I have no idea why IdenTrust does this.
So they are supporting this project as a sponsor and to cross-sign. Seems like they are just being nice, or maybe they have a vested interest in the tools that LE are developing.
I understand that IdenTrust’s root cert(s) is/are currently recognized by most (all) major Web browsers.
If I understand it correctly, IdenTrust will cross-sign LE’s root cert.
Imagine a future where 60-70% of all ‘small’ business and ‘hobby’ Web sites show up with a LE-cert, which indirectly is certified by IdenTrust. (Using an end-user’s way of seeing it, since I’m far from expert on the subject.)
Wouldn’t that strengthen IdenTrust’s position as a leader amongst the CA’s recognized by most Web browsers? If ‘yes’, then I guess this could long term strengthen their market position as a whole.
If I’ve understood something incorrectly in my assumptions above, I’d much appreciate any corrections with explanations.
Self-signed certificates are safe if you install them in every browser used to access the site. Otherwise, they are next to useless. So, basically, they can only be used safely for internal sites, VPNs, etc.
Let’s Encrypt is run by ISRG, a not-for-profit organization. We have an ongoing need for additional sponsors and donations. If you think or know of an organization that thinks that our services are making the Internet better and safer, we’d be glad to have your support.
Well... a thing you miss is that also Let's Encrypts own root cert will be shipped with all major browsers, so after this date IdenTrusts cross-signature is not important anymore. (except for some old clients maybe)
Yeah, @Jeroen based on all of your posts, you’re well inside the target audience of Let’s Encrypt. Just tell the client to issue a single certificate for all, some, or one of your domains, and repeat until you’re all covered
The point of expensive certs is they do a better job of verifying your company. When we purchased a Intel vPro cert from GoDaddy it was a lot of work getting them all the paperwork to verify our company was who we said it was and they would only speak to the contacts on the domain at the numbers/emails/addresses specified in the contact information. Business licenses and everything had to be provided.
So there definitely is a very big peace of mind advantage to a company going through that kind of process especially if it’s a bank or some other site with extremely sensitive data.
@digitalfiz, I agree that different certificate authorities perform, and claim to perform, different kinds and amounts of verification.
But as other people have described, many uses of certificates experience a weakest-link phenomenon. HTTPS client software accepts any kind of cert from any CA. So the question @joel is pointing to is to what extent users will check what kind of verification a particular entity was subject to. If they don’t check, directly or indirectly, it’s not clear that they got whatever benefits were to be had from the greater verification, especially since if an impostor could get another cert from a different CA, those users might accept it just as readily as they accept the genuine one.
To put @joel’s point another way, the extra verification is meant to benefit the relying party, the person who accepts the certificate. If it’s extremely rare for relying parties to check this information, or act on it, or become aware of it, how much benefit did it actually get them? It didn’t improve the cryptographic protection of their information, and in many scenarios it wasn’t even likely to prevent an attack based on some other CA misissuing a certificate.
New technologies to address misissuance, like CAA, CT, and HPKP, are applicable to DV certificates too: a site that uses a cheap CA that performs less verification can take the same precautions against other CAs doing the wrong thing as a site that uses an expensive CA that performs more verification.
@rugk, CAA is a protocol to say which CA may issue certificates for a particular subject DNS name.
It can be checked either at the time of issuance by the CA, or at the time of acceptance by a client, or by researchers who are searching the Internet for potentially misissued certificates. It’s one of several technologies that could increase the chance that misissued certificates are detected. The others that I mentioned are
Ah so DAA is quite similar to DANE...
The difference just seems to be that it is a check on the CA side and not the client side...
And as the Wikipedia article is not really large here I found a nice explanation of it:
Certificate Authority Authorization (CAA, RFC 6844)
is intended to reduce the risk of unintended SSL/TLS certificate
mis-issuance, either by malicious actors or by honest mistake. The goal
is to allow a DNS domain name holder to specify the certificate
authority or authorities that the owner has authorized to issue SSL/TLS
certificates for that domain.
For example, if you own example.com,
and wish to express your preference that certificates for that domain
should only be issued by Primary CA, Inc., you would create a record in
DNS indicating such. If a malicious actor, or an employee who is not
aware of your preference, engages a different CA, Secondary CA, Inc. to
purchase a certificate, Secondary CA might first check in DNS. If they
see that you have a CAA record that does not specify Secondary CA as a
preferred certificate authority, Secondary CA could alert you of that.
You could then choose to deny the certificate purchase, or change or add
to DNS your preference to allow Secondary CA to issue certificates for
your domain.
For this reason, we recommend use of the CAA record.
– Rick Andrews, Senior Technical Director for Trust Services, Symantec.com
I haven't heard of any CA supporting CAA, but Let's Encrypt is going to support this?