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

Milestone: 100M Certificates Issued

letsencrypt.org

Post reply on HN
Print view View original

171–180 of 197 posts

Re: Milestone: 100M Certificates Issued

#171

Post by eropple »

tokenizerrr wrote: post #156
cyphar wrote: post #136

Earlier quoted context omitted.

Yes, many services "seem to do it". The problem is how do you safely verify that a wildcard certificate is actually being given to the owner of that domain space? It's "trivial" to provide a certificate for a particular domain is owned by someone, but the same techniques don't work for wildcard certificates because now you're verifying only a single domain and providing certificates for an entire class of domains. If…

That SO post makes no sense to me. It claims: > The authentication test can't merely back down one level to mysub.example.com because that isn't covered by the cert requested, and may not be under the control of the requesting agent either. This just seems wrong. Performing the check like that seems to be a sane way to do it. If people can't control the base domain they have no business requesting a wildcard cert.

I regularly have subdomain zones delegated to AWS for Route 53 use without having direct control over the root domain. The idea that I must have direct control to assert control over a subdomain is pretty questionable.

Re: Milestone: 100M Certificates Issued

#172

Post by tokenizerrr »

eropple wrote: post #170
tokenizerrr wrote: post #162

Earlier quoted context omitted.

IPv4 addresses are relatively expensive. I encounter it quite often where a wildcard gets pointed to a single server (with single IP) which hosts multiple services. There are no security issues compared to a large SAN that I can see in such a situation.

I would submit, respectfully, that you're not being creative enough . When it comes to security, including phishing, it behooves all of us to not assume that permissiveness is a de facto positive.

Very helpful. Thanks.

Re: Milestone: 100M Certificates Issued

#173

Post by tokenizerrr »

eropple wrote: post #171
tokenizerrr wrote: post #156

Earlier quoted context omitted.

That SO post makes no sense to me. It claims: > The authentication test can't merely back down one level to mysub.example.com because that isn't covered by the cert requested, and may not be under the control of the requesting agent either. This just seems wrong. Performing the check like that seems to be a sane way to do it. If people can't control the base domain they have no business requesting a wildcard cert.

I regularly have subdomain zones delegated to AWS for Route 53 use without having direct control over the root domain. The idea that I must have direct control to assert control over a subdomain is pretty questionable.

If you don't have access, fine. You can't make use of this functionality. Stick with what is available today. Nothing lost. If you do have access, like 99% of the domains out there, you now get access to more functionality. Win-win.

Re: Milestone: 100M Certificates Issued

#174

Post by j_s »

dylz wrote: post #168
j_s wrote: post #135

Earlier quoted context omitted.

Ain't nobody got time for that! They might have " a few places around the internet " to verify from, but I doubt it is very diverse location-wise. And there's no way they're going to bother with doing it multiple times, for free.

> they're going to bother with doing it multiple times, for free You are aware you are talking about the cost of a single HTTP GET?

> You are aware you are talking about the cost of a single HTTP GET?

First, the conversation is about the possibility of multiple (not single) interactions, including protocols other than HTTP such as DNS.

Perhaps you're confusing a subset of what they currently do vs. coordinating the initiation of requests multiple times from a few places around the internet (per OP) supporting multiple protocols, aggregating and verifying the responses, etc. -- all within a reasonable timeframe at scale with Internet infrastructure level high availability (while protecting against malicious misuse)?

I hope this is enough to explain that no, that's not what I was talking about. But thanks for taking the time to reply!

Re: Milestone: 100M Certificates Issued

#175

Post by collinmanderson »

duskwuff wrote: post #154
collinmanderson wrote: post #125

Earlier quoted context omitted.

StartSSL effectively died, and I assume LetsEncrypt was part of the reason.

No... the real reason StartSSL died was because they were acquired by another CA, Wosign, which had a number of serious security and management issues. These issues led to both CAs being distrusted by all major browsers. https://wiki.mozilla.org/CA:WoSign_Issues

Right, but why did Eddy Nigg sell StartSSL to WoSign?

My guess is Heartbleed made him re-consider whether he wanted to keep doing ssl/tls certs, and once Let's Encrypt came along he started looking for a way to get out of it.

Re: Milestone: 100M Certificates Issued

#176

Post by jazoom »

perlgeek wrote: post #164
gator-io wrote: post #89

The biggest issue we've had is the short expirations. We have 51 certificates in our organization and do not want to rely on auto-renew. As our community project, we built a totally free to the public service to monitor certs and alert you when they get close to expiration or are invalid, etc: https://letsmonitor.org Feel free to use it for any certs.

Thanks for providing that! I've been using another free certificate monitor, but it assumes 1 year validity and the lowest possible warning threshold is 30 days, which isn't all that useful when working with Let's Encrypt. So, you have another happy user now :-)

This one also works: https://sslping.com

Re: Milestone: 100M Certificates Issued

#177

Post by doublerebel »

tskaiser wrote: post #25
m12k wrote: post #14

Earlier quoted context omitted.

If you're comfortable with said cronjob having access to your private key

If the private key is only used for this purpose, and the cronjob as well as the key only reside on the server, is the security of the key then not a moot point if the server is breached? Genuinely curious.

I don't store keys on the filesystem for two reasons:

* Security in case of a breach

* Ephemeral containers

I try never to store secrets in an unencrypted cloud filesystem, and decrypted secrets should be in memory, if possible.

I store my LE keys in Vault using ten-ply-crest, so access is very restricted yet storage has redundancy. Vault is dead easy to integrate with any system.

I have been really surprised how many LetsEncrypt tools store certs and keys in the filesystem, other than "that's the way it's always been done".

Also if the keys are stored only on one cloud server, that means there ought to be a backup somewhere, so now there are two potential leaks instead of one.

With Vault only ten-ply-crest and Fabio access the keys. No human ever gets near them.

Re: Milestone: 100M Certificates Issued

#178

Post by gator-io »

j_jochem wrote: post #90
gator-io wrote: post #89

The biggest issue we've had is the short expirations. We have 51 certificates in our organization and do not want to rely on auto-renew. As our community project, we built a totally free to the public service to monitor certs and alert you when they get close to expiration or are invalid, etc: https://letsmonitor.org Feel free to use it for any certs.

Out of interest, what makes you not want to rely on auto-renew?

It has never worked right on Windows servers (don't know why). And it is simply a check of last resort if something goes wrong.

Re: Milestone: 100M Certificates Issued

#179

Post by gator-io »

danielsamuels wrote: post #110
gator-io wrote: post #89

The biggest issue we've had is the short expirations. We have 51 certificates in our organization and do not want to rely on auto-renew. As our community project, we built a totally free to the public service to monitor certs and alert you when they get close to expiration or are invalid, etc: https://letsmonitor.org Feel free to use it for any certs.

Why would you not use the auto renew system?

Oh, and it also does some validity checking.

Re: Milestone: 100M Certificates Issued

#180

Post by jpalomaki »

Asdfbla wrote: post #108
koolba wrote: post #43

SSL certificate from a traditional provider valid for a year: $10. SSL certificate from a traditional provider valid for two years: $20. Automated SSL certificate generation and deployment via LetsEncrypt with zero human intervention and more importantly zero human intervention to renew it going forward - priceless . --- That's the real value for me. At $10/cert, that's not even a rounding error. But manually generat…

What's the justification of traditional providers to charge for the certificates? Do they offer services or extended certificates that "Let's encrypt" doesn't or is it just a matter of "no one tried to offer it for free before"?

Among other things they provide certs which are valid up to three years. Let's Encrypt certs are short term. There idea is to auto renew, but sometimes that is difficult to implement.
Post reply on HN