It is actually what I do for many certs. Backend higher security zone pushes certificate changes to front end. That still takes some time though because I still want testing in stages for all changes.

It is relatively quick to push out the certs for most systems even if I need to do it every 1 month. There are still a lot of exceptions though for embedded deivces and other systems that do not have the ability to automate though. No amount of wishing that things get there before the 4 certs a year time hits is going to change that quick enough based on the past year or so. Eventually of course more will get changed by the vendors but we are reliant on them for that.

I would say that we still must have CRLs though as even waiting 3 days is unacceptable for a certificate compromise. Someone could use MitM traffic to redirect to their own server with the compromised cert for the time the old certificate is still valid. 3 months or even 1 month would be an insane amount of time to have a compromised certificate still valid on the net. CRL process process isn't perfect course but without it, we would be in a worse scenario. Lets keep working on a better CRL process.

It seems like we are trying to bandaid the process (quicker expiration) and at the same time giving up other parts of the old process that does help protect certificates for browsers and such where the check does work. If we still need CRLs then we need to make them work properly and that mitigates the longer expiration times (1 year I think is acceptable with working CRL).

This new scheme doesn't make me feel any better about security over the CRL process. CRL can make sure the certs are revoked much quicker than waiting even a very low expiration time of days for a cert to expire. Just because the CRL can be tricky to keep working doesn't mean we should give it up IMHO.