Certificates for many user-controlled subdomains

#3

As far as I know, there are exemptions to that rule for things like localhost/127.0.0.1. See https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy:

  • If origin’s host component is or falls within “localhost.” [RFC6761], return “Potentially Trustworthy”.
  • If origin’s host component matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], return “Potentially Trustworthy”.

External access can be solved via your own DynDNS (probably using dns-01 challenges).

This leaves a couple of things unsolved:

  • Users will have to use different URLs for internal (http://localhost/) and external (https://userid.yourddns.com/) access. Alternatively, you could use split-horizon DNS (public DNS resolves to your WAN IP, local DNS to 127.0.0.1).
  • Only localhost/127.0.0.0/8 is trustworthy, so this wouldn’t work if the server is running on another IP in your LAN. Two possible solutions:
  • Split-horizon DNS, like the previous example, except that your local DNS would resolve to the LAN IP.
  • Use a separate DynDNS domain for LAN access (https://internal.clientid.yourddns.com/). Resolve that IP to the server’s LAN IP. Issue a SAN certificate that covers both domains. Note: Some DNS resolvers scrub replies containing private IP addresses.
#4

I’m not sure I’m doing a good job of explaining what I’m trying to solve.

The app is for end users. Your mom. You Dad. Your nephew. So whatever solution has to requires zero network configuration. So I guess I’m not understanding the suggestion for split-horizon DNS. If I understand correctly, that would only work if users configured their routers.

This is why I brought up Plex as an example. It has the same issues and it’s something a non techie can setup.

I also don’t understand how the fact that localhost is exempt from restrictions helps. All the devices accessing the server will not be accessing localhost, they’ll be accessing ip-address-of-device. You can imaging the native software is running on some PC as 192.168.0.10 and some smartphone is on 192.168.0.12. That smartphone currently connects by going to http://192.168.0.10 but it can no longer do that because you can’t HTTPS to an IP address, only to a domain.

You then say users connect at https://internal.clientid.yourdns.com/ Where does the cerificate for that come from? That’s the issue. One person is https://192.168.0.10.joe.yourdns.com/ another is https://10.0.0.12.bob.yourdns.com/ another is https://192.168.2.200.kim.yourdns.com/. All of those need different certificates because the certificate has to be served from the app and I can’t give everyone the same private certificate.

Am I mis-understanding how your suggestions work?

#5

Correct, I pointed it out merely as a workaround. It is not strictly necessary as long as you’re willing to use different URLs for internal/external access. The last solution would not require split-horizon DNS at all, but is the most complex to implement.

I pointed it out because you specifically mentioned localhost, and this restriction doesn’t apply there. The last solution works for what you describe here.

From Let’s Encrypt?

You can use dns-01 verification to avoid having to open port 80/443 on the client’s IP. You have to run your own DynDNS setup on a domain you own and that is either on the Public Suffix List (so that the rate limit doesn’t apply) or that is otherwise whitelisted from rate limiting (something that will be implemented in the future).

Your software would update your DynDNS service with the correct LAN and WAN IPs so that you can resolve internal.userid.yourddns.com to the LAN IP and userid.yourddns.com to the WAN IP.

This would essentially support every client except those with DNS resolvers that scrub internal IPs (which, IIRC, is true for plex as well). UX would be slightly worse because of separate internal/external URLs. This could be hidden behind the scenes if your software is accessed via some centralized site similar to https://app.plex.tv/.

This would probably be a good topic for a more detailed blog post, may I ask what project this is for?
// edit: nvm, just found it at the top of this thread. :blush:

#6

Thank you for the DNS example. So I think I get that part now. And I’ll lookup dns-01, not sure what that is. I already have a re-director so users don’t have to type in IP addresses so that’s not a worry.

I guess I misunderstood letsencrypt’s limits. I thought it was just 5 subdomains per domain but apparently it’s unlimited so yea, I can see the solution now. Thanks!

#7

And what about avahi/mDns .local, I want to use on my machine a valid SSL certificate, because I’m facing now some development glitches on XCode, trying to get something from web and http is restricted, then I have to use https, but it does not support self-signed certificates. I know I can disable
that restriction configuring the project, but at some point I would prefer using a valid SSL certificate for my laptop web server that will serve the files required for my project or any other project even without being connected to a network.

Thanks

#8

CAs are not allowed to issue certificates for internal DNS names.

You can get a certificate for a public domain and point it to localhost/127.0.0.1 through your hostfile (e.g. /etc/hosts) or a local DNS server. Validation for Let’s Encrypt can be done with dns-01 (which works with TXT records) if you want to avoid launching a publicly accessible web server just for this purpose.

#9

So I’m seeing people saying there’s a limit to the number of certs per domain, meaning each subdomain cert counts againt that limit? Is that true? Of course my project is just a hobby project at the moment but I’m going to need at least a few 100 certs, 1 per subdomain. Examples

g1234.user.happyfuntimes.net
g5456.user.happyfuntimes.net
g4645.user.happyfuntimes.net
g6464.user.happyfuntimes.net

etc…

#10

Hello @greggman,

Yes, it is.

If you issue 1 certificate for g1234.user.happyfuntimes.net and 1 certificate for g5456.user.happyfuntimes.net you are using 2 of the 20 certs per domain limit allowed in 7 days.

But if you want, you could add those 100 domains (100 is the limit for domains in the same cert) to the same certificate and it will count just as 1 certificate and not 100, in that way you will avoid the 20 certs per week limit.

Anyway, take a look to the post where Let’s Encrypt explains the Rate Limits in use.

Cheers,
sahsanu

#11

Thanks for the explanation. Unfortunately it’s not helpful.

I’m S.O.L. DAMIT!

The certs are per user. That means they get downloaded to that user’s machine. I can’t share certs.

This is really frustrating. My project is basically dead because browsers are banning the features I need unless I go HTTPS and I’m not some giant company with $$$$$$$$$ to partner with some cert issuer. I thought letsencrypt would solve this. That’s what this entire thread is about but apparently I’m wrong.

#12

You really should review the link about Rate Limits and this post:

If you review the discussions there are also options using the public suffix list which would probably be very appropriate for your described usage. Since you’re just starting - it sounds like the 20 certs per week limit will grow slowly as you generate more certs over time.

#13

Alternatively buy a wildcard certificate for your domain - then it can have unlimited subdomains.

#14

If you read his posts, you can see that isn’t an option for his use case since the certs are being installed on customer systems.

#15

It’s already not enough. A single small gamejam would require 15-50 certs in a single day.

On top of that I’ve made the software a library to be added to games. those games get installed by users. Even a non hit game will get 20-100 downloads in the first day just from friends and acquaintances each one requiring a cert.

I guess I can try to do the 100 domain thing but that means sending the same private cert to 100 unrelated people per cert.

#16

The PSL then is probably going to be your best bet.

#17

See above. PSL is not solution. PSL is for devs. This is a end-user product. Scary warnings about un-certified certs is not solution nor is asking users to install certs.

I appreciate you’re trying to offer solution. It would be helpful if you could read above on what the product is, how it works, who the target audience though. Then you’d understand PSLs are not a solution

#18

Not sure what you’re getting at with the comment about PSL… PSL is a standardized central directory of domain suffixes that are known to have “end user specific subdomains or hosts”, and my understanding is the lower domain limits do not apply to domains on the PSL. It has nothing to do with uncertified certs.

If you went that route you’d need to be sure to investigate the side effects though, as being on the PSL does have some behavioral effects on cookie access/etc. - generally to protect subdomains from each other.

Were you perhaps confusing this with the staging server?

#19

Doh, thank you for the clarification. I thought PSL referred to something else.

#20

Is the PSL actually a solution?

Some things that aren’t clear. How do I get my domain on the PSL? Looking at the docs domain in the ICANN section need to be TLDs and submitted through ICANN so that seems like a non-starter?

I can submit a private domain but will letsencrypt let me get unlimited certs for stuff in the private section? It looks like I would want to add

*.users.happyfuntimes.net
!*.happyfuntimes.net

or something like that though I’d be happy to make it something more generic like

*.*.opensourceprojectsthatneedcerts.net
!*.opensourceprojectsthatneedcerts.net

Update: I see dyndns and other dynamic dns services are listed under PRIVATE which I assumed letsecrypt supports so I submitted a PR. Cross my fingers this is a solution

#21

PSL denied because the sole reason is to get around letsencypt’s limits.

I suppose I should have lied and just said I was a new dynamic dns company :pensive::roll_eyes::triumph::cry::frowning:️

#22

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.