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.
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.