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

Let's Encrypt root certificate trusted by Mozilla

bugzilla.mozilla.org

Post reply on HN
Print view View original

151–160 of 166 posts

Re: Let's Encrypt root certificate trusted by Mozilla

#151

Post by patates »

tracker1 wrote: post #125
icebraining wrote: post #65

Earlier quoted context omitted.

> publish Sandstorm is a platform for personal computing; each person runs their own applications, much like in a PC. Also, applications don't get hostnames; each document (or equivalent) in the application gets its own hostname.

For such applications, there are plenty of relatively inexpensive paid options for wildcard certs. I don't think this is something Let's Encrypt should solve. I'd rather see them invest more time into supporting dynamic dns provider domains better, which imho is a much larger issue for small/hobby/free projects.

I'm ready to pay a reasonable amount for a wildcard cert to use with some hobby projects. Is there a trustworthy cheap wildcard cert provider which is not Comodo?

Re: Let's Encrypt root certificate trusted by Mozilla

#152

Post by grahamedgecombe »

devy wrote: post #21
xutopia wrote: post #15

The one thing stopping adoption for a lot of people is wilcard support. https://community.letsencrypt.org/t/please-support-wildcard-...

It's been discussed in details here the reason why they don't support wildcard: "doing domain validation for wildcard certificates is not currently in the ACME spec because it's a hard problem."[1] LetsEncrypt CA allows Subject Alternative Names (SAN), the true need for an unlimited sub-domains TLS cert vs. a SAN TLS cert is minimum, given Certbot's automation capability. [1]: https://github.com/certbot/certbot/issue…

Wildcards are in the version of the ACME spec at https://letsencrypt.github.io/acme-spec/:

> A server MAY consider a client authorized for a wildcard domain if it is authorized for the underlying domain name (without the “*” label).

Although this seems to be gone from https://ietf-wg-acme.github.io/acme/, which I think is the later version.

Re: Let's Encrypt root certificate trusted by Mozilla

#153

Post by mieko »

AndyMcConachie wrote: post #147
mieko wrote: post #134

Earlier quoted context omitted.

