Live data from Hacker News

Let's Encrypt makes certs for 30% of web domains

leebutterman.com

71–80 of 147 posts

Re: Let's Encrypt makes certs for 30% of web domains

#71

does anyone care that letsencrypt and other CAs are sharing their certificate requests to indexers? It allows someone to discover every one of your HTTPS certificates that you've requested. For instance, here is some free rabbitmq clusters to use... https://censys.io/certificates?q=parsed.extensions.subject_a... Default password of guest/guest works on http://rabbitmq.avtomain-crypto.com/#/

Yes I do care, and I agree that they should be doing so: I expect that CAs share these to Certificate Transparency logs, it’s a requirement to so that we can accurately find misissued certificates.

Re: Let's Encrypt makes certs for 30% of web domains

#72
post #59

Earlier quoted context omitted.

Let's Encrypt goes down, certs can't be renewed, people can't access websites securely (or at all if HSTS was used).

Good practice says that you should be renewing your certs when they have about 10% of their lifetime left, just in case this exact thing happens with whoever your provider might be. It's unlikely they would be down for so long that certs would actually expire.

I don't think a percentage is the best way to think about it. There is a lot of variability in lifetimes and the time it takes to resolve issues is not related to the lifetime of the cert.

Just pick a discrete number of days before expiration such that you have a comfortable amount of time to deal with issues.

We (Let's Encrypt) recommend renewing with 30 days left, so every 60 days. If your system is automated like we recommend that shouldn't be burdensome, no reason to do it less often than that.

Re: Let's Encrypt makes certs for 30% of web domains

#73
post #72
post #59

Earlier quoted context omitted.

Good practice says that you should be renewing your certs when they have about 10% of their lifetime left, just in case this exact thing happens with whoever your provider might be. It's unlikely they would be down for so long that certs would actually expire.

I don't think a percentage is the best way to think about it. There is a lot of variability in lifetimes and the time it takes to resolve issues is not related to the lifetime of the cert. Just pick a discrete number of days before expiration such that you have a comfortable amount of time to deal with issues. We (Let's Encrypt) recommend renewing with 30 days left, so every 60 days. If your system is automated like…

Also, Nagios/Icinga has a handy certificate checker in check_http. If that is a bit too much then logwatch the log and notify on the box itself.

Re: Let's Encrypt makes certs for 30% of web domains

#74

can someone please share how they deploy/distribute Let's encrypt certificates with auto renewal on load balanced multiple EC2 servers for the same dns name. I had tried this a while but had to give up and just bought SSL certs which I then include in my EC2 image.

