4 ms·

I think the default certificate expiration time (2 years) is a terrible idea. Its long enough that there's a good chance whoever registered the cert last time h

I think the default certificate expiration time (2 years) is a terrible idea. Its long enough that there's a good chance whoever registered the cert last time has left the team or the company. Its long enough that I've forgotten how to generate a certificate with openssl on the command line. And its long enough that each time, I (and everyone else) can justify not bothering to automate the process. But 2 years is still short enough that if you have a couple domains, remembering to renew them is an ongoing hassle! Letsencrypt certificates last 90 days, and they recommend renewing them every 60 days. This is a much better duration, because it encourages the entire ecosystem - developers and admins - to set up processes which automate renewal. And if the automated renewal process fails, letsencrypt starts emailing you about it to let you know your certificate is about to expire. (And you have enough time to fix it). https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html

Uvix 4y ago
The maximum expiration time is now down to 13 months, for certs that need to be valid in a browser. And if you want to cycle yours more frequently, you can. But there's enough places that can't set up automated processes that trying to make it 90 days for everyone would be a lot of pain and a lot of broken sites.
- josephg 4y ago
  > But there's enough places that can't set up automated processes Why can't they be automated? And anyway, this is the exact problem that short expiration times avoid! Systems that aren't set up for automation, and rely on someone once a year remembering some creaky, error prone process to get a new cert. Much better to force short expiration times so manual cert renewal is a thing of the past.
  - voytec 4y ago
    DV is not the only kind of certificates validation. I don't want to have to go through the OV/EV validation process several times a year, nor to validate 4 certificate issuances a year in advance. But if I wanted to, I can do so even now without being forced - request new certificate during it's validity period, and revoke the former one.
    - Kwpolska 4y ago
      DV is the only kind that actually matters. Browsers do not display EV certificates in the address bar anymore, the verified identity is hidden in a panel or sometimes even invisible. If you want to pay extra for snake oil, you get to enjoy all the pain in the process. See also: https://www.troyhunt.com/how-everything-were-told-about-website-identity-assurance-is-wrong/ https://www.troyhunt.com/how-everything-were-told-about-webs...
      - citrin_ru 4y ago
        Google made quite a few questionable changes in Chrome (with the rest feeling forced to follow the fashion set by Chrome) and not displaying EV info. Many big organisations use tens of domain some of which look very suspicious. Information in a EV/OV cert is often the only way to establish that a domain operated by the legitimate company (and not by a phisher who registered a similarly looking domain).
        cedilla 4y ago
        Google and Firefox made the change roughly at the same time -- because there was a lot of evidence that EV indicators simply don't work. Users don't pay attention to them, and even if they did, the idea that company names are unique - even within a jurisdiction - is simply incorrect. The only upside of EV certificates is that the PKI companies can seek a higher rent.
        citrin_ru 4y ago
        Even if a higher price is the only EV difference (which not exactly the case) it would be enough make sites with EV certs much less likely to be used in phishing - threat actors want to keep their cost down because they frequently register a lot of domains (much more than most legit companies). And even company names are not unique good luck with registering PayPal Inc or Bank of America Corporation to get an EV cert for your phishing site.
        4y ago
  - Eduard 4y ago
    > Why can't they be automated? E.g. because of regulatory requirements, chain of responsibility, a paper has to be signed with a pen, etc.
    - orra 4y ago
      Interesting, but that sounds like speculation. Do you have any examples of regulatory requirements, as opposed to voluntarily-broken internal processes?
  - Uvix 4y ago
    The people installing the certs aren't necessarily the people buying the certs. I can't do anything to automate the cert purchases at my current workplace; that's a separate team that I have no control or influence over. Shorter expiration times just mean they send me an email with the new .pfx every 4 months instead of every 12.
    - TheCoelacanth 4y ago
      If they had to do that every 2 months instead of every 12, they might get tired enough of it to fix their broken process.
  - technion 4y ago
    Several of the appliances we manage have certificates that are installed using a Web gui and require a reboot with a 15 minute outage for the change to take effect. We've looked at automating some things but there's only so far I want to go down the rabbit hole of headless chrome vs manually installing a cert yearly.
    - pxc 4y ago
      It seems like enforcing faster rotation would do a lot to encourage people and companies to move away from such obtuse platforms, no?
phpisthebest 4y ago
>>to set up processes which automate renewal. that is all fine and good for things that have the ability to automate that process, plenty of hardware and device do not. Some are not even legacy are still actively being sold and developed It is also not good for internal networks where you can not valid out to something like lets encrypt to automate that validation process, sure you could do your own internal PKI and run your own CA for that but...... In my current org 60 days would be a NIGHTMARE to manage.
- thayne 4y ago
  > It is also not good for internal networks where you can not valid out to something like lets encrypt to automate that validation process, sure you could do your own internal PKI and run your own CA for that but...... Or you can set up certbot or similar on a public facing server (or something that can add DNS records to for your domain), and use a secure channel to send the private keys to the things that need it. I would like to see more of a push to make setting up an internal CA a lot easier though. Because that is probably most correct way to handle that.