That's not how domain-validated wildcard certificates from any CA have ever worked, and it's not how any proposed wildcard-supporting future LetsEncrypt would work. I can, today, get a valid certificate for myname.github.io (getting GitHub to serve it is a different issue, but from an MITM, proof of ownership, and CA/Browser Forum standpoint, it's properly assigned.) That's not surprising or weird, and it's exactly h…

Are you saying you're OK with co.uk getting a cert for foo.co.uk, even though they're under different administrative control? I'm not OK with that. I understand that other CA's provide wildcard certs, but frankly I see them as a giant problem. It's bad enough that I only have to have something listening on port 80 to prove that I control a domain. Let's not make it more attractive for people to start fooling Let's En…

> Are you saying you're OK with co.uk getting a cert for foo.co.uk, even though they're under different administrative control?

This argument hasn't been made, or hinted at, by anyone, anywhere in this thread. And $50 isn't the difference between that being possible or not.

Re: Let's Encrypt root certificate trusted by Mozilla

#154

Post by saynsedit »

jerf wrote: post #107
saynsedit wrote: post #100

Earlier quoted context omitted.

Source? I remember reports in the past decrying CAs for issuing certificates for phishing sites in the style of "gooogle.com" etc.

That's properly understood as a variant of getting a certificate of a domain you don't own, for practical purposes. And the point there is still that the "bad guys" shouldn't be able to get a cert that appears to identify them as Google , not that the bad guys can't get a cert . It's two different things. It is not a bug for Let's Encrypt to hand out certs to "bad" people.

That's fair and makes sense. Still, do you have a source for that type of CA policy? With all due respect, I can't tell if this is just your opinion or a codified threat model.

Re: Let's Encrypt root certificate trusted by Mozilla

#155

Post by icebraining »

tracker1 wrote: post #125
icebraining wrote: post #65

Earlier quoted context omitted.

> publish Sandstorm is a platform for personal computing; each person runs their own applications, much like in a PC. Also, applications don't get hostnames; each document (or equivalent) in the application gets its own hostname.

For such applications, there are plenty of relatively inexpensive paid options for wildcard certs. I don't think this is something Let's Encrypt should solve. I'd rather see them invest more time into supporting dynamic dns provider domains better, which imho is a much larger issue for small/hobby/free projects.

What's the problem with dynamic dns provider domains?

Re: Let's Encrypt root certificate trusted by Mozilla

#156

Post by nailer »

devishard wrote: post #82
stephenr wrote: post #71

Earlier quoted context omitted.

Can you elaborate?

The identity verification is essentially a phone call for most CAs, which verifies nothing. Some CAs do better, but it only takes a few bad apples, and in this case it's not a few bad apples--it's mostly bad apples.

Before that phone calls happens a bunch of other work has to be happen first - see the other answer for details.

All CAs are audited against the same guidelines: they should be requiring the same levels of proof. From what I've seen (our tech works with different EV providers) that's generally the case.

While EV is certainly more than a phone call, there are certainly flaws. The EV guidelines change over time and I'd like to get them tightened with additional requirements in particular circumstances.

Re: Let's Encrypt root certificate trusted by Mozilla

#157

Post by nailer »

koolba wrote: post #51
nailer wrote: post #34

Earlier quoted context omitted.

Heads up: I work for a company that speeds up the background checks used for EV. Tying real world identities to public keys is very much a part of crypto. Windows does it with package signing and EV, Debian does it with people holding up their passports at Linux events, and web sites do it with EV HTTPS. And yes, we (CertSimple) are looking at Certbot support for EV.

> Heads up: I work for a company that speeds up the background checks used for EV. How much faster? The one time I've gotten an EV cert it took a couple hours to get verified. Didn't seem too long at all and compared to the time to plan the swap out of the cert in production, the wait was a non issue. The verification itself was a joke though. It was basically just a phone call asking "Are you X? Ok great! Here's you…

> How much faster?

https://certsimple.com/about

> The verification was basically just a phone call asking "Are you X? Ok great! Here's your cert!"

Congratulations, you have an active registered company that was already well known to qualified third parties. Before that phone call happens, the CA has to verify your existence and status by government records and a qualified third party. There are additional steps for certain company structures. They don't just call you and you get the cert - and people are often rejected.

> Joe User isn't going to look at the details and validation chain of a certificate.

Nobody is expecting users to look at the cert details or verification chain. Just the name in middle of the address bar.

From the front page of HN right now:

https://hackernoon.com/this-is-what-apple-should-tell-you-wh...

https://d262ilb51hltx0.cloudfront.net/max/800/1*DzlpfS4cesC6...

"The green text on the address bar shows the site really belongs to Apple Inc."

Re: Let's Encrypt root certificate trusted by Mozilla

#158

Post by nailer »

scrollaway wrote: post #50
nailer wrote: post #34

Earlier quoted context omitted.

Heads up: I work for a company that speeds up the background checks used for EV. Tying real world identities to public keys is very much a part of crypto. Windows does it with package signing and EV, Debian does it with people holding up their passports at Linux events, and web sites do it with EV HTTPS. And yes, we (CertSimple) are looking at Certbot support for EV.

FYI: Your server's vulnerable to CVE-2016-2107 and is getting an F from ssllabs. https://www.ssllabs.com/ssltest/analyze.html?d=certsimple.co...

Now back to our previous A+. Thanks for the heads up.

I had been logging in to update but the rate of new, severe openssl vulnerabilities - and the risk of missing one, fairly obviously - is high enough I'd rather just apply them immediately. yum-cron's also now enabled to apply openssl updates as soon as they're issued.

Re: Let's Encrypt root certificate trusted by Mozilla

#159

Post by greggman »

peteretep wrote: post #146
greggman wrote: post #138

Earlier quoted context omitted.

I'm not running a business. I'm writing an open source library that needs certs because browsers are banning features unless served from https http://docs.happyfuntimes.net One cert per game * one hit game = need 10s of thousands of certs. But even without a hit game a single game jam would hit the limits For reference here is an example of a similar problem and solution but it required $$$$$$ https://blog.filippo.io…

> It is a problem that needs a cheaper solution at > least for open source projects. Maybe: games.example.com/foobarbarz instead of foobarbaz.example.com?

how would this help? Like Plex each game is running a local webserver on a user's home computer/apple tv/android tv/etc. It's those devices that need the certs in order to serve content to browsers on player's smartphones.

Re: Let's Encrypt root certificate trusted by Mozilla

#160

Post by pfg »

tracker1 wrote: post #148
pfg wrote: post #136

Earlier quoted context omitted.

Dynamic DNS providers that are on the Public Suffix List are essentially treated like TLDs in terms of rate limiting, meaning each client subdomain has a separate counter. They should probably be on the PSL anyway; browsers rely on it for cookie scoping.

True enough, but would be nice if it detected that the SOA IP corresponds to a public suffix dns provider. Also, not sure where to put public suffix list additions for such a provider... I was going to add bbs.io, as well as say the top 25 domains for freedns.afraid.org, but wasn't sure where to add them.

The process is described here[1]. It needs to be performed by the domain owner.

[1]: https://publicsuffix.org/submit/

Post reply on HN