Hacker News Reader

Comment by ck2 | Hacker News Reader

Everyone repeat after me, wildcards, wildcards, wildcards.

(just hoping they will appear next year)

One more nail in the coffin of the ssl cert mafia.

While I too would like to see wildcards, doesn't the fact that you can programmatically obtain a cert for a subdomain obviate most of the wildcard needs? Sure it's a bit more difficult but if your service has some form of sorts to make a subdomain work for a specific word, surely it can request the cert at that time. Having said that, obviously keeping track of only one cert and not having to build this into your apps is much more preferred.

This comes up when you are running a multi-tenant app with many tenants; github.com is a good example. You can sign up as "dude.github.com" or "me234.github.com" and so on. So, Github can either a) obtain wildcard SSL cert for "*.github.com" once, and then present it to tenants, and control access with the "domain" property of the cookie, and don't worry about SSL cert until next year's renewal time, or 2) apply to some authority for XXX.github.com every time the new tenant signs up. Well, 2) makes you reliant on "some authority" every time new customer signs up, (hopefully many times a day!) which is not so very good IMHO. Just my 5c.

Without wildcards you can't use the automated tool to pre-provision new servers, for example.

Say 1.example.com is in production and is to be swapped for new1.example.com which is in staging.

new1 can't obtain a useful cert from Let's Encrypt until it becomes 1 in Internet-facing DNS. So you have a service discontinuity whilst moving 1 -> old1 and new1 -> 1 and then applying for the cert.

I appreciate that the set of people managing such issues probably aren't the target market ( they also won't be running an as-root tool to make automated changes on their edge servers... ) but it's an example of why wildcards are so useful.

Not all subdomains are known in advance - DNS has wildcards too.

I can absolutely understand the need for this, but until then with a bit of code and the automated workflow you could make requests for new subdomains on-the-fly.

They won't support those on launch?

Altough because of SNI (https://en.wikipedia.org/wiki/Server_Name_Indication) the need for wildcard certificates has greatly diminished.

Agreed.

SNI and SubjectAltName [https://en.wikipedia.org/wiki/SubjectAltName] mixed with the simplicity of issuing a new certificate using LetsEncrypt [https://letsencrypt.org/howitworks/] all but eliminate the need for wildcards.

Not sure if they'll amend their certificate policy or not. My guess is because their process is automated, they want to confine their certificate issuance to specific domains/sub-domains and not wildcards. It mitigates some repercussions in the event of a compromised cert.

Pg. 24 of the Certificate Policy:

For DV-SSL The Issuer DN of a DV-SSL Certificate shall be its Issuer’s subject DN. CAs shall include FQDNs or IP Addresses of the Device in the subject Alternative Name extension. The Subject Alternative Name extension may contain more than one instance of the name form. CAs may include a FQDN or IP Address in the subject DN for backwards compatibility, but this name shall be also included in the Subject Alternative Name extension. Wildcard names are not permitted

https://letsencrypt.org/documents/ISRG-CP-May-5-2015.pdf

The major problem with this is that the IETF validation working group hasn't come up with a definite procedure for deciding what the apex of a domain is, and how to validate control over all subdomains above it yet.

Doesn't ownership of domain.tld also imply ownership of *.domain.tld?

I don't think the owner of "co.uk" should have the power to issue certificates for everything below it.

To make the original comment more precise, should not proving ownership of:

   <some domain>

be enough to imply ownership of anything under that? i.e., DNS is a hierarchy — right? At the top level (a bit closer to how the original comment phrased it, I'd say that proving ownership of,

    <some domain>.<some public suffix>

should prove ownership of all domains under that. To address the specific case of "co.uk", anyone in control of a public suffix[1] should just fail the check (i.e., owning a public suffix does not imply ownership of all subdomains, which I think is correct). Someone with better knowledge of the innards of DNS would have to speak to if the Public Suffix List is good enough here.

Really, why can't I be a mini-CA for my own domain, with only the power to issue certs for the set of domains I actually have control over? (essentially, why can't I get a nameConstraint CA cert?)

[1]: The Public Suffix list is a list of what a human might call a "tld, essentially"; "com" is a public suffix, but so is "co.uk": https://publicsuffix.org

Because client support isn't there for nameConstraints. I really wish it was though.

That's the relatively simple case, but there are a number of corner cases that make the process much more complicated.

See https://github.com/letsencrypt/acme-spec/pull/97 for a discussion of why this was scraped from the ACME specification proposal.

I don't get it. Whoever controls the base domain could always just replace the NS records and point any subdomain wherever.

No? I thought I'd seen a list of them somewhere authoritative. Anyone know what I'm talking about?

Yes, the Public Suffix List: https://publicsuffix.org/

That's definitely what I was thinking of, but it's not entirely suitable as a list of domains not to issue certificates for, unless you're happy to accept you won't be issuing certificates for domains like blogspot.com or flynn.io.

That's what Domain Validation (DV) is for and what most less-expensive wildcards use.

Absolutely. I badly need a wildcard cert to do any of the SSL-ing I'd like to do.

Reply on news.ycombinator.com