- Hamuko 4y ago
  >It is also not good for internal networks where you can not valid out to something like lets encrypt to automate that validation process Why not? Just use DNS validation.
  - linsomniac 4y ago
    Yep, I do this for internal names, works great. I've used acme.sh to update the names in a public zone that is isolated from the rest of the zone and has it's unique AWS credentials to update via Route53.
thayne 4y ago
> And its long enough that each time, I (and everyone else) can justify not bothering to automate the process And even worse, if you do automate it there is a pretty good chance something changes and breaks your automation by the time it is needed. And that is assuming you actually tested the automation before your new cert is close to expiring.
- WirelessGigabit 4y ago
  I solve this by certificate expiration monitoring and renewing the certificate at the 60 day mark. The expiration warning is configured so that it starts to yell at me if it passes that timeframe. That gives me plenty of time to fix it IF it goes wrong.
  - derefr 4y ago
    In your case, "something breaks in your automation" might mean that, by the time the cert is (about to be) in need of renewal, the notifications you set up are now going to an email account that doesn't exist any more, because you left the department got re-orged and...
    - RamRodification 4y ago
      If "monitoring" is set up as "send email to specific personal mailbox" then things are gonna suck a lot.
      - derefr 4y ago
        I was more imagining that it was going to an email account called e.g. "devops@"; and then when you left (possibly very quickly, e.g. via termination), the need for the continuity of that account was forgotten, because it had never become institutional knowledge; and then during a reorg, a new group (= email distribution list) was created to match the new department name; with nobody remembering to forward devops@ to the new address, because it wasn't receiving emails anybody needed to see on any sort of consistent basis, only these once-in-a-blue-moon emails.
rr808 4y ago
I like to renew certificates long before expiry. At my job certs last a year but I automate renewal after 5 months. If you find a certificate that is older than 6 months you know something is wrong (long before expiry).
cookiengineer 4y ago
Advantage of certbot: a systemd timer that runs every other week is very easy to write, because "certbot renew" doesn't need any user interactions. So it's literally < 10 lines of systemd unit file to automate it.
- Dylan16807 4y ago
  Or one line of cron.
  - deleted 4y ago
    [deleted]
  - cookiengineer 4y ago
    > Or one line of cron. For each distro, with each having their own format and own crond implementation, at each different file paths.
janoc 4y ago
If you don't automate, don't document and don't check that it is actually working your process from the get-go it is only your own fault, especially when working on industrial scale like this. Rotating the certificates constantly works for personal websites but it is not ideal in places where one can't easily update things - like behind corporate firewalls or where corporate processes permit updating/replacing things only in fixed cycles, which are often much longer than 90 days. Don't remember the Let's Encrypt root certificate expiring fiasco from year ago? Granted, that wasn't really Let's Encrypt's fault but it shows well that these things can be a tad more complicated than just running a script every 90 days.
cush 4y ago
Ballmer's Law: Engineers will design a system's maintenance schedule to be just beyond their promotion cycle

Uvix 4y ago

The maximum expiration time is now down to 13 months, for certs that need to be valid in a browser. And if you want to cycle yours more frequently, you can. But there's enough places that can't set up automated processes that trying to make it 90 days for everyone would be a lot of pain and a lot of broken sites.

josephg 4y ago
> But there's enough places that can't set up automated processes Why can't they be automated? And anyway, this is the exact problem that short expiration times avoid! Systems that aren't set up for automation, and rely on someone once a year remembering some creaky, error prone process to get a new cert. Much better to force short expiration times so manual cert renewal is a thing of the past.
- voytec 4y ago
  DV is not the only kind of certificates validation. I don't want to have to go through the OV/EV validation process several times a year, nor to validate 4 certificate issuances a year in advance. But if I wanted to, I can do so even now without being forced - request new certificate during it's validity period, and revoke the former one.
  - Kwpolska 4y ago
    DV is the only kind that actually matters. Browsers do not display EV certificates in the address bar anymore, the verified identity is hidden in a panel or sometimes even invisible. If you want to pay extra for snake oil, you get to enjoy all the pain in the process. See also: https://www.troyhunt.com/how-everything-were-told-about-website-identity-assurance-is-wrong/ https://www.troyhunt.com/how-everything-were-told-about-webs...
    - citrin_ru 4y ago
      Google made quite a few questionable changes in Chrome (with the rest feeling forced to follow the fashion set by Chrome) and not displaying EV info. Many big organisations use tens of domain some of which look very suspicious. Information in a EV/OV cert is often the only way to establish that a domain operated by the legitimate company (and not by a phisher who registered a similarly looking domain).
      - cedilla 4y ago
        Google and Firefox made the change roughly at the same time -- because there was a lot of evidence that EV indicators simply don't work. Users don't pay attention to them, and even if they did, the idea that company names are unique - even within a jurisdiction - is simply incorrect. The only upside of EV certificates is that the PKI companies can seek a higher rent.
        citrin_ru 4y ago
        Even if a higher price is the only EV difference (which not exactly the case) it would be enough make sites with EV certs much less likely to be used in phishing - threat actors want to keep their cost down because they frequently register a lot of domains (much more than most legit companies). And even company names are not unique good luck with registering PayPal Inc or Bank of America Corporation to get an EV cert for your phishing site.
        4y ago
