4 ms·

They forgot the fact that you can create internal certs with longer expiration dates than a year. You’d be hard pressed to find an organization that hasn’t had

by ratg13 4y ago

They forgot the fact that you can create internal certs with longer expiration dates than a year. You’d be hard pressed to find an organization that hasn’t had operations taken down at least once by expired certs. Renewing all of the certificates in the org every year is just a time consuming hassle. Obviously auto-renew setups are preferred, but in the instances where this is not possible, i prefer 20 year certs over hoping someone will remember to change the cert for the next 20 years. It’s all internal traffic anyway. You could use all of the time saved to harden your network instead, which would provide greater security than cert rotation.

justin_oaks 4y ago
This is a great point. There's an issue in Docker Desktop where some certificate expires and then Docker Desktop fails to start. The worst part about this is that its a self-signed certificate that expires in a year. Why just 1 year when it's self signed and could be 20 years? Internal traffic shouldn't require changing a certificate every year. Even an automated rotation process can fail, and having more frequent rotations allows more chances for failure.
- tashian 4y ago
  Full disclosure: I work for Smallstep. The recent trend toward "Zero Trust" security has come about in the wake of attacks on internal infrastructure, where having a firewall wasn't enough. There can be lots of ways into internal networks. And attacks can come from the inside. Of course, every environment is different and every threat model is different. Internal CAs are not for everyone. But, a lot of orgs have a threat model that demands authenticated encryption for internal traffic. And at that point, you may want an internal CA. As for validity periods... as with many things, there are tradeoffs. We advocate for short-lived certs (a few minutes to a few days). Short-lived certs can greatly simplify the revocation process, in the case where an attacker steals a private key. You often don't need the complexity of CRL or OCSP, because you can just let the cert expire and tell the CA to disallow renewal. And, if you have a policy where certs last for 7 days and is renewed every day, it forces the organization to use good hygiene around automated renewals and monitoring. However, there are scenarios where long-lived certs make a lot of sense. For example, if the private key is hardware-bound and is non-exportable, then it makes sense to use longer validity periods. In this case, a successful attacker might be able to use the key, but they cannot steal it. So, you can get away with a longer-lived cert here. But, all certs do eventually expire and you still have to have some answer to that.
m3047 4y ago
Not sure why this is getting downvoted. I upvoted it because I'm not sure people understand the complexity of internal operations and all of the uses of certs and opportunities for things to go wrong. But 20 years? Geesh. Couldn't you have just advocated for staggered expirations?
- ratg13 4y ago
  The CA that issues the 20 year certs stays offline, so the only way to get the private key is to hack each machine. If the machine is compromised to the point where you can extract the key, the cert does very little since you already own the endpoint.
stefan_ 4y ago
You would think with the frequency this happens some adults in the room would have introduced a "soft expire" mode by now, where it just loudly complains instead of binary refusing to work, particularly given how marginal a "security feature" expiry is anyway.
- ndsipa_pomu 4y ago
  Sounds to me that a "soft expire" is just shifting the problem slightly. If things continue to work, then people will ignore the soft expiration until it becomes a hard expiration. If things stop working, then there's no point in having the soft expiration. I'm sold on the LetsEncrypt philosophy of having short expiration dates so that organisations are more or less forced to properly automate their renewal processes.

by ratg13 4y ago

justin_oaks 4y ago

This is a great point. There's an issue in Docker Desktop where some certificate expires and then Docker Desktop fails to start. The worst part about this is that its a self-signed certificate that expires in a year. Why just 1 year when it's self signed and could be 20 years? Internal traffic shouldn't require changing a certificate every year. Even an automated rotation process can fail, and having more frequent rotations allows more chances for failure.

tashian 4y ago
Full disclosure: I work for Smallstep. The recent trend toward "Zero Trust" security has come about in the wake of attacks on internal infrastructure, where having a firewall wasn't enough. There can be lots of ways into internal networks. And attacks can come from the inside. Of course, every environment is different and every threat model is different. Internal CAs are not for everyone. But, a lot of orgs have a threat model that demands authenticated encryption for internal traffic. And at that point, you may want an internal CA. As for validity periods... as with many things, there are tradeoffs. We advocate for short-lived certs (a few minutes to a few days). Short-lived certs can greatly simplify the revocation process, in the case where an attacker steals a private key. You often don't need the complexity of CRL or OCSP, because you can just let the cert expire and tell the CA to disallow renewal. And, if you have a policy where certs last for 7 days and is renewed every day, it forces the organization to use good hygiene around automated renewals and monitoring. However, there are scenarios where long-lived certs make a lot of sense. For example, if the private key is hardware-bound and is non-exportable, then it makes sense to use longer validity periods. In this case, a successful attacker might be able to use the key, but they cannot steal it. So, you can get away with a longer-lived cert here. But, all certs do eventually expire and you still have to have some answer to that.

m3047 4y ago

Not sure why this is getting downvoted. I upvoted it because I'm not sure people understand the complexity of internal operations and all of the uses of certs and opportunities for things to go wrong. But 20 years? Geesh. Couldn't you have just advocated for staggered expirations?

ratg13 4y ago
The CA that issues the 20 year certs stays offline, so the only way to get the private key is to hack each machine. If the machine is compromised to the point where you can extract the key, the cert does very little since you already own the endpoint.

stefan_ 4y ago

You would think with the frequency this happens some adults in the room would have introduced a "soft expire" mode by now, where it just loudly complains instead of binary refusing to work, particularly given how marginal a "security feature" expiry is anyway.

ndsipa_pomu 4y ago
Sounds to me that a "soft expire" is just shifting the problem slightly. If things continue to work, then people will ignore the soft expiration until it becomes a hard expiration. If things stop working, then there's no point in having the soft expiration. I'm sold on the LetsEncrypt philosophy of having short expiration dates so that organisations are more or less forced to properly automate their renewal processes.