Hacker News Reader

Comment by kalleboo | Hacker News Reader

Note to self: Use subdirectories, not subdomains in the future

The other issue with subdomains is that some customers will insist on typing "www." in front of every domain. Since the wildcard cert won't match, those customers will see an error.

I feel like TLS certificates are fundamentally misdesigned there. It should be possible to have a wildcard certificate that matches all subdomains under a domain, no matter how many layers deep.

Well if it wasn't for someone buying <star>.com back in the day, we probably could have them. Oh and then buying <star>.<star>.com after browsers banned that one, which led to RFC 6125 rule clarifications and restrictions.

Hey, I'm pretty sure that the first real domain name hack was sex.net, which as the proud owner of ex.net [PS: or was it sexnet.com, as we also have exnet.com?] caused some upset for a while, though mainly to disappointed one-handed typists I believe... B^>

BTW, did I blink and miss the "It really is all faster over HTTP/2, even given TLS" bit? My testing for my tiny lightweight sites close to their users (the opposite of what you're dealing with) is that HTTP/2 is slightly slower overall. Even with Cloudflare's advantages such as good DNS. And with the pain of cert management...

http://m.earth.org.uk/note-on-carbon-cost-of-CDN.html

Anyhow, thanks for the warts-n-all.

I would imagine the more resources your page has, the more benefit you can get from HTTP/2 because of Server Push. So if you're comparing a tiny lightweight site, I'm guessing you can't benefit as much from Server Push.

I have relatively little that would benefit from push; basically a tiny hand-crafted CSS file that I currently inline because HTTP/1.1 and even HTTP/2 overhead for having it separate may be too high.

> which as the proud owner of ex.net

haha, that page is a priceless timecapsule:

Use the Java applet below to search ExNet's main Web pages.

When the ``Status'' indicator stops flashing and says ``Idle'', type key words in the ``Search for:'' box.

The ``Results:'' box will show you the documents that matched your key words, the best matches coming first in the list. Click on any line in the ``Results:'' box, and that document should appear in a new browser window in a few seconds. When you are finished with that document, you can close it without killing your browser.

That code did search-by-word from (IIRC before Google existed, ie Netscape 2) right up until Java applets were dropped, across all compliant browsers AFAIK. It did roughly what G's live search now does.

browsers use domains for everything from connection limits to data storage. if you use folders everything will be shared.

Note to self: Use subdomains, not subdirectories in the future

Wait...

The real LPT here is using different domain altogether..

But wait, in that case browser will make another DNS fetch and open up a separate http connection!

TLS kills this kind of "cool" features which is kind of sad :( Unless you can afford wildcard certs.

What's the argument behind LetsEncrypt not doing that? Extended Validation stuff?

Probably their agreements with their partner CAs. Given that those partners sell wildcards themselves...

Their "Let’s Encrypt Authority X3" intermediate is signed by their own root (ISRG Root X1). See https://letsencrypt.org/certificates/.

Subdomains were killed by SEO a long time ago (afaik, Google does not transfer domain PageRank credit to subdomains), so this is not limited solely by the cost of wildcard certs.

But this is orthogonal to the issue of LetsEncrypt not delivering wildcard certs.

There's a long StackExchange answer about this: https://security.stackexchange.com/a/158164

But it boils down to there being no practical way for Let's Encrypt to automatically validate that a wildcard certificate is safe to issue.

It's a long answer that completely fails to address the possibility of validating ownership of the domain itself by e.g. adding a TXT record, which the ACME protocol already supports.

The general point is that being able to control the parent domain doesn't necessarily mean you control all possible subdomains as well. You need to prove ownership, not just control. Here's the relevant bit from the SO answer:

> If I have ownership of the parent domain example.com then I can freely create and control anything as a subdomain, at any level I choose. Note that here "ownership" is distinct from "control", which is what is validated by the ACME protocol.

How would they prove that you own every subdomain?

I'm not sure I understand the question. If you own something.com then you automatically own any possible subdomains.

The Let's Encrypt process is about validating control of the content on a domain, not about OWNERSHIP of the domain. To get a cert, you just have to be able to update a file at a Let's Encrypt specified location on the domain. This is only proving that you are in control of the website for that specific domain, not that you are in control of the DNS for the entire domain and all subdomains.

Of course if I own a domain, I own all the subdomains. However, being in control of the site served at port 80 for a domain does not mean I own it.

But the ACME protocol, the automation underpinning Let's Encrypt, supports validation via a DNS challenge (adding a specific TXT record to the domain). Would it not be possible to issue wildcards if-and-only-if a DNS challenge succeeds?

I think you're right.

They cost like $199 or less. It's an anoying tax, but they do offer a lot of options, so they're often worth it.

Way less than that. I've got a wildcard SSL cert for my domain for $60, although that was an add-on to the domain itself and hosting, purchased from the provider of the latter.

Reply on news.ycombinator.com