6 ms·

3 months was an excellent choice because it means you _have_ to automate so it will never expire. While the 1 and 2 year certs always end up expiring on product

by hexa22 5y ago

3 months was an excellent choice because it means you _have_ to automate so it will never expire. While the 1 and 2 year certs always end up expiring on production because someone forgot about them.

flemhans 5y ago
Now you just have to upgrade certbot every 1-2 years instead, it feels like.
- martin-adams 5y ago
  Did that this morning. Was a complete pain but got there in the end.
- danuker 5y ago
  I have a Debian server, and it has been running unattended pretty much since I installed it. I warmly recommend it. https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades
  - flemhans 5y ago
    Me too, also on Debian. But there have been different installation methods over the time, certbot via deb package, installation script by piping in a URL, certbot-auto, something in /opt, lost track :D
  - hexa22 5y ago
    I had to look at mine once in 5 years because acme v1 shut down.
wbond 5y ago
It also means you have to automate things that are tied to your certificate lifetime. Apple Pay on the web requires you authenticate your server, and it uses your certificate serial num as proof you still own the server. This means every three months you need to re-authenticate with Apple Pay. But there is no Acme client for authenticating with Apple Pay. So instead, I was having to re-authenticate something manually every 3 months. It involved logging into an Apple Developer account, downloading a PEM file, uploading to my server and then clicking a button in the Developer Account to check the file. After doing that dance, I happily paid for 2 year certificates from RapidSSL. Now you can only buy one year certificates. I really hope the CAB isn’t successful in making those non-conforming and requiring shorter certs. There are plenty of other environments where certificate automation is not possible. And honestly, I haven’t seen arguments as to how on-machine automation is more secure than requiring someone be involved in the process. While I’m dreaming about improvements to the CA ecosystem, having some way to actually prove your are the company you claim would be amazing. Instead we are actively removing support for anything that tried to provide that…
- infogulch 5y ago
  I'm not sure why you choose to see this as something that "can't be automated, so must use long-expiry certs" and not "apple fails to offer an api to perform an essential-to-automate task".
  - wbond 5y ago
    I see LE as generally trading low cost certs for expensive labor. It’s great when you have scale and need hundreds of certs. I care more about making it easy for people to pay me than getting “free” certificates that cost me hundreds of dollars in labor costs. Everyone talks about LE like it is perfect. I’ve just determined after using it at four different orgs that for smaller shops it tends to take more time/money to get it working than using long expiring certs deployed via an automation system. Honestly, setting up even more automation, like you suggest Apple provide, would probably cost 5x in labor as being able to purchase 3 year certs for the next 12 years. Automation is great when you have scale. In this case, I don’t. I tend to work at smaller companies, so I’ve never worked at an org big enough for the automation to pay off versus buying certs.
    - infogulch 5y ago
      > long expiring certs deployed via an automation system If you're already automating it why stop halfway? I don't see your point. > setting up even more automation ... would probably cost 5x in labor [than the cost of 3 year certs over 12 years]. (0. 3 year certs are going away for operational security reasons, but lets skip that for now.) 1. Are you sure it costs more in labor to automate? Are you factoring in: a) the opportunity cost of lost sales and customer dissatisfaction when the certs expire in prod? b) the time it takes to train new employees how to change the certs [which at the average turnover rate is paid at every cert change]? c) the recurring labor of finance and operations professionals and management expensing, accounting, reporting, and reviewing this irregular cost? d) the opportunity cost of avoiding setting up new https-enabled services because it's such a huge pita for the organization? > Automation is great when you have scale. 2. Lets decompose your scale argument into "vertical" vs "horizontal" scale that is hopefully familiar to people provisioning infrastructure. Here, "vertical scale" is one company needing many certs. I agree that if your vertical scale is low (say 10 certs) then it may not be worth it to spend 200h of labor automating it by yourself. But automation can also be scaled "horizontally": if 100 companies need it they can amortize the labor cost of creating the automation between them and have plenty of hours left over to implement it. This is the central ethos of open source and the reason why it can work at all.
webmobdev 5y ago
Concerns when automating and connecting with a third-party service is that you can introduce more vulnerability. (Or even introduce a backdoor if you use a malware / insecure software to do so.)
ryandrake 5y ago
Except when certbot fails (silently) for some unknown and different reason every three months, and you have to ssh in anyway to fix it. Out of all the software I run on my tiny hobby VPS (a few web sites, E-mail), certbot requires more babysitting by an order of magnitude. Even more than spamassassin, which gets wedged regularly. I'm not a professional sysadmin, so something is probably configured incorrectly, but certbot's error messages are so cryptic and non-actionable that I've never been able to solve it. So, I have a calendar reminder every three months to log in to the VPS and figure out what went wrong this time...
- Anunayj 5y ago
  I agree certbot can be a pain the the arse, specially when combined with the fact that you need to also rely on other moving parts (like DNS updates) that can fail in weird ways too. You could try your luck with acme.sh or dehydrated though. My previous setup had a lot of weird problems, my current one seems to be doing fine though, I still think capping the certificates to 3 months is a good idea though, well unless people start taking DNSSEC seriously and adopt DANE [1] [1] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
- tialaramex 5y ago
  FWIW While your "every three months ssh to the VPS and check" approach can work, I'd commend finding a service (many free ones out there for a small project) that will notify you in a way you're happy with about certificates that are expired or soon-to-expire on your servers.
- petre 5y ago
  Lego has an option to renew a number of days prior to expiration. LE recommends 30 days. That leaves me with 4 weekly attempts to renew my certificate.
superkuh 5y ago
Back before the corporate browsers took over standards via whatwg and worse, unilateral moves, you could have a TLS cert for many, many years. I often set mine for 20. But because of changes browsers have made in the name of security this is no longer possible and so shifts the insecurity to another part of the process (the complex system for automation on both client and server sides).

