6 ms·

We could very easily make the cert lifetimes one year, or anything else. We chose 90 days for the reasons outlined here: https://letsencrypt.org/2015/11/09/why

by jaas 10y ago

We could very easily make the cert lifetimes one year, or anything else. We chose 90 days for the reasons outlined here: https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html Additionally, long cert lifetimes are dangerous because revocation is ineffective and things like heartbleed happen.

toomuchtodo 10y ago
I appreciate what Let's Encrypt is doing, and have even donated, but internally at our org (as a DevOps), I cannot sell certs that expire every 90 days; $300/year for a wildcard cert is a small price to pay for 1 year expirations.
- jaas 10y ago
  Yeah, I hear that frequently and I get it. The important thing, really, is that you have a cert and that you deploy HTTPS. If you can afford it and it's what you need to do to deploy HTTPS, then whether or not you get your cert from Let's Encrypt is not so important. There are some good reasons behind the automation practices we encourage though, and if you're doing that stuff then the lifetime doesn't matter much. Worth considering regardless of who your CA is. Thanks for your support!
- devy 10y ago
  I think LE's 90-day expiration reason #2 is really the key: encouraging automation. So what it really is investing effort once and working for arbitrarily period of time. If the TLS certificate renewal process cannot be automated but must be manually done for some reason, that perhaps LE certificates are really not what you are looking for.
  - toomuchtodo 10y ago
    The chances of automation failing is higher than the chance our SSL certs will need revocation. With that said, still a big supporter of Let's Encrypt for folks who can tolerate the constraints.
    - artursapek 10y ago
      Automation failing once shouldn't be a catastrophe; you could renew after 30 days and issue a pager alert if it fails. Then you'd have 60 days to figure out what went wrong, manually update it, and fix the issue with the automation.
      - toomuchtodo 10y ago
        At fully loaded engineer costs, if someone takes more than an hour or two to investigate, its already more expensive than a wildcard cert.
        artursapek 10y ago
        If all you care about is money, sure.
        finnn 10y ago
        The few times I've had Let's Encrypt's automation fail it's taken a few minutes, not hours, to investigate and fix. Anecdotal, sure, but I don't see it taking hours to fix
        toomuchtodo 10y ago
        Anecdotal, but managing thousands of VMs, hundreds of ELBs, service discovery, several CI pipelines, and so on, its never a few minutes unless its a blatant misconfigured flag.
        jessaustin 10y ago
        It sounds as if your organization would be a customer for a different service than the one that LE provides.
        viraptor 10y ago
        If you're issuing lots of internal certificates, you may be interested in using Anchor [1] instead. It's designed for that use case and with own service you don't need to worry about rate limits, name limits of similar issues. While it's designed to cycle all your certificates every day, you can still configure it for weeks/months. It's also based on credentials rather than domain verification (shameless plug, I'm Anchor developer) [1] https://github.com/openstack/anchor https://github.com/openstack/anchor
- JoshTriplett 10y ago
  I'd absolutely love to have wildcard certificates as well. I think Let's Encrypt has plans to offer them, as soon as they finish producing a new version of the ACME standard that supports authorizing them.
  - Intermernet 10y ago
    It looks like that should be happening soonish if I read the Github issues correctly. https://github.com/ietf-wg-acme/acme/pull/124 https://github.com/ietf-wg-acme/acme/pull/124 is "Enable the server to specify requirements for issuance" which seems to include wildcard cert support, but was only merged into master about 5 weeks ago. I presume further discussion is ongoing. Personally I'm glad that they're taking the time to get this right. They could have probably supported wildcard certs a while ago, but it would have been through some mangled and limited method. The method they're now looking at seems to be much more future proof. Of course, I may be completely wrong about this, but the above is what I gather from following the issues.
- __jal 10y ago
  Same here. But you and I (or, more specifically, our firms) are not really the market for LE, at least at this point. I fully expect over time for others to compete with LE, using free certs as a loss leader for other services. I also expect the NSIs and Symantecs to continue making money catering to businesses for multiple reasons, some possibly reasonable, some stupid. Of course, LE could make themselves more attractive to firms like mine, given the automation angle - I've had cert vendors try to offer tools to do this, but they have all been terrible, broken, security nightmares, or all three. Get this part bullet proof and I can imagine companies switching right after someone forgets to renew...

