3 ms·

Ignoring for a moment the fact that they hard coded an expiration date: This serves as a good reminder of why it’s a bad idea to set expiration dates at the en

Ignoring for a moment the fact that they hard coded an expiration date: This serves as a good reminder of why it’s a bad idea to set expiration dates at the end of a year, where lots of people are on leave for the holidays (this notice came out only 2 days ago). Instead try sometime less complicated, like mid March or Sept.

black_puppydog 7y ago
I think if someone lacks the awareness that hard-coding expiration dates is not a good idea, expecting them to think to this level is a bit much... :|
- eddieroger 7y ago
  It's a good reminder nonetheless. I was on a team responsible for a web server farm and we noticed after a few years that the expiration date kept creeping closer to January since we would regularly kick off the process a few weeks before it actually expired, and decided one year to renew twice just to reset the clock away from January.
raxxorrax 7y ago
x.509 certs all have a validity period. Of course they could have set them to 2099, but as far as I know you cannot change the validity without reissuing the cert.
- deleted 7y ago
  [deleted]
- tialaramex 7y ago
  It's called notAfter and since it's part of the signed document you cannot change it without invalidating the signature. In a custom system the issuer could (but probably shouldn't) sign a document which is identical save for the notAfter date, but in the Web PKI this would be a serious miss-issuance and have consequences. By convention the notAfter field is filled out in Zulu timezone (ie UTC) and so these will expire simultaneously around the world.
- zenexer 7y ago
  The problem here isn’t that the certificates themselves have an expiration date, it’s that the code that generates them has a hard-coded date. Even if you try to generate a new certificate after 2020-01-01, the expiration date will still be 2020-01-01 on the new certificate.
jcadam 7y ago
Why can't you be grateful for the gift of canceled vacations and overtime pay? Cisco cares - making sure you're home (in your data center) for the holidays.
mywacaday 7y ago
Add to that making production changes two days before holidays. Sitting here waiting for another team to debug what they broke and how to fix it so my app will work. Holidays should have started an hour ago.
- C1sc0cat 7y ago
  We had a freeze starting the 18th /19th for deployments

black_puppydog 7y ago

I think if someone lacks the awareness that hard-coding expiration dates is not a good idea, expecting them to think to this level is a bit much... :|

eddieroger 7y ago
It's a good reminder nonetheless. I was on a team responsible for a web server farm and we noticed after a few years that the expiration date kept creeping closer to January since we would regularly kick off the process a few weeks before it actually expired, and decided one year to renew twice just to reset the clock away from January.

raxxorrax 7y ago

x.509 certs all have a validity period. Of course they could have set them to 2099, but as far as I know you cannot change the validity without reissuing the cert.

deleted 7y ago
[deleted]
tialaramex 7y ago
It's called notAfter and since it's part of the signed document you cannot change it without invalidating the signature. In a custom system the issuer could (but probably shouldn't) sign a document which is identical save for the notAfter date, but in the Web PKI this would be a serious miss-issuance and have consequences. By convention the notAfter field is filled out in Zulu timezone (ie UTC) and so these will expire simultaneously around the world.
zenexer 7y ago
The problem here isn’t that the certificates themselves have an expiration date, it’s that the code that generates them has a hard-coded date. Even if you try to generate a new certificate after 2020-01-01, the expiration date will still be 2020-01-01 on the new certificate.

jcadam 7y ago

Why can't you be grateful for the gift of canceled vacations and overtime pay? Cisco cares - making sure you're home (in your data center) for the holidays.

mywacaday 7y ago

Add to that making production changes two days before holidays. Sitting here waiting for another team to debug what they broke and how to fix it so my app will work. Holidays should have started an hour ago.

C1sc0cat 7y ago
We had a freeze starting the 18th /19th for deployments