by hexa22 5y ago

3 months was an excellent choice because it means you _have_ to automate so it will never expire. While the 1 and 2 year certs always end up expiring on production because someone forgot about them.

flemhans 5y ago

Now you just have to upgrade certbot every 1-2 years instead, it feels like.

martin-adams 5y ago
Did that this morning. Was a complete pain but got there in the end.
danuker 5y ago
I have a Debian server, and it has been running unattended pretty much since I installed it. I warmly recommend it. https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades
- flemhans 5y ago
  Me too, also on Debian. But there have been different installation methods over the time, certbot via deb package, installation script by piping in a URL, certbot-auto, something in /opt, lost track :D
- hexa22 5y ago
  I had to look at mine once in 5 years because acme v1 shut down.

wbond 5y ago

It also means you have to automate things that are tied to your certificate lifetime. Apple Pay on the web requires you authenticate your server, and it uses your certificate serial num as proof you still own the server. This means every three months you need to re-authenticate with Apple Pay. But there is no Acme client for authenticating with Apple Pay. So instead, I was having to re-authenticate something manually every 3 months. It involved logging into an Apple Developer account, downloading a PEM file, uploading to my server and then clicking a button in the Developer Account to check the file. After doing that dance, I happily paid for 2 year certificates from RapidSSL. Now you can only buy one year certificates. I really hope the CAB isn’t successful in making those non-conforming and requiring shorter certs. There are plenty of other environments where certificate automation is not possible. And honestly, I haven’t seen arguments as to how on-machine automation is more secure than requiring someone be involved in the process. While I’m dreaming about improvements to the CA ecosystem, having some way to actually prove your are the company you claim would be amazing. Instead we are actively removing support for anything that tried to provide that…

infogulch 5y ago
I'm not sure why you choose to see this as something that "can't be automated, so must use long-expiry certs" and not "apple fails to offer an api to perform an essential-to-automate task".
- wbond 5y ago
  I see LE as generally trading low cost certs for expensive labor. It’s great when you have scale and need hundreds of certs. I care more about making it easy for people to pay me than getting “free” certificates that cost me hundreds of dollars in labor costs. Everyone talks about LE like it is perfect. I’ve just determined after using it at four different orgs that for smaller shops it tends to take more time/money to get it working than using long expiring certs deployed via an automation system. Honestly, setting up even more automation, like you suggest Apple provide, would probably cost 5x in labor as being able to purchase 3 year certs for the next 12 years. Automation is great when you have scale. In this case, I don’t. I tend to work at smaller companies, so I’ve never worked at an org big enough for the automation to pay off versus buying certs.
  - infogulch 5y ago
    > long expiring certs deployed via an automation system If you're already automating it why stop halfway? I don't see your point. > setting up even more automation ... would probably cost 5x in labor [than the cost of 3 year certs over 12 years]. (0. 3 year certs are going away for operational security reasons, but lets skip that for now.) 1. Are you sure it costs more in labor to automate? Are you factoring in: a) the opportunity cost of lost sales and customer dissatisfaction when the certs expire in prod? b) the time it takes to train new employees how to change the certs [which at the average turnover rate is paid at every cert change]? c) the recurring labor of finance and operations professionals and management expensing, accounting, reporting, and reviewing this irregular cost? d) the opportunity cost of avoiding setting up new https-enabled services because it's such a huge pita for the organization? > Automation is great when you have scale. 2. Lets decompose your scale argument into "vertical" vs "horizontal" scale that is hopefully familiar to people provisioning infrastructure. Here, "vertical scale" is one company needing many certs. I agree that if your vertical scale is low (say 10 certs) then it may not be worth it to spend 200h of labor automating it by yourself. But automation can also be scaled "horizontally": if 100 companies need it they can amortize the labor cost of creating the automation between them and have plenty of hours left over to implement it. This is the central ethos of open source and the reason why it can work at all.

webmobdev 5y ago

Concerns when automating and connecting with a third-party service is that you can introduce more vulnerability. (Or even introduce a backdoor if you use a malware / insecure software to do so.)

ryandrake 5y ago

Except when certbot fails (silently) for some unknown and different reason every three months, and you have to ssh in anyway to fix it. Out of all the software I run on my tiny hobby VPS (a few web sites, E-mail), certbot requires more babysitting by an order of magnitude. Even more than spamassassin, which gets wedged regularly. I'm not a professional sysadmin, so something is probably configured incorrectly, but certbot's error messages are so cryptic and non-actionable that I've never been able to solve it. So, I have a calendar reminder every three months to log in to the VPS and figure out what went wrong this time...

Anunayj 5y ago
I agree certbot can be a pain the the arse, specially when combined with the fact that you need to also rely on other moving parts (like DNS updates) that can fail in weird ways too. You could try your luck with acme.sh or dehydrated though. My previous setup had a lot of weird problems, my current one seems to be doing fine though, I still think capping the certificates to 3 months is a good idea though, well unless people start taking DNSSEC seriously and adopt DANE [1] [1] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
tialaramex 5y ago
FWIW While your "every three months ssh to the VPS and check" approach can work, I'd commend finding a service (many free ones out there for a small project) that will notify you in a way you're happy with about certificates that are expired or soon-to-expire on your servers.
petre 5y ago
Lego has an option to renew a number of days prior to expiration. LE recommends 30 days. That leaves me with 4 weekly attempts to renew my certificate.

superkuh 5y ago

Back before the corporate browsers took over standards via whatwg and worse, unilateral moves, you could have a TLS cert for many, many years. I often set mine for 20. But because of changes browsers have made in the name of security this is no longer possible and so shifts the insecurity to another part of the process (the complex system for automation on both client and server sides).