by jaas 10y ago

toomuchtodo 10y ago

I appreciate what Let's Encrypt is doing, and have even donated, but internally at our org (as a DevOps), I cannot sell certs that expire every 90 days; $300/year for a wildcard cert is a small price to pay for 1 year expirations.

jaas 10y ago
Yeah, I hear that frequently and I get it. The important thing, really, is that you have a cert and that you deploy HTTPS. If you can afford it and it's what you need to do to deploy HTTPS, then whether or not you get your cert from Let's Encrypt is not so important. There are some good reasons behind the automation practices we encourage though, and if you're doing that stuff then the lifetime doesn't matter much. Worth considering regardless of who your CA is. Thanks for your support!
devy 10y ago
I think LE's 90-day expiration reason #2 is really the key: encouraging automation. So what it really is investing effort once and working for arbitrarily period of time. If the TLS certificate renewal process cannot be automated but must be manually done for some reason, that perhaps LE certificates are really not what you are looking for.
- toomuchtodo 10y ago
  The chances of automation failing is higher than the chance our SSL certs will need revocation. With that said, still a big supporter of Let's Encrypt for folks who can tolerate the constraints.
  - artursapek 10y ago
    Automation failing once shouldn't be a catastrophe; you could renew after 30 days and issue a pager alert if it fails. Then you'd have 60 days to figure out what went wrong, manually update it, and fix the issue with the automation.
    - toomuchtodo 10y ago
      At fully loaded engineer costs, if someone takes more than an hour or two to investigate, its already more expensive than a wildcard cert.
      - artursapek 10y ago
        If all you care about is money, sure.
      - finnn 10y ago
        The few times I've had Let's Encrypt's automation fail it's taken a few minutes, not hours, to investigate and fix. Anecdotal, sure, but I don't see it taking hours to fix
        toomuchtodo 10y ago
        Anecdotal, but managing thousands of VMs, hundreds of ELBs, service discovery, several CI pipelines, and so on, its never a few minutes unless its a blatant misconfigured flag.
        jessaustin 10y ago
        It sounds as if your organization would be a customer for a different service than the one that LE provides.
        viraptor 10y ago
        If you're issuing lots of internal certificates, you may be interested in using Anchor [1] instead. It's designed for that use case and with own service you don't need to worry about rate limits, name limits of similar issues. While it's designed to cycle all your certificates every day, you can still configure it for weeks/months. It's also based on credentials rather than domain verification (shameless plug, I'm Anchor developer) [1] https://github.com/openstack/anchor https://github.com/openstack/anchor
JoshTriplett 10y ago
I'd absolutely love to have wildcard certificates as well. I think Let's Encrypt has plans to offer them, as soon as they finish producing a new version of the ACME standard that supports authorizing them.
- Intermernet 10y ago
  It looks like that should be happening soonish if I read the Github issues correctly. https://github.com/ietf-wg-acme/acme/pull/124 https://github.com/ietf-wg-acme/acme/pull/124 is "Enable the server to specify requirements for issuance" which seems to include wildcard cert support, but was only merged into master about 5 weeks ago. I presume further discussion is ongoing. Personally I'm glad that they're taking the time to get this right. They could have probably supported wildcard certs a while ago, but it would have been through some mangled and limited method. The method they're now looking at seems to be much more future proof. Of course, I may be completely wrong about this, but the above is what I gather from following the issues.
__jal 10y ago
Same here. But you and I (or, more specifically, our firms) are not really the market for LE, at least at this point. I fully expect over time for others to compete with LE, using free certs as a loss leader for other services. I also expect the NSIs and Symantecs to continue making money catering to businesses for multiple reasons, some possibly reasonable, some stupid. Of course, LE could make themselves more attractive to firms like mine, given the automation angle - I've had cert vendors try to offer tools to do this, but they have all been terrible, broken, security nightmares, or all three. Get this part bullet proof and I can imagine companies switching right after someone forgets to renew...