Have you tried using Caddy? It handles automatic HTTPS (a.k.a Let's Encrypt) renewal across a fleet. https://caddyserver.com/docs/automatic-https#fleet

Caddy seems nice but I am way too invested in Nginx

Re: Let's Encrypt makes certs for 30% of web domains

#75
post #6

The GCP self-serving platform for certs is very welcome, but still kinda janky. You end up waiting hours for their batch jobs to run at unknown cycles. Let's encrypt is awesome because it's instantaneous! You'd think Google would understand that aspect. Edit: GCP people: Please give us a an explicit "retry" button to press when we've set up the DNS records. (I'm talking about the Google Cloud Balancing Service here.…

> The GCP self-serving platform for certs is very welcome, but still kinda janky. You end up waiting hours for their batch jobs to run at unknown cycles.

Have you noticed where they get the certs from? Let's Encrypt! So there's really no reason for that.

Re: Let's Encrypt makes certs for 30% of web domains

#76
post #64
post #16

Earlier quoted context omitted.

What problems would decentralization solve here?

Limiting a bit the impacts if Let's Encrypt is compromised in any way. If Let's encrypt is compromised, either by being able to issue certificate for arbitrary domains or if the CA itself is compromised, the impact would be huge given the current number of certificates signed by it and this number is likely to grow in the futur. With several CAs in different organizations, you have a far lower risk of seeing all the…

What exactly happens if a CA is compromised (private keys stolen etc)? Wouldn't existing certificates before the compromise date still be valid?

Re: Let's Encrypt makes certs for 30% of web domains

#77

can someone please share how they deploy/distribute Let's encrypt certificates with auto renewal on load balanced multiple EC2 servers for the same dns name. I had tried this a while but had to give up and just bought SSL certs which I then include in my EC2 image.

If your load balancers are AWS load balancers, you are doing it wrong. AWS provides their own free certificates that work the load balancer and they handle renewal as well. Let's Encrypt would be an unnecessary additional dependency and complexity. (At least if you are comfortable terminating your SSL at the load balancer. If you plan to use SSL between the AWS LBs and your EC2 instances, then AWS certs don't work th…

I stopped using AWS load balancer as I found that it was costing me more than my server, which are cheap as I normally use a fleet of spot instances . Also this is not corporate funded but my own money -- so I am very cost sensitive

Re: Let's Encrypt makes certs for 30% of web domains

#78
post #58
post #22

Earlier quoted context omitted.

Competition is always good. For one, a completely decoupled and separately managed system on a different stack would improve availability of ACME-based certificates. It would also reduce the concentration of trust in one entity. While LE is awesome, the target on their back is only getting bigger. For what it's worth, I'm pretty sure even Let's Encrypt wants to see competitors to Let's Encrypt.

> It would also reduce the concentration of trust in one entity. No it wouldn't. If there are 9999 CAs, you need to trust every single one of them. A better argument for having multiple CAs is that it would increase resilience (against takedowns, bugs, money running out, etc.)

I think you’re interpreting my comment about trust too literally. If you’re talking about “Web PKI root of trust” trust then yes, having two CAs just means you’re trusting two third parties without reducing trust in either. I was using the term more broadly and more narrowly... like, trusting them to be good stewards, trusting them with PII, and trusting them to not configure their DNS resolvers to use NSA-controlled DNS. They have more power and more control and become a more attractive target and more susceptible to corruption because the stakes are higher. Maybe I should have said “concentration of control”. If one CA owns 90% of issuances they’ll be able to push their agenda, for sure.

To be clear, all of the evidence shows that LE uses this power only for good. But that’s the threat. 30% market share is probably fine. 90% or 100% would be scary.

Re: Let's Encrypt makes certs for 30% of web domains

#79
post #39

Earlier quoted context omitted.

Yeah the software is open source, any other CA has the ability to pick it up ajd implement a similar service.

Just so people don't get an oversimplified view of what it takes to start a CA from this comment, you will have much bigger challenges than access to application software. Your first issue will be securing millions of dollars per year for the staff that it takes to run the CA responsibly. Your next issue will be getting trusted by browsers. Also, the open source Let's Encrypt CA software is tailored for how we do thi…

Well, that's why the comment is "any other CA" rather than "anyone".

Starting yet another CA is definitely not to be taken lightly.

Re: Let's Encrypt makes certs for 30% of web domains

#80
post #72
post #59

Earlier quoted context omitted.

Good practice says that you should be renewing your certs when they have about 10% of their lifetime left, just in case this exact thing happens with whoever your provider might be. It's unlikely they would be down for so long that certs would actually expire.

I don't think a percentage is the best way to think about it. There is a lot of variability in lifetimes and the time it takes to resolve issues is not related to the lifetime of the cert. Just pick a discrete number of days before expiration such that you have a comfortable amount of time to deal with issues. We (Let's Encrypt) recommend renewing with 30 days left, so every 60 days. If your system is automated like…

For what it’s worth, I’ve run into some issues with this guidance from you guys as I’ve been building out a private CA with ACME support. A lot of ACME clients have hard coded renewal at 30 days prior to expiration, which makes them pretty worthless for managing short-lived private certificates. Using a percentage might not encode a fixed SLA very well, but as a default it does accommodate various lifetimes well.

I can see pros/cons either way, just thought you might be interested in this feedback.

Post reply on HN