5 ms·

What's the justification of traditional providers to charge for the certificates? Do they offer services or extended certificates that "Let's encrypt" doesn't o

What's the justification of traditional providers to charge for the certificates? Do they offer services or extended certificates that "Let's encrypt" doesn't or is it just a matter of "no one tried to offer it for free before"?

cyphar 9y ago
Currently their only upside is that they provide wildcard (and EV) certificates. EV certs can't be automated for obvious reasons, but LE doesn't support wildcard certs because they don't believe there's a secure way of providing an automated way of getting them. Given that traditional CA models don't actually have much more security than LE (in fact from personal experience they're far less secure), I wonder whether they should be in the business of providing wildcard certificates at all.
- philliphaydon 9y ago
  Why is providing wildcard certs not secure???? Amazon seems to do it?
  - eropple 9y ago
    Because once your wildcard certificate is compromised--and you must design systems with the assumption that your certificates will be compromised--it becomes a very achievable exercise to use that wildcard certificate to compromise users going to any of your subdomains. With each domain governed under its own TLS certificate, you install firebreaks between systems to contain the damage an attacker can do. There are vanishingly few reasons to ever share private keys across multiple automated systems. This is not one of them. (Are your systems not automated? Fix that.)
    - tokenizerrr 9y ago
      Meanwhile SAN is fine? The alternative to wildcards is that you get a single cert with tons of subdomains as alternative name. Exact same risks, yet much more hassle to add subdomains. I don't see it.
      - eropple 9y ago
        That's a fine point, if you're using SANs. With Let's Encrypt, you don't need to use a SAN so long as each of your endpoints is distinct. (If they're not, I'm uneasy with your architecture in the first place, y'know?) However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists.
        tokenizerrr 9y ago
        SNI is not yet always an option if you have to support older clients. It's not about if I'm using SANs anyway. It's that LE is fine with that, but not with wildcard certs. > However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists. Can you elaborate what you mean here?
        eropple 9y ago
        If you have to support older clients--definitely, SAN is your only option if you have to run on the same host. (And I sympathize, because that sucks.) At that point, though, my inclination becomes to attach a bunch more public IPs and wire up my DNS correctly to match. > Can you elaborate what you mean here? Me saying "this cert is valid for example.com, foo.example.com, and bar.example.com" is an incrementally better security posture than saying "this cert is valid for *.example.com". It constrains an attacker from running a phishing attack from, say, "private.example.com" or "secure.example.com". You're whitelisting what you're covering by explicitly declaring all of them. It is incremental, but it's a thing.
        tokenizerrr 9y ago
        IPv4 addresses are relatively expensive. I encounter it quite often where a wildcard gets pointed to a single server (with single IP) which hosts multiple services. There are no security issues compared to a large SAN that I can see in such a situation.
    - philliphaydon 9y ago
      So the Low risk of compromise for most people is more important than the ability to easily maintain a system? If a certificate is going to be compromised it's most likely going to be the most important cert to the system anyway. A hacker isn't going to go after the meaningless ones. But by your logic I should increase the maintainability of the system for no benefit. Obviously this is highly dependent on the usage of the certs to begin with.
  - cyphar 9y ago
    Yes, many services "seem to do it". The problem is how do you safely verify that a wildcard certificate is actually being given to the owner of that domain space? It's "trivial" to provide a certificate for a particular domain is owned by someone, but the same techniques don't work for wildcard certificates because now you're verifying only a single domain and providing certificates for an entire class of domains. If you work through all of the ways ACME verification works (/.well-known/, DNS, and so on) you can come up with several plausible setups that become insecure if you allow wildcard certificates. Here's a stack exchange question about it: https://security.stackexchange.com/questions/157972/why-cant-lets-encrypt-support-wildcard-certificates https://security.stackexchange.com/questions/157972/why-cant....
    - tokenizerrr 9y ago
      That SO post makes no sense to me. It claims: > The authentication test can't merely back down one level to mysub.example.com because that isn't covered by the cert requested, and may not be under the control of the requesting agent either. This just seems wrong. Performing the check like that seems to be a sane way to do it. If people can't control the base domain they have no business requesting a wildcard cert.
      - cyphar 9y ago
        But *.a.com doesn't cover a.com, so it's not very clear that the inverse ownership relationship should hold. Yes, it's true on a DNS level but that's one argument I would imagine against doing it that way.
        tokenizerrr 9y ago
        No, but ownership of a.com heavily implies ownership of (wildcard).a.com (HN is being weird with the asterisk) Alternatively they could just do a DNS check. If you can configure DNS for a.com, you control *.a.com.
        cyphar 9y ago
- giobox 9y ago
  One annoying thing I've seen less technical stakeholders ask about with letsencrypt is "why the padlock isn't green" in Safari/Edge. Unlike Chrome and I think Firefox, those browsers only display a green padlock for SSL certs with EV, which of course letsencrypt doesn't (and arguably can't really) do. The "grey padlock" for an otherwise perfectly valid certificate seems to confuse a very small subset of users, especially when there's a ton of badly written articles out there advising users only to trust "green padlocks", given the behavior in almost all other browsers. Thankfully showing google.com not using an EV certificate is usually easiest way to shut these conversations down.
  - hueving 9y ago
    What types of users have asked you about that? I'm lucky if I can get regular users not to click their way through cert errors.
    - giobox 9y ago
      Like you I've never seen a "customer" user notice, which is why I was careful to use the word "stakeholder". For me it's almost always been product management/sales types in the company.
  - nlawalker 9y ago
    >> only to trust "green padlocks" It's not so much about browser-specific behavior, it's about using the padlock to ensure that the company or other entity you're interacting with is the one you wanted, as opposed to only ensuring that the server you're talking to is the one indicated in the address bar. A gray padlock is better than none, but telling less technically-inclined, clicks-all-the-links, fat-fingered users to trust them outright may not be the best idea now that you can go get bankofomerica.com, dress it up to look like BoA's site, and put a gray padlock on it for free.
    - giobox 9y ago
      Given how piecemeal the use of EV certs is by big companies, I'm not sure EV as implemented today delivers any 'real' benefits. It absolutely is about browser specific behaviors. How can you tell users only to interact with companies if they have an EV certificate, when huge internet properties like Amazon, Google and Facebook don't use them? In reality you can't, which means Safari/Edge's behavior arguably doesn't really help anyone. I'm not saying Safari/Edge shouldn't tell the user an EV certificate is present, they absolutely should, but that the approaches used by rival browsers arguably make more sense. I think Chrome/Firefox got this one right by using a green padlock for both valid EV _and_ DV certificates like Letsencrypt, displaying the extra EV information clearly inline in the URL bar if it is present. The changing color in Safari/Edge can give the impression that the the non-EV certificate is somehow less secure, which in technical terms is not the case. Questions of identity verification and security of data transmission are two separate issues which the Safari/Edge approach arguably conflates - both EV and DV can provide equal security of transmission, even if only EV provides some degree of identity confirmation. As a user, it's simply not possible to make the distinction too - if I visit your fake Bank Of America site with a grey padlock, how can I even be sure the 'real' site had an EV certificate and a green one, when there's so many companies that don't? As a user you are effectively forced to treat the grey and green padlocks the same, so why not make them the same color and display extra EV info if it is there, like the other browsers?
orf 9y ago
> What's the justification of traditional providers to charge for the certificates They could, so they did.
rmc 9y ago
No-one did free which works in all browsers before.
- collinmanderson 9y ago
  StartSSL worked with any Windows XP SP2+ computer. Though you couldn't automate it and their website was kinda slow.
  - floatboth 9y ago
    And they demanded personal data. Even checked that your personal address is not a business address! "Domain validation" my ass.
josephjrobison 9y ago
Is this total BS then?: "Why pay for something that’s free, you ask? When a user visits a website that is secured with a self-signed, or free SSL certificate, most web browsers will post an error message. While some people will click “I understand the risks” and proceed to your site, it’s likely that many people will click the “Get me out of here!” button and never return. The real problem lies in the fact that self-signed certificates are virtually unregulated. If your site is compromised, it may still appear secure; however, certificates issued by a trusted certificate authority can be revoked and therefore alert users of any potential threats." Source: http://searchengineland.com/comprehensive-guide-ssl-certificates-264377 http://searchengineland.com/comprehensive-guide-ssl-certific...
- MertsA 9y ago
  Sort of, that's conflating all free SSL certs with self signed certs. The whole point of an SSL cert is to provide authentication that the server you're talking to is really the server you were trying to reach at www.example.com . They are talking about self signed certificates which is basically the remote server saying "I'm www.example.com, you can trust me because I said so". Let's Encrypt is the same as other CAs out there in terms of authentication. In fact, if you see a certificate that's signed by Symantec, it's more likely to be mississued than a certificate signed by Let's Encrypt.
- Ajedi32 9y ago
  The certificates Let's Encrypt issues are _not_ self-signed. They are signed by a trusted certificate authority which Let's Encrypt manages, and are no different from domain validated certs signed by any other CA. That article makes the mistake of assuming that if a certificate is free then it _must_ be self-signed, which is obviously false.
jpalomaki 9y ago
Among other things they provide certs which are valid up to three years. Let's Encrypt certs are short term. There idea is to auto renew, but sometimes that is difficult to implement.
tialaramex 9y ago
Just making a certificate costs almost nothing. So in a sense $0 seems like the right price. BUT, being _able_ to make certificates is very expensive. ISRG (the charity behind Let's Encrypt) spends _millions of dollars per year_ on this. Purely mechanically Let's Encrypt needs a data centre with a bunch of high availability servers and pretty good Internet access, employees to look after all that stuff, a deal with CDNs to serve up their OCSP responses around the world (which ensure certificates stay working after they're issued) and so on, none of which is cheap and all of which needed to be in place before issuing even one certificate. In practice to be any use the certificates need to be trusted, which meant meeting the standards of the big Trust Stores (definitely Apple, Microsoft, Mozilla, probably Google, Oracle, and ideally dozens more besides). Those standards require physical site security, regular third party audits, and so on, which cost even _more_. Now, for Let's Encrypt the solution is this is a charity, you can pitch in $10 and if a hundreds of thousands of people like you do that then it all gets paid for, or if a few bigger organisations pitch in $1000 each that helps too. But for a commercial outfit, well, why not charge $10 to cover costs? And if $10, why not $50? Why not $1000?

cyphar 9y ago

Currently their only upside is that they provide wildcard (and EV) certificates. EV certs can't be automated for obvious reasons, but LE doesn't support wildcard certs because they don't believe there's a secure way of providing an automated way of getting them. Given that traditional CA models don't actually have much more security than LE (in fact from personal experience they're far less secure), I wonder whether they should be in the business of providing wildcard certificates at all.

philliphaydon 9y ago
Why is providing wildcard certs not secure???? Amazon seems to do it?
- eropple 9y ago
  Because once your wildcard certificate is compromised--and you must design systems with the assumption that your certificates will be compromised--it becomes a very achievable exercise to use that wildcard certificate to compromise users going to any of your subdomains. With each domain governed under its own TLS certificate, you install firebreaks between systems to contain the damage an attacker can do. There are vanishingly few reasons to ever share private keys across multiple automated systems. This is not one of them. (Are your systems not automated? Fix that.)
  - tokenizerrr 9y ago
    Meanwhile SAN is fine? The alternative to wildcards is that you get a single cert with tons of subdomains as alternative name. Exact same risks, yet much more hassle to add subdomains. I don't see it.
    - eropple 9y ago
      That's a fine point, if you're using SANs. With Let's Encrypt, you don't need to use a SAN so long as each of your endpoints is distinct. (If they're not, I'm uneasy with your architecture in the first place, y'know?) However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists.
      - tokenizerrr 9y ago
        SNI is not yet always an option if you have to support older clients. It's not about if I'm using SANs anyway. It's that LE is fine with that, but not with wildcard certs. > However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists. Can you elaborate what you mean here?
        eropple 9y ago
        If you have to support older clients--definitely, SAN is your only option if you have to run on the same host. (And I sympathize, because that sucks.) At that point, though, my inclination becomes to attach a bunch more public IPs and wire up my DNS correctly to match. > Can you elaborate what you mean here? Me saying "this cert is valid for example.com, foo.example.com, and bar.example.com" is an incrementally better security posture than saying "this cert is valid for *.example.com". It constrains an attacker from running a phishing attack from, say, "private.example.com" or "secure.example.com". You're whitelisting what you're covering by explicitly declaring all of them. It is incremental, but it's a thing.
        tokenizerrr 9y ago
        IPv4 addresses are relatively expensive. I encounter it quite often where a wildcard gets pointed to a single server (with single IP) which hosts multiple services. There are no security issues compared to a large SAN that I can see in such a situation.
  - philliphaydon 9y ago
    So the Low risk of compromise for most people is more important than the ability to easily maintain a system? If a certificate is going to be compromised it's most likely going to be the most important cert to the system anyway. A hacker isn't going to go after the meaningless ones. But by your logic I should increase the maintainability of the system for no benefit. Obviously this is highly dependent on the usage of the certs to begin with.
- cyphar 9y ago
  Yes, many services "seem to do it". The problem is how do you safely verify that a wildcard certificate is actually being given to the owner of that domain space? It's "trivial" to provide a certificate for a particular domain is owned by someone, but the same techniques don't work for wildcard certificates because now you're verifying only a single domain and providing certificates for an entire class of domains. If you work through all of the ways ACME verification works (/.well-known/, DNS, and so on) you can come up with several plausible setups that become insecure if you allow wildcard certificates. Here's a stack exchange question about it: https://security.stackexchange.com/questions/157972/why-cant-lets-encrypt-support-wildcard-certificates https://security.stackexchange.com/questions/157972/why-cant....
  - tokenizerrr 9y ago
    That SO post makes no sense to me. It claims: > The authentication test can't merely back down one level to mysub.example.com because that isn't covered by the cert requested, and may not be under the control of the requesting agent either. This just seems wrong. Performing the check like that seems to be a sane way to do it. If people can't control the base domain they have no business requesting a wildcard cert.
    - cyphar 9y ago
      But *.a.com doesn't cover a.com, so it's not very clear that the inverse ownership relationship should hold. Yes, it's true on a DNS level but that's one argument I would imagine against doing it that way.
      - tokenizerrr 9y ago
        No, but ownership of a.com heavily implies ownership of (wildcard).a.com (HN is being weird with the asterisk) Alternatively they could just do a DNS check. If you can configure DNS for a.com, you control *.a.com.
        cyphar 9y ago
giobox 9y ago
One annoying thing I've seen less technical stakeholders ask about with letsencrypt is "why the padlock isn't green" in Safari/Edge. Unlike Chrome and I think Firefox, those browsers only display a green padlock for SSL certs with EV, which of course letsencrypt doesn't (and arguably can't really) do. The "grey padlock" for an otherwise perfectly valid certificate seems to confuse a very small subset of users, especially when there's a ton of badly written articles out there advising users only to trust "green padlocks", given the behavior in almost all other browsers. Thankfully showing google.com not using an EV certificate is usually easiest way to shut these conversations down.
- hueving 9y ago
  What types of users have asked you about that? I'm lucky if I can get regular users not to click their way through cert errors.
  - giobox 9y ago
    Like you I've never seen a "customer" user notice, which is why I was careful to use the word "stakeholder". For me it's almost always been product management/sales types in the company.
- nlawalker 9y ago
  >> only to trust "green padlocks" It's not so much about browser-specific behavior, it's about using the padlock to ensure that the company or other entity you're interacting with is the one you wanted, as opposed to only ensuring that the server you're talking to is the one indicated in the address bar. A gray padlock is better than none, but telling less technically-inclined, clicks-all-the-links, fat-fingered users to trust them outright may not be the best idea now that you can go get bankofomerica.com, dress it up to look like BoA's site, and put a gray padlock on it for free.
  - giobox 9y ago
    Given how piecemeal the use of EV certs is by big companies, I'm not sure EV as implemented today delivers any 'real' benefits. It absolutely is about browser specific behaviors. How can you tell users only to interact with companies if they have an EV certificate, when huge internet properties like Amazon, Google and Facebook don't use them? In reality you can't, which means Safari/Edge's behavior arguably doesn't really help anyone. I'm not saying Safari/Edge shouldn't tell the user an EV certificate is present, they absolutely should, but that the approaches used by rival browsers arguably make more sense. I think Chrome/Firefox got this one right by using a green padlock for both valid EV _and_ DV certificates like Letsencrypt, displaying the extra EV information clearly inline in the URL bar if it is present. The changing color in Safari/Edge can give the impression that the the non-EV certificate is somehow less secure, which in technical terms is not the case. Questions of identity verification and security of data transmission are two separate issues which the Safari/Edge approach arguably conflates - both EV and DV can provide equal security of transmission, even if only EV provides some degree of identity confirmation. As a user, it's simply not possible to make the distinction too - if I visit your fake Bank Of America site with a grey padlock, how can I even be sure the 'real' site had an EV certificate and a green one, when there's so many companies that don't? As a user you are effectively forced to treat the grey and green padlocks the same, so why not make them the same color and display extra EV info if it is there, like the other browsers?

orf 9y ago

> What's the justification of traditional providers to charge for the certificates They could, so they did.

rmc 9y ago

No-one did free which works in all browsers before.

collinmanderson 9y ago
StartSSL worked with any Windows XP SP2+ computer. Though you couldn't automate it and their website was kinda slow.
- floatboth 9y ago
  And they demanded personal data. Even checked that your personal address is not a business address! "Domain validation" my ass.

josephjrobison 9y ago

Is this total BS then?: "Why pay for something that’s free, you ask? When a user visits a website that is secured with a self-signed, or free SSL certificate, most web browsers will post an error message. While some people will click “I understand the risks” and proceed to your site, it’s likely that many people will click the “Get me out of here!” button and never return. The real problem lies in the fact that self-signed certificates are virtually unregulated. If your site is compromised, it may still appear secure; however, certificates issued by a trusted certificate authority can be revoked and therefore alert users of any potential threats." Source: http://searchengineland.com/comprehensive-guide-ssl-certificates-264377 http://searchengineland.com/comprehensive-guide-ssl-certific...

MertsA 9y ago
Sort of, that's conflating all free SSL certs with self signed certs. The whole point of an SSL cert is to provide authentication that the server you're talking to is really the server you were trying to reach at www.example.com . They are talking about self signed certificates which is basically the remote server saying "I'm www.example.com, you can trust me because I said so". Let's Encrypt is the same as other CAs out there in terms of authentication. In fact, if you see a certificate that's signed by Symantec, it's more likely to be mississued than a certificate signed by Let's Encrypt.
Ajedi32 9y ago
The certificates Let's Encrypt issues are _not_ self-signed. They are signed by a trusted certificate authority which Let's Encrypt manages, and are no different from domain validated certs signed by any other CA. That article makes the mistake of assuming that if a certificate is free then it _must_ be self-signed, which is obviously false.

jpalomaki 9y ago

Among other things they provide certs which are valid up to three years. Let's Encrypt certs are short term. There idea is to auto renew, but sometimes that is difficult to implement.

tialaramex 9y ago

Just making a certificate costs almost nothing. So in a sense $0 seems like the right price. BUT, being _able_ to make certificates is very expensive. ISRG (the charity behind Let's Encrypt) spends _millions of dollars per year_ on this. Purely mechanically Let's Encrypt needs a data centre with a bunch of high availability servers and pretty good Internet access, employees to look after all that stuff, a deal with CDNs to serve up their OCSP responses around the world (which ensure certificates stay working after they're issued) and so on, none of which is cheap and all of which needed to be in place before issuing even one certificate. In practice to be any use the certificates need to be trusted, which meant meeting the standards of the big Trust Stores (definitely Apple, Microsoft, Mozilla, probably Google, Oracle, and ideally dozens more besides). Those standards require physical site security, regular third party audits, and so on, which cost even _more_. Now, for Let's Encrypt the solution is this is a charity, you can pitch in $10 and if a hundreds of thousands of people like you do that then it all gets paid for, or if a few bigger organisations pitch in $1000 each that helps too. But for a commercial outfit, well, why not charge $10 to cover costs? And if $10, why not $50? Why not $1000?