That philosophy is perplexing because system admins already have to manually handle things like software upgrades. Unlike SSL renewals, upgrades usually occur to an arbitrary frequency yet admins seem to be able to cope.
I'd also contend that 90 day expiry makes end-users less sensitive to certificate change notifications; at present if a website renews its cert after a year I receive a pop-up and I pay attention. Receiving one every 60 days will just condition people to start ignoring cert changes, whether valid or not.
The end users should ideally not be prompted when they see a certificate renewed by the same CA. It should also ideally be a /renewal/ of the old one, and not an entirely new private key generated each time as well. Of course everything could be tuneable.
I believe these are sane defaults.
* Prompt on CA change? (Default Yes)
* Prompt on private key change? (Default No IF the cached certificate is on the old CA's revocation list.)
* Prompt on CA renewal? (Default No)
> It should also ideally be a /renewal/ of the old one, and not an entirely new private key generated each time as well
sure? A new key provides quite a bit of security benefits because even when the key got loose without you noticing, three months later, it won't be usable any more when the new cert is made for a new key.
Users should be able to safely ignore certificate changes. No one should need to install Certificate Patrol to have a safe experience.
Of course, if the certificate changes to an untrusted one, the browser should flag it -- and if the server specifies HSTS, then the browser should block the user from clicking through anyway (increasing the pressure to make sure the cert is always trusted and unexpired).
I'd also contend that 90 day expiry makes end-users less sensitive to certificate change notifications; at present if a website renews its cert after a year I receive a pop-up and I pay attention. Receiving one every 60 days will just condition people to start ignoring cert changes, whether valid or not.