3 ms·
I think it's the same reason we have expirations for server certificates. It limits the amount of time you can do something bad with it without straight up untr
by ecnahc515 6y ago
I think it's the same reason we have expirations for server certificates. It limits the amount of time you can do something bad with it without straight up untrusting it in it's entirety.
Probably something like: large CA gets acquired by another company (trustworthy, or not).
How does one stop trusting certs from that CA going forward, but still allowing existing certs to be trusted? Unless you control the clients and the CAs they use (eg like browsers do) you can't easily configure things to only trust certs issued by a particular root prior to a particular date. So your other option is to remove the CA from your OS CA bundle, but that breaks all existing certs that you still want to trust.
Instead, you can assume the root CA will eventually expire, and you simply have to trust certificates issued by it until the CA expires. It's not perfect, but it's an option.
A good example is the Symantec CA which was caught mis-issuing certificates. Browsers control their own CA bundles and logic so they basically changed how they do validation to only allow certs issued by Symantec prior to June 2016, but other clients still trusted Symantec. The only choice was to remove them from the CA bundle or wait for the CA to expire. In this case, most OSes and Browsers simply removed the CA after a particular date, but it's possible it wouldn't have been so unanimous across the industry on how to proceed, and an expiration date would have been the last fall back.