[kevinreedy]

I actually love the idea of 90 day (or less) certificates! Once you automate the process of replacing your certificate (which let's encrypt will greatly help with), it won't matter how short the period is. Also, if a key gets compromised, it'll be valid for a shorter time. Give https://letsencrypt.org/2015/11/09/why-90-days.html a read! If you want to get more in-depth about certificate revocation, http://news.netcraft.com/archives/2013/05/13/how-certificate... is also a great/depressing read.

[bmelton]

Does Google still penalize short-term / soon-expiring SSL certs in search rankings?

Edit: this does not appear to be a thing that happens.

[mappu]

I would assume not, given that https://letsencrypt.org/2015/11/09/why-90-days.html cites "According to Firefox Telemetry, 29% of TLS transactions use ninety-day certificates. That’s more than any other lifetime."

[tedchs]

Why do you think that's a thing that's happening?

[ars]

If someone compromised the key they also compromised the system used to automatically generate more keys, so a short expiration is not as helpful as it looks.

It's even worse than that:

A smart attacker will copy the method used to generate keys, and leave the server. Then they can keep generating keys and you will probably never notice.

I feel that automation is a mistake, something security sensitive like this should be on a completely different machine.

[AgentME]

Generating the cert involves proving that you own the domain. An attacker can't copy that away (unless they've stolen the domain entirely from you, in which case the SSL keys are not your primary issue).

[kevinreedy]

I'm not in the beta, and thus haven't been able to play with it yet. But, I don't believe there'd be anything prohibiting you from generating the certs on a separate machine. In fact, I'd imagine that's what you'd want to do (if you have more than one server) rather than generating a separate certificate for every web server or load balancer.