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

141–150 of 166 posts

Re: Let's Encrypt root certificate trusted by Mozilla

#141

Post by x1798DE »

icebraining wrote: post #65
aroch wrote: post #58

Earlier quoted context omitted.

That doesn't prevent domain enumeration for your application though. Once you publish an application, anyone using it can find the address its hosted behind

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

I thought sandstorm was a self-hosted thing. Why do the certs need to be signed by a public CA at all? A self-signed certificate is fine (and in some ways better than a public CA) when you can verify the source yourself because you generated it.

Re: Let's Encrypt root certificate trusted by Mozilla

#142

Post by eeeeeeeeeeeee »

dimino wrote: post #114
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-...

I feel like this is one of those "faster horse" moments. You don't need a wildcard cert! Just get certs for each one of your subdomains, even internally.

Some people are using dynamic dns records, so the list of subdomains is not static. This is where wildcard ssl is perfect. And what if you have hundreds or thousands of subdomains? It unnecessarily bulks up your configuration as you have to do a cert per site instead of a single one.

Re: Let's Encrypt root certificate trusted by Mozilla

#143

Post by kentonv »

x1798DE wrote: post #141
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.

I thought sandstorm was a self-hosted thing. Why do the certs need to be signed by a public CA at all? A self-signed certificate is fine (and in some ways better than a public CA) when you can verify the source yourself because you generated it.

Sure, you can use a self-signed cert, if you don't mind going through the process of installing the cert into every browser that you'll use to access the server.

But Sandstorm is designed for sharing and collaboration. For example, you might write a document in Etherpad which you want other people to comment on. It may be tough to get the right certificate into all your friends' and family's browsers.

(Note that Sandstorm actually provides free wildcard certificates if you are OK with using a subdomain of sandcats.io.)

Re: Let's Encrypt root certificate trusted by Mozilla

#144

Post by ubernostrum »

discreditable wrote: post #103
joecool1029 wrote: post #94

Earlier quoted context omitted.

If you read through the linked bug inside the bug, I think they had to do that as part of the review process. They had to wait 90 days after the initial cert was issued to have it reviewed. Since LE only issues 90 day certs this means they'd have to review an expired one. The whole Mozilla CA review process is a little crazy and the thread talks about ways they could reform it in the future. (overview: https://wiki.m…

It's funny because LE's stance has been that 90-day certs are cool because it is easy to automate renewal. However, no one bothered to set up renewal on their example server.

The use of an expired certificate on that domain is deliberate due to the circumstances around the procedures required to get trusted. Here's the full explanation:

https://www.reddit.com/r/programming/comments/4wb7c2/lets_en...

Re: Let's Encrypt root certificate trusted by Mozilla

#145

Post by geofft »

tracker1 wrote: post #129
geofft wrote: post #122

Earlier quoted context omitted.

If you're running in a standard config. If your config is nonstandard (you have multiple servers that need a cert to stay in sync, you're not running a common web server, you're on a private network, you're pinning a client to a public key etc.), it's still easy but not a single command. For sufficiently nonstandard setups, it's often easier to do the commonplace email-based verification than make Let's Encrypt work.…

Why not terminate public TLS/SSL at the proxy level, then use internal PKI for proxy to backing servers... It's be easy enough to have a single ACME server that handles all acme requests forwarded from the firewall(s), then federate that configuration out as needed.

The configs I was describing in my first paragraph don't involve proxies. Adding proxies doesn't really solve the problems, and even if it did, writing an in-house ACME server is a lot more work than "run this magic command".

The config I'm describing in my second paragraph is for internal web services within a corporate network, that aren't public-internet-facing at all. I don't want to have all my clients (including people's phones) add an internal PKI because that's just bad security practice.

Re: Let's Encrypt root certificate trusted by Mozilla

#146

Post by peteretep »

greggman wrote: post #138
xienze wrote: post #113

Earlier quoted context omitted.

I mean it kind of makes sense doesn't it? If you need enough certs (> 20 per week) to hit the rate limit, you're probably running some sort of business -- in which case you probably shouldn't be depending on a free service and can likely afford the cost of wildcard certs.

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?

Re: Let's Encrypt root certificate trusted by Mozilla

#147

Post by AndyMcConachie »

mieko wrote: post #134
rahkiin wrote: post #133

Earlier quoted context omitted.

Problem is, that if ypu can prove you have access to someuser.github.com, it does not mean you have access to .github.com. Reversely, if you have access to .cs.mit.edu you might want a cert for it. So you cant give a wildcard using one subdomain test, nor can you simply test every domain. So they are looking in DNS verification. Given you have access to dns. But that also gives problems, as shown above. Tldr: one ver…

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 Encrypt into getting certs for domains they don't control.

Re: Let's Encrypt root certificate trusted by Mozilla

#148

Post by tracker1 »

pfg wrote: post #136
tracker1 wrote: post #128

Earlier quoted context omitted.

Depends on where you want SSL termination, and if you want it federated out... The default Let's Encrypt project(s) integration tooling afaik isn't used by many people, but there have been a lot of tools to do more simple ACME integration into various web servers, reverse proxies and other configurations. It's pretty cool. I'm overall, very happy that it works at all... Some things I'd like to see... Namely, automati…

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.

Re: Let's Encrypt root certificate trusted by Mozilla

#149

Post by arcticfox »

gist wrote: post #96
arcticfox wrote: post #72

Earlier quoted context omitted.

HN, of all places, may take the trouble to actually make a small statement however. People would actually notice here.

> may take the trouble to actually make a small statement however Another move in the direction of political correctness and making decisions according to optics. Have you considered valid business purposes for a company doing a particular act or are you just deciding that everyone thinks this was a "scumbag" action?

Supporting a non-profit organization working for a more secure Internet could easily fall under a "valid business purpose" for a site like HN.

HN's entire business mandate, such as it is, seems to be to encourage technological growth in the interest of profiting tangentially off the growing pie.

Edit: as for whether Comodo had a "valid business purpose" for the action, sure, in the same sense that patent trolls have a valid business purpose. Read this statement by their CEO: https://forums.comodo.com/general-discussion-off-topic-anyth...

It's surreal. He tries to shift the blame to Let's Encrypt for choosing 90 days as their default certificate expiration date, somehow implying that 90 days is Comodo IP.

Re: Let's Encrypt root certificate trusted by Mozilla

#150

Post by grahamedgecombe »

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…

CAs are forbidden from issuing a cert for * .co.uk. The Baseline Requirements say:

> The CA MUST establish and follow a documented procedure that determines if the wildcard character occurs in the first label position to the left of a "registry-controlled" label or "public suffix" (e.g. "* .com", "* .co.uk", see RFC 6454 Section 8.2 for further explanation).

This basically means that the CA should check the Public Suffix List before they issue a wildcard.

As a 'just in case' measure, most modern browsers also reject certs where the wildcard is directly below something on the PSL.

(sorry for the spaces after the asterisks, HN seemed to like converting big chunks of the post to italics)

Post reply on HN