I’m curious what the benefits are of paying for SSL certificates vs using a free provider such as letsencrypt.
What exactly are you trusting a cert provider with and what are the security implications? What attack vectors do you open yourself up to when trusting a certificate authority with your websites’ certificates?
In what way could it benefit security and/or privacy to utilize a paid service?
And finally, which paid SSL providers are considered trustworthy?
I know Digicert is a big player, but their prices are insane. Comodo seems like a good affordable option, but is it a trustworthy company?
Not the only use cases, but you’d need a different service if you need/want wildcard certs, certs that are manually installed and managed, or certs with a longer expiration.
Letsencrypt issues wildcard certificates. This is however more complicated to setup.
Whoa, really??? I guess I just assumed nothing changed in the last 5 years. I need to look into that.
I’ve set it up fully automated with traefik and dns challenges.
I’d say they’re actually easier, at least in my experience. Since wildcard certs use DNS-01 verification with an API, you don’t need to deal with exposing port 80 directly to the internet.
Yes, it can be easier. But not every DNS provider allows API access, so you might need to change the provider.
(good luck with that in many enterprise scenarios).
You can get wildcard certs with LetsEncrypt (since 2018): https://community.letsencrypt.org/t/acme-v2-production-environment-wildcards/55578
AFAIK, the only reason not to use Letsencrypt are when you are not able to automate the process to change the certificate.
As the paid certificates are valid for 12 month, you have to change them less often than a letsencrypt certificate.
At work, we pay something like 30-50€ for a certificate for a year. As changing certificates costs, it is more economical to buy a certificate.
But generally, it is best to use letsencrypt when you can automate the process (e.g. with nginx).
As for the question of trust: The process of issuing certificates is done in a way that the certificate authority never has access to your private key. You don’t trust the CA with anything (except your payment data maybe).
you can automate the process (e.g. with nginx).
How does nginx automate that?
The person isn’t talking about automating being difficult for a hosted website. They’re talking about a third party system that doesn’t give you an easy way to automate, just a web gui for uploading a cert. For example, our WAP interface or our on-premise ERP don’t offer a way to automate. Sure, we could probably create code to automate it and run the risk it breaks after a vendor update. It’s easier to pay for a 12 month cert and do it manually.
There’s a certbot addon which uses nginx directly to renew the certificate (so you don’t need to stop the web server to renew). If you install the addon you just use the same certbot commands but with --nginx instead and it will perform the actions without interfering with web server operation.
You just then make sure the cron job to renew also includes --nginx and you’re done.
Oh, that… I think i’m using it but it seems.to expect a response from 80 when all I have there is a redirect to 443.
I thought you meant an nginx plugin.
PSA: All public certificates (private internal certificates won’t be affected) will have a lifetime of only 90 days soon. Google is planning to reduce their lifetime in 2024 but considering that they haven’t given an update on this since early this year, I doubt it will happen this year.
But it will happen soon.
This will be a pain in the ass for my workplace because we primarily use Digicert and manually renewing certificates every 90 days is just impossible for use. We are currently looking into a way to switch to letsencrypt or similar.
You’re right, Google released their vision in 2023, here is what it says regarding lifespan:
a reduction of TLS server authentication subscriber certificate maximum validity from 398 days to 90 days. Reducing certificate lifetime encourages automation and the adoption of practices that will drive the ecosystem away from baroque, time-consuming, and error-prone issuance processes. These changes will allow for faster adoption of emerging security capabilities and best practices, and promote the agility required to transition the ecosystem to quantum-resistant algorithms quickly. Decreasing certificate lifetime will also reduce ecosystem reliance on “broken” revocation checking solutions that cannot fail-closed and, in turn, offer incomplete protection. Additionally, shorter-lived certificates will decrease the impact of unexpected Certificate Transparency Log disqualifications.
The background is that certificate revocation is a broken system and having short lived certificates makes the problem go away. You don’t need to worry about how to tell people that some certificate is bad if it’s only valid for a few days.
Ideally, certificates would only be valid for a few days, it should be automated anyway. This has other downsides as I can imagine, like creation of more traffic. My self signed CA for my home LAN has 4 days as standard, and it works perfectly fine.
Yeah, absolutely!
I actually like the change.
It’s just that it will create a lot of work for us (especially for me and my colleague) short term. I would very much appreciate it if Google actually bothered to give an exact timeline (optimally a few months or a year in advance).
There are more reasons, as LetsEncrypt might be more restrictive on what you can get (for example, you cant get a certificate for an IP address from them). But, as 99.99% of usecases do not require anything like that, go with letsencrypt until you know of a reason not to.
No proper CA should give out a certificate for an IP, that’s a no go by the common rules.
I see why automatically giving them out (like in ACME) would be a bad idea, but other than that, why not? Even https://1.1.1.1 has a DigiCert cert.
So, the web uses a system called chain of trust. There are public keys stored in your system or browser that are used to validate the public keys given to you by various web sites.
Both letsencrypt and traditional SSL providers work because they have keys on your system in the appropriate place so as to deem them trustworthy.
All that to say, you’re always trusting a certificate authority on some level unless you’re doing self signed certificates… And then nobody trusts you.
The main advantage to a paid cert authority is a bit more flexibility and a fancier certificate for your website that also perhaps includes the business name.
Realistically… There’s not much of a benefit for the average website or even small business.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| CA | (SSL) Certificate Authority |
| CF | CloudFlare |
| DNS | Domain Name Service/System |
| HTTP | Hypertext Transfer Protocol, the Web |
| HTTPS | HTTP over SSL |
| IP | Internet Protocol |
| SSL | Secure Sockets Layer, for transparent encryption |
| TLS | Transport Layer Security, supersedes SSL |
| nginx | Popular HTTP server |
9 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.
[Thread #969 for this sub, first seen 12th Sep 2024, 15:05] [FAQ] [Full list] [Contact] [Source code]
Personally, I distrust any ecommerce site that uses any free cert. I see paid cert as a commitment to do honest business, as they need to have some records on the CA.
But for a blog or anythings other than ecommerce is totally fine by me.
Note: It is not about security, nor automation, but a show commitment (i.e. buying a cert), largely psycological.
LetsEncrypt is legit. A downside is that the certs expire after 90 days. However, that also carries an upside in that it limits the damage in case a certificate is compromised. There are procedures by which you can automatically renew/request (I forget whether they allow renewing an existing cert or require a brand new one) LE certs and apply them to your application, but that can be fiddly to configure.
If you’re not comfortable with configuring automatic certificate cycling, a long-term paid cert would be more appropriate.
I didn’t say it isn’t legit nor I distrust automation, but I would like to see anyone operating an online shop paid for a cert to show they are honest and won’t diappear in thin air not delivering. Am I going to get back what I paid, properly not, but a basic DV cert isn’t expensive either for a business.
Would you accept a certificate issued by AWS (Amazon)? Or GCP (Google)? Or azure (Microsoft)? Do you visit websites behind cloudflare with CF issued certs? Because all 4 of those certificates are free. There is no identity validation for signing up for any of them really past having access to some payment form (and I don’t even think all of them do even that). And you could argue between those 4 companies it’s about 80-90% of the traffic on the internet these days.
Paid vs free is not a reliable comparison for trust. If anything, non-automated processes where a random engineer just gets the new cert and then hopefully remembers to delete it has a number of risk factors that doesn’t exist with LE (or other ACME supporting providers).
IMO, sticking to manual processes that are error-prone is a waste of money and not a sign of a honest business.
I don’t believe paid cert can’t use automation to keep certs upto date.
Most paid certs aren’t worth much anyway. Payment and delivery info for DV certs isn’t validated by anyone, it’s literally the same concept as Let’s Encrypt. OV and EV are the only ones that theoretically have any value, but nobody is using those ever since they got rid of the URL bar labeling; even Amazon is on DV nowadays.
Let’s Encrypt is just as secure as paid certs. They’re held to the same security standard.
