Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Public Beta: December 3, 2015

letsencrypt.org

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Public Beta: December 3, 2015

#51

Post by pfg »

kevinreedy wrote: post #48
ars wrote: post #38

Earlier quoted context omitted.

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 shou…

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

Re: Public Beta: December 3, 2015

#52

Post by mobiplayer »

tombrossman wrote: post #10

I'm really pleased to see this initiative and I've used the private beta with letsencrypt-nosudo[0] to issue a certificate, but after successfully getting a certificate my site failed the SSL Labs test[1] with an 'unknown CA' error, even though I used the newer one that should have been trusted. It was probably down to user error and the additional complexity of denying sudo privileges for the set up script, but it t…

You need to present your full certificate chain and not only your public cert.

I'm running a certificate generated with Let's Encrypt on one of my sites and I've got an A+ result: https://www.ssllabs.com/ssltest/analyze.html?d=datasnitch.co...

Re: Public Beta: December 3, 2015

#53

Post by pilif »

discreditable wrote: post #5

I am beginning to wonder how much effect Let's Encrypt will really have on wide TLS deployment. A very large portion of the web is stuck at shared hosting services, such as Go Daddy, Lunarpages, et al. These services generally charge for TLS hosting, and due to the 90-day issuance on Let's Encrypt certificates it seems somewhat infeasible to use their certificates on shared hosts which offer very limited (if any) she…

I would imagine that shared hosting providers will just request the certificate for you in the future. Remember: This is about domain validated certs, so there's zero difference whether you request the certificate or whether your hoster does it for you.

Re: Public Beta: December 3, 2015

#54

Post by bmelton »

kevinreedy wrote: post #18
tombrossman wrote: post #10

I'm really pleased to see this initiative and I've used the private beta with letsencrypt-nosudo[0] to issue a certificate, but after successfully getting a certificate my site failed the SSL Labs test[1] with an 'unknown CA' error, even though I used the newer one that should have been trusted. It was probably down to user error and the additional complexity of denying sudo privileges for the set up script, but it t…

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.netcra…

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

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

Re: Public Beta: December 3, 2015

#55

Post by geerlingguy »

Diamons wrote: post #11
atmosx wrote: post #8

Earlier quoted context omitted.

A VPS costs 5 bucks on DO and I've seen (can't remember where) a 3 USD/month offering. So it's rather cheap to move away from shared hosting nowadays. For me Let's Encrypt came out at the right time. They said they will automate the 90-day renewal process.

Side question, does anyone actually enjoy running a VPS? Between managing the sites on it, you have to maintain the VPS, keep it up to date, its prone to security bugs and flaws, etc. Am I missing something here? I remember setting up multiple VPSes on Linode / DO and it was always a painful process of installing the OS, installing the whole stack, configuring everything, setting up users / roles, firewalls, etc. On…

On a basic level, shell scripts to do the basic config work in a pinch. But if you can learn the basics of Ansible, setting up a new VM can take just a few minutes and not be painful at all. It's quicker for me to add a new VM and apply a few Ansible roles I've written for a new client site/app than to log into some shared hosting provider and click through their UI to do the same.

Re: Public Beta: December 3, 2015

#56

Post by AgentME »

ars wrote: post #38
kevinreedy wrote: post #18

Earlier quoted context omitted.

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.netcra…

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 shou…

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

Re: Public Beta: December 3, 2015

#57

Post by cpeterso »

Bedon292 wrote: post #36
flavmartins wrote: post #28

Anyone concerned with the amount of fraud that will come from this? Won't bad actors utilize this to https all of their phishing sites?

These certs are to verify you control the domain name, not that you are who you say you are. Those certificates are much more complicated and expensive. See https://letsencrypt.org/2015/10/29/phishing-and-malware.html for more information

What is the value of checking Google's Safe Browsing API before issuing a certificate when the browser can/should use the same Safe Browsing API to block the phishing website? Move the policy to the user agent.

Re: Public Beta: December 3, 2015

#58

Post by tedchs »

bmelton wrote: post #54
kevinreedy wrote: post #18

Earlier quoted context omitted.

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.netcra…

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?

Re: Public Beta: December 3, 2015

#59

Post by mappu »

bmelton wrote: post #54
kevinreedy wrote: post #18

Earlier quoted context omitted.

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.netcra…

Does Google still penalize short-term / soon-expiring SSL certs in search rankings? Edit: this does not appear to be a thing that happens.

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

Re: Public Beta: December 3, 2015

#60

Post by bmelton »

tedchs wrote: post #58
bmelton wrote: post #54

Earlier quoted context omitted.

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.

Post reply on HN