It's probably more attributed to browsers marking non-https as 'Not Secure' than anything but LetsEncrypt definitely has had a substantial impact to make that change possible.
I ran into a local store taking credit cards awhile back, no TLS, weird, so I go to the store owner in person. I explain the problem and he insists that can't be the case, he's mad at me. "See! It's got a lock on the website!"... on the homepage. I direct him to the store and now it says Not Secure.
That did more to explain the situation than my attempt at TLS and HTTPS and Certs. He was able to call his web guy and say "It says not secure, Jerry! Fix it".
It was such a simple addition to (at least in Firefox) use the words Not Secure that it's crazy no one thought of it before.
You're right, but didn't have to. This guy when he could get past being mad at me knew that was against the rules. Also even if it was allowed, no one wants to shop at a place that says Not Secure.
Side topic, but I've been trying to explain to our terrible CFO for years that PCI / PCI DSS is a real thing. He thinks that's the type of regulation that only giant companies have to deal with.
Feel free to report your org to your merchant processor if necessary if you're not meeting compliance requirements and think you can get away with it without compromising yourself.
Even if it says "secure", that doesn't mean it really is. I worked at a place in the 90's that hosted a some sites taking credit cards through HTTPS. You know what they did? They sent emails, in clear text, to people at the store that would enter / process the cards manually.
did you check the url the form submits to for https? it was a somewhat common pattern once upon a time to load the form in http but submit it in https. not great, but better than nothing (nobody should do this nowadays btw).
Doesn't matter though, the reality for him was that customers saw a Not Secure and that was a problem. All the crypto, certs, forms, probability of issue, technical things didn't matter, just the perception.
The whole reason we started tracking HTTPS vs HTTP was because of LetsEncrypt. Love that they broke the need to pay ridiculously overpriced fees to generate certs.
I'd imagine that a lot of this is attributable to Firesheep calling attention to how anyone on a public Wi-Fi network could snoop on your Facebook traffic.
Most of the major websites fast-tracked HTTPS shortly after that.
There was a link a month or two back that showed Let's Encrypt is used by 30% of domains but if this is by volume of data not domain share then it'd be a lot less than 30%.
It is amazing how HTTPSEverywhere has revealed how incompetent people are regarding TLS/SSL.
I can't count the number of times I've seen the extension page during sign-ups or logins. Oracle Cloud just triggered it the other day during signup and initial login. Most times when I email, asking why an email marketing link, or an embedded token-login email link sends me through an HTTP URL, the person on the other ends tells me they don't know and that's unexpected, or a result of out-sourcing their marketing/email/whatever.
In one case, their marketing mail provider supposedly just blanket intercepted all links and unknown-to-their-customers passed them through an HTTP redirect. Stunningly unprofessional.
Is a LetsEncrypt certificate "just as secure" as other certs? I have to imagine the answer is "no" simply because LetsEncrypt is free and the other certs aren't -- what more do you get by paying for a cert?
It used to be you paid because everyone who was trusted by browser manufacturers charged a fee, not because signing a certificate is actually hard or could be done in a "non secure" way. A signature is a signature.
LetsEncrypt signatures are now trusted by the browsers, so there's usually no need to pay for the service.
Thing is, even if LetsEncrypt were less secure (I don't really think it is, but lets assume), that would hurt the security of every website.
If you use a paid CA, someone trying to impersonate you could still go to lets-encrypt and get a certificate there. In other words, the system is only ever as secure as its weakest link. It doesn't matter what link you chose, it matters what link a potential attacker would use.
All of this is because failure of a CA only means false certificates are issued. Its not like lets encrypt ever could get access to any of your private key material.
Nothing of value, but there usually is some (silly, IMO) justification, such as badges and warranty (practically useless). Funnily, Comodo starts its list of key features with "value" [0]. They also seem more expensive now than I remember them to be (hundreds of USD per certificate/year), and still call both X.509 and TLS "SSL".
Sometimes I hear about people just looking for "SSL certificates" because somebody told them that they should have one, and search engines would lead them to those websites; probably that's how it still works.
So for my personal projects, I use lets encrypt. As far as I know (and I could be wrong now, haven't checked in a while) - their certs are only good for 3 months. Which is simple enough to get around - run a script on your box that updates the cert every 90 days automatically.
At work, we use a paid certificate that is good for a longer period of time (normally a year). So that's one benefit to paying, I suppose.
As far as encryption technologies and security, the traffic encrypted by a lets encrypt cert is just as secure as the traffic secured by a paid-for CA signed cert.
The fact that Let's Encrypt certificates expire quickly is a feature, not anything to do with paid vs. non-paid.
Let's Encrypt could have just as easily generated certificates good for a year or more. But the point of Let's Encrypt is to force you to do this in an automated way, using scripts like you suggest.
You're not getting around anything. The choice was by design.
I am sad that this question is down-voted. It seems honest enough, it's slightly off-topic but not dramatically so.
There are two halves to the first answer but they're both "Yes, Let's Encrypt is just as secure".
1. Most elements of TLS security have nothing whatsoever to do with certificates. This is easier to grasp in TLS 1.3 than earlier versions (all the encryption in TLS 1.3 is working before anybody sends any certificates anywhere) but it has always been true.
Even without certificates eavesdroppers can't see what was communicated, and nobody can change it en route between client and server. For these things even no certificate at all would be fine...
Certificates do add a vital thing though: Identity. A certificate from Let's Encrypt is a signed document from Let's Encrypt vouching for the identity of your site. Cryptography (with a "private key") lets you prove this certificate belongs to you and nobody else can do that. Without Identity somebody in a position to be an eavesdropper could just pretend to be you and intercept everything (a "Man in the Middle"). So even though it's a small aspect it's vital.
2. To go around issuing people with Certificates you need some way to know who is who. Until a few years ago there weren't many hard and fast rules about how to do this, and so a lot of rather dubious procedures were used by people who charged a pretty penny. Some of them would argue that charging validated the purchaser but that's not so smart, plenty of crooks are willing to spend money to make more.
So, Let's Encrypt actually helped write actual formal rules for how you can make sure you're issuing certificates to the real owners of the names they're certificates for. These are known as the Ten Blessed Methods, because there were once exactly ten of them and each is a method that the certificate issuer is allowed to use to do this Domain Validation. None of them are utterly foolproof, and there is ongoing work to further improve them or get rid of the least effective ones, but at least now there are written rules.
Having helped write these rules it should be no surprise that though they represent a significant tightening up of things for some of the incumbent for-profit issuers, Let's Encrypt was already doing everything required.
Partly this is actually helped by not taking money for certificates. Since Let's Encrypt doesn't make a profit from giving you a certificate, they've no incentive to do so unless they're sure.
Now: For the second part, I have written lengthy answers elsewhere, there are a lot of reasons you might pay somebody money. None of these reasons make Let's Encrypt any worse, and many of them are real niche cases, you'd know about it if you've hit those. Like if you make web sites for Nintendo's obsolete WiiU video game console - Let's Encrypt doesn't help you because the WiiU web browser doesn't have the right trust store for that. Or if you need S/MIME certificates for your corporate email system for some reason, Let's Encrypt don't offer that. If you need a special relationship with your issuer under contract (like Facebook has) then Let's Encrypt can't help you. And so on. For most people it doesn't matter.