- Eduard 4y ago
  > Why can't they be automated? E.g. because of regulatory requirements, chain of responsibility, a paper has to be signed with a pen, etc.
  - orra 4y ago
    Interesting, but that sounds like speculation. Do you have any examples of regulatory requirements, as opposed to voluntarily-broken internal processes?
- Uvix 4y ago
  The people installing the certs aren't necessarily the people buying the certs. I can't do anything to automate the cert purchases at my current workplace; that's a separate team that I have no control or influence over. Shorter expiration times just mean they send me an email with the new .pfx every 4 months instead of every 12.
  - TheCoelacanth 4y ago
    If they had to do that every 2 months instead of every 12, they might get tired enough of it to fix their broken process.
- technion 4y ago
  Several of the appliances we manage have certificates that are installed using a Web gui and require a reboot with a 15 minute outage for the change to take effect. We've looked at automating some things but there's only so far I want to go down the rabbit hole of headless chrome vs manually installing a cert yearly.
  - pxc 4y ago
    It seems like enforcing faster rotation would do a lot to encourage people and companies to move away from such obtuse platforms, no?

phpisthebest 4y ago

>>to set up processes which automate renewal. that is all fine and good for things that have the ability to automate that process, plenty of hardware and device do not. Some are not even legacy are still actively being sold and developed It is also not good for internal networks where you can not valid out to something like lets encrypt to automate that validation process, sure you could do your own internal PKI and run your own CA for that but...... In my current org 60 days would be a NIGHTMARE to manage.

thayne 4y ago
> It is also not good for internal networks where you can not valid out to something like lets encrypt to automate that validation process, sure you could do your own internal PKI and run your own CA for that but...... Or you can set up certbot or similar on a public facing server (or something that can add DNS records to for your domain), and use a secure channel to send the private keys to the things that need it. I would like to see more of a push to make setting up an internal CA a lot easier though. Because that is probably most correct way to handle that.
Hamuko 4y ago
>It is also not good for internal networks where you can not valid out to something like lets encrypt to automate that validation process Why not? Just use DNS validation.
- linsomniac 4y ago
  Yep, I do this for internal names, works great. I've used acme.sh to update the names in a public zone that is isolated from the rest of the zone and has it's unique AWS credentials to update via Route53.

thayne 4y ago

> And its long enough that each time, I (and everyone else) can justify not bothering to automate the process And even worse, if you do automate it there is a pretty good chance something changes and breaks your automation by the time it is needed. And that is assuming you actually tested the automation before your new cert is close to expiring.

WirelessGigabit 4y ago
I solve this by certificate expiration monitoring and renewing the certificate at the 60 day mark. The expiration warning is configured so that it starts to yell at me if it passes that timeframe. That gives me plenty of time to fix it IF it goes wrong.
- derefr 4y ago
  In your case, "something breaks in your automation" might mean that, by the time the cert is (about to be) in need of renewal, the notifications you set up are now going to an email account that doesn't exist any more, because you left the department got re-orged and...
  - RamRodification 4y ago
    If "monitoring" is set up as "send email to specific personal mailbox" then things are gonna suck a lot.
    - derefr 4y ago
      I was more imagining that it was going to an email account called e.g. "devops@"; and then when you left (possibly very quickly, e.g. via termination), the need for the continuity of that account was forgotten, because it had never become institutional knowledge; and then during a reorg, a new group (= email distribution list) was created to match the new department name; with nobody remembering to forward devops@ to the new address, because it wasn't receiving emails anybody needed to see on any sort of consistent basis, only these once-in-a-blue-moon emails.

rr808 4y ago

I like to renew certificates long before expiry. At my job certs last a year but I automate renewal after 5 months. If you find a certificate that is older than 6 months you know something is wrong (long before expiry).

cookiengineer 4y ago

Advantage of certbot: a systemd timer that runs every other week is very easy to write, because "certbot renew" doesn't need any user interactions. So it's literally < 10 lines of systemd unit file to automate it.

Dylan16807 4y ago
Or one line of cron.
- deleted 4y ago
  [deleted]
- cookiengineer 4y ago
  > Or one line of cron. For each distro, with each having their own format and own crond implementation, at each different file paths.

janoc 4y ago

If you don't automate, don't document and don't check that it is actually working your process from the get-go it is only your own fault, especially when working on industrial scale like this. Rotating the certificates constantly works for personal websites but it is not ideal in places where one can't easily update things - like behind corporate firewalls or where corporate processes permit updating/replacing things only in fixed cycles, which are often much longer than 90 days. Don't remember the Let's Encrypt root certificate expiring fiasco from year ago? Granted, that wasn't really Let's Encrypt's fault but it shows well that these things can be a tad more complicated than just running a script every 90 days.

cush 4y ago

Ballmer's Law: Engineers will design a system's maintenance schedule to be just beyond their promotion cycle