Live data from Hacker News

Let's Encrypt has issued its first million certificates

eff.org

71–80 of 156 posts

Re: Let's Encrypt has issued its first million certificates

#71
post #2

> It is clear that the cost and bureaucracy of obtaining certificates was forcing many websites to continue with the insecure HTTP protocol I never realized this so clearly, but it's true. The biggest hindrance to security until LE was that certs were expensive and hard to install. I don't think it was so much the former as the latter. I'd gladly pay 10% more for my cert if it meant my server could renew automaticall…

> I'd gladly pay 10% more for my cert if it meant my server could renew automatically without me touching it at all.

I wrote a server that does this. Would be happy to have your feedback sometime: https://caddyserver.com - here's how it works with regards to Let's Encrypt certs: https://www.youtube.com/watch?v=OE5UhQGg_Fo&t=32m

Re: Let's Encrypt has issued its first million certificates

#72
post #27

The default LE client was kind of a pain to work with. The docker container was better but where it really helped was the Lego golang implementation. That one 'just works' and was super easy to setup behind nginx to run automatically. It also writes a nicer config dir.

Thanks for sharing your experience here, I'll go straight to lego when I go to set it up. It's hard to beat the simplicity of a Go binary for system tools like this.

How is a binary simpler then a script?

Re: Let's Encrypt has issued its first million certificates

#73

Earlier quoted context omitted.

If there only wasn't the limit of 5 certificates per domain per week [1]. [1] https://community.letsencrypt.org/t/rate-limits-for-lets-enc...

When it comes to rate-limiting, example.com and foobar.example.com are treated as completely separate domains.

I do not believe this is true. That rate limit applies to second-level domains and all subdomains.

Re: Let's Encrypt has issued its first million certificates

#74
post #61
post #58

Earlier quoted context omitted.

You need a domain name registered. Otherwise what would they issue the certificate for? You could buy a domain though, then have a local dns resolve it to your own machine. Alternatively you could use a self signed cert and sign it to localhost or whatever, then configure all your browsers to trust this certificate.

Is it possible to do without Chrome complaining about the validity of the self signed cert?

If you have a registered domain and get a DV cert from LE or anywhere else, chrome will not complain about the cert. If you self-sign it, chrome, or any other browser, will complain, unless you add your own CA to the trusted list on each device.

Re: Let's Encrypt has issued its first million certificates

#75
post #72

Earlier quoted context omitted.

Thanks for sharing your experience here, I'll go straight to lego when I go to set it up. It's hard to beat the simplicity of a Go binary for system tools like this.

How is a binary simpler then a script?

True Go binaries like lego[1] are statically compiled (zero external dependencies). No need to fuss about versions of installed dependencies, updates, package management, etc. You just run the binary and it just works.

[1]: https://github.com/xenolf/lego

Re: Let's Encrypt has issued its first million certificates

#76
post #35

Given that LE does certificate transparency, would it be possible to find out what their millionth certificate was?

CT doesn't seem that transparent. crt.sh only shows the certificate for one of my domains, despite them all having certs issued by the same CA on the same day. Go figure.

I'm assuming we're talking about CAs other than Let's Encrypt? In which case this is expected; not many CAs currently submit all their certificates to CT logs. It's only mandatory for EV certificates. The biggest source for Google's CT log servers is probably Googlebot, so unless your site is publicly available and crawlable, this is nothing unusual.

Re: Let's Encrypt has issued its first million certificates

#77
post #48

Earlier quoted context omitted.

given that LE takes just as much time and effort for initial set-up as a standard multi-year cert I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH - i.e. every server will configure itself right on first launch and keep itself that way. It's just going to take a long time to get there :)

> I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH It already is. Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception. That's the security model of SSH, and has the same assurances. It's just a terrible comparison. We can do better. A better comparison would be with DNSSEC... The way to simplify TLS deployment, while getting a better lev…

The symmetries between DNSSEC and LetsEncrypt are striking. Your account key is your KSK. Your cert is your ZSK... but instead of your webserver (in DNSSEC, your DNS server) doing rollover for you, you're depending on a pile of scripts, leaning on an already insecure DNS, and setting it up is still, comparatively, a pita.

As the Caddy server linked in another comment shows, nothing in LE requires you to depend on a "pile of scripts" to do roll-over for you, it's just early days.

Re: Let's Encrypt has issued its first million certificates

#78
post #37

Earlier quoted context omitted.

What are you talking about? My nginx ssl config is static as well. It looks at a specific path for my certs, which just happens to be a symlink managed my by letsencrypt tooling. You're going to have to renew anyway. Previously you would have to remember to do that once a year, or maybe once every two years. Now let's ignore the security implications of having certificates that are valid for a year for a moment, and…

"Once" assuming nothing randomly breaks while you're not looking. What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date? What if one of the (Python?) dependencies has a bug or breaks? What if LEs servers are being DDoS'd? Can you enumerate and account for all the failure scenarios? I've already botched things with acme-tiny&LE in several different ways. I'm not claiming these risks…

Let's Encrypt renews certificates after 60 days by default, giving you a 30-day grace period for outages, etc. Use a daily cronjob and monitor your certificates. Setup alerts if your certificates are closer than, say, 25 days to expiration. This should cover temporary outages, bugs, etc. - and the monitoring bit is no different from what you should already have even with manual renewal.

Re: Let's Encrypt has issued its first million certificates

#79

Earlier quoted context omitted.

I doubt it. CAs still have EV, wildcard, email, and code signing certificates that are often twice as expensive (or more) than their DV offerings. And some people will choose to pay for a DV cert just so they don't have to swap them out every 3 months anyway.

EV can die a fiery death. It is bullshit. I don't see a reason why LE can't issue wildcards in the future, though with their current setup they are even less important. Email certificates can be issued by LE as well. Code signing is the only one I see as problematic. In either case, I suspect that LE will take a huge bite out of CA's bottom lines, since there are a lot more DV certs out there than EV ones.

EV is what CA's was supposed to do but initially never did; a trusted third-party validation that checks if a online identity really match the real world identity. Its similar to PGP key-signing, but on a government/industry level.

The question I wonder is if CA's can actually survive on only doing their intended job, and if the green bar can sustain enough trust to be worth paying for.

Re: Let's Encrypt has issued its first million certificates

#80
post #29

Earlier quoted context omitted.

I personally find the hassle of installing, configuring and, crucially, testing , both LetsEncrypts scripts, and an accompanying cronjob, much more work and worry than a static nginx ssl config.

What are you talking about? My nginx ssl config is static as well. It looks at a specific path for my certs, which just happens to be a symlink managed my by letsencrypt tooling. You're going to have to renew anyway. Previously you would have to remember to do that once a year, or maybe once every two years. Now let's ignore the security implications of having certificates that are valid for a year for a moment, and…

I think you are underestimating the cognitive burden this added complexity puts on your ops person (maybe yourself)

I know for me, it was a choice between farting around with lets-encrypt for hours, or a $40 wildcard cert. so I went with the $40/year cert instead.

There are just too many choices for lets-encrypt with no super-simple how-to for people who don't know this stuff (like myself).

Post reply on HN