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?
as many said, getting more than 90 days validity for certs that are harder to rotate, or the automation hasn’t been done.
higher rate limits for issuing and renewing certs, you can ask letsencrypt to up limits, but you can still hit them.
you can get certs for things other than web sites, ie code signing.
The only thing that matters to most people is that they don’t get cert errors going to/using a web site, or installing software. Any CA that is in the browsers, OS and various language trust stores is the same to that effect.
The rules for inclusion in the browsers trust stores are strict (many of the Linux distros and language trust stores just use the Mozilla cert set), which is where the trust comes from.
Which CA provider you choose doesn’t change your potential attack surface. The question on attack surface seems like it might come from lacking understanding of how certs and signing work.
A cert has 2 parts public cert and private key, CAs sign your sites public cert with their private key, they never have or need your private key. Public certs can be used to verify something was signed by the private key. Public certs can be used to encrypt data such that only the private key can decrypt it.
OP’s security concern is valid. Different CAs may differ in the challenges used to verify you to be the domain owner. Using something that you could crack may lead to an attacker’s public key being certified instead.
This could for example be the case with HTTPS verification (place a file with a specific content accessible through your URL) if the website has lacking input sanitization and/or creates files with the user’s input at an unfortunate location that collides with the challenge.
This attack vector might be far-fetched, but there can certainly be differences between different signing authorities.
But even if you use GoMommy extra super duper triple snake oil security checked ssl cert, if I trick LetsEncrypt to sign a key for that domain I still have a valid cert for your site.
Also all let’s encrypt certs are public. So if someone malicious gets a cert for your domain, you can notice.
(Thats also why it may be a bad idea to use that for secretButPublicStuff.Yourdomain.com certificate transparency logs are a great way to find attack surface.)
edit oh certificate pinning has been deprecated in favor of checking transparency logs.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
The main benefits to paying for certs are
The only thing that matters to most people is that they don’t get cert errors going to/using a web site, or installing software. Any CA that is in the browsers, OS and various language trust stores is the same to that effect.
The rules for inclusion in the browsers trust stores are strict (many of the Linux distros and language trust stores just use the Mozilla cert set), which is where the trust comes from.
Which CA provider you choose doesn’t change your potential attack surface. The question on attack surface seems like it might come from lacking understanding of how certs and signing work.
A cert has 2 parts public cert and private key, CAs sign your sites public cert with their private key, they never have or need your private key. Public certs can be used to verify something was signed by the private key. Public certs can be used to encrypt data such that only the private key can decrypt it.
OP’s security concern is valid. Different CAs may differ in the challenges used to verify you to be the domain owner. Using something that you could crack may lead to an attacker’s public key being certified instead.
This could for example be the case with HTTPS verification (place a file with a specific content accessible through your URL) if the website has lacking input sanitization and/or creates files with the user’s input at an unfortunate location that collides with the challenge.
This attack vector might be far-fetched, but there can certainly be differences between different signing authorities.
But even if you use GoMommy extra super duper triple snake oil security checked ssl cert, if I trick LetsEncrypt to sign a key for that domain I still have a valid cert for your site.
Certificate pinning?
Also all let’s encrypt certs are public. So if someone malicious gets a cert for your domain, you can notice.
(Thats also why it may be a bad idea to use that for secretButPublicStuff.Yourdomain.com certificate transparency logs are a great way to find attack surface.)
edit oh certificate pinning has been deprecated in favor of checking transparency logs.
You’re right, my bad.