Hacker News Reader

Comment by kevinreedy | Hacker News Reader

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.

View on HN

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

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

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

Hrm. Good point. At some point I remember some SEO guru or other claiming that long-duration domain name registrations were good for SEO, but looking at it now, it seems as though that was a correlation !== causation, as MS, Goog, et al register their domain names for decades at a time, and also tend to have high search rankings.

As for the rest, chalk it up to my over-active imagination, compounded with that bad knowledge. SSL is an SEO boost (according to a random Googling), and if domain name expiration was a factor, it made sense to me that SSL expiry would factor too.

TLDR, I was a dumb.

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

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.

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.

That's correct. I've recently deployed LE on a side project. The official letsencrypt client supports a mode called webroot, where you basically tell the client where your webroot is located on your file system, and it will place a file in .well-known/acme-challenge/<random> to confirm ownership. I use nginx in front of multiple domains with different backends (which do not all have the platform equivalent of a webroot), so I simply added a location directive for .well-known to all vhosts pointing to the same directory which I then pass to letsencrypt.

It would be trivial to move this to a separate machine by using a reverse proxy for .well-known instead of serving it directly from your load balancer's filesystem. The rest is just scp'ing your certificates and keys to your load balancers (or using your configuration management software of choice to achieve the same). With ACME being an open protocol it's quite likely that someone will end up writing a client specifically for this use-case, making it even easier.

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

Reply on news.ycombinator.com