Getting an exception to the rate limit

Without knowing all the inner details of your current software solution…

Could you not use self-signed certs?

Be your own CA, send the users their individual certs signed by “your own CA”?

If your users need to trust each others certs (which I just assume) then make sure the users (game-)software trust certificates signed by “your own CA”?

Don’t know, it was just a thought that came to mind.

1 Like

self-signed certs don’t work because

  • they either need to be install on all devices the user will use to access their server, something end users are not going to do

  • they put up scary warnings that will scare users away. Some browser go to great lengths to confuse users on how to bypass the warnings.

Not sure how being my own CA helps. Is it easy to be public CA or are you talking CA in terms of self signed certs?

It's fairly hard to be a public CA. I think @Biker is describing creating a non-public CA, and having your users trust it. This is common for software that's purely local to one machine. However, it sounds like your software is going to run on a single machine on a LAN and have other users with unmodified browsers connect to that machine. Is that correct? A couple of questions:

  • How will the other users find the name of the machine running your software? And how will they route to the right IP?
  • Why do you need each user to access a unique subdomain?
1 Like

I think this was what made me think in those terms. If you distribute certificates to be used by the client computers to be software (game-)servers within the shared gaming circle, I thought you could distribute certificates signed by yourself. But of course, users would have to somehow trust your own signature ("your own CA"). And I thought that trust could somehow be distributed when you distribute the software that "will serve https from their local machine".

But hey, it was just a thought. I don't know all the details, so... :wink:

First off:

Each domain may only have 20 certs per week, but you can pre-generate the certs then allocate. You can generate 80 certs a month that way. Then you just revoke the certs after the gamejam (or let them phase out). You can’t recycle them, because the private key would be shared and violate the TOS (which is why you can’t use 100+ dI don’t quite understand your system though.
It seems like somehow everything registeres with happyfuntimes.net
Within a LAN, there must be some advanced configuration working?

Using LE - and that option - means you must have public internet OR some firewall rules that is rerouting traffic back.
You will basically require internet connectivity for people to use your system. Is that wanted?

From an Open Source and game-jam perspective… I would have each “server” become it’s own CA and have users trust it. This isn’t some random page someone is being asked to trust after clicking a facebook link – you’re telling people how to run/install a game in a local environment. There is a much higher level of informing and interacting with a user.

I would also shift the onus of configuring the domains / lan / and certificate management onto people who use your software, instead of the open source project itself.
omains per cert). Additional domains can be used to generate new batches of 20 certs/week.

1 Like

The software is used by 1000s of students and gamedevs. Each one needs a cert

Users and devs need zero network configuration. Currently files are served from http://<ipaddress-of-local-pc>/18679. The software/library registers itself with happyfuntimes.net. As long as users are on the same WiFi (behind NAT) they'll then players can get out their phone, go to happyfuntimes.net and they'll be redirected to http://<ipaddress-of-local-pc>/18679 since the redirection server running at happyfuntimes.net can see a matching public IP address for both the system run on the local pc and all the players using their smartphones.

Now, those users/devs need a cert so they can serve HTTPS. Hence the need for lots of certs.

All of these issues were gone over in this thread which ended with realizing I need way more certs than 20 a week.

You will basically require internet connectivity for people to use your system. Is that wanted?

Yes and no. Sometimes yes. See example above. Sometimes no (see museum example in other thread). In the no case though the user/dev can connect on internet to get a cert and a domain name. Then can then run the system in "no internet" mode and use that cert for ~90 days.

Using self-signed certs is a NON-STARTER. Users are not devs. They will not put up with warnings and will not click the tiny "advance options" -> "really go to untrusted sight" fine print. Remember these users are parents and kids in museums not devs. There is no one there to hand hold them through the process.

Also the many of the devs themselves are art students not techies so any solution that requires manually generating certs and configuring OSes is out as well.

Someone in that thread linked above suggested trying to get my domain added to the PSL. I'm not sure if that's possible and even if it is if it will work.

See above, there's a rendezvous server running at happyfuntimes.net that redirects them

Each game needs a cert. There might be thousands of people running or developing games. In order for HTTPS to work it need to be associated with a domain. So I need to run a public dynamic dns server, make up a subdomain for each game, get a cert for that domain, send the cert to that game so it can serve the cert, point the subdomain to their local-ip-address, then have the rendezvous server redirect players to that domain instead of what it does now which is redirect to http://<local-ip-address-of-machine-running-game>

All of this was covered in the other thread as well as the plex article linked above.

That's my question. Why? You could just run a proxy at https://happyfuntimes.net/, with each game available under https://happyfuntimes.net/game1, https://happyfuntimes.net/game2, etc.

Devs would still operate their own server, and would register with happyfuntimes.net under a given name (e.g. game1) and received forwarded requests.

1 Like

A proxy? How does that help except to add a ton of latency and add gigs of bandwidth to my costs? There are already games made that send video from every phone to the game. (yet another thing being banned without https)

Ah, I was assuming that your server would be running onsite with the devs and the servers at the game jam. I'm afraid I still don't have an accurate mental model of the game jam you're planning, except that there will be thousands of devs and thousands of players. Can you explain a bit more?

Can you provide more details about specific browsers or specific features that are causing you problems? According to Prefer Secure Origins For Powerful New Features, the intent is actually "prefer secure origins for powerful features," not "prefer HTTPS." According to that page:

“Secure origins” are origins that match at least one of the following (scheme, host, port) patterns:
(https, *, *)
(wss, *, )
(
, localhost, )
(
, 127/8, )
(
, ::1/128, *)
(file, *, —)
(chrome-extension, *, —)

1 Like

I don't see this system working as you want WITH HTTPS without a lot of network configuration.

You have 4 roles in your setup:

  • CloudService (happyfuntimes.net)
  • GameHost (whomever is running the LAN)
  • GameDeveloper (whomever provides a game on the lan)
  • Player (plays on their phone)

In your example, a GameDeveloper will have a valid cert but it would be served off a local LAN ip address. That will generate an name mismatch / wrong domain error on many (all?) browsers.

In order for the cert to appear valid and seamless like you want, the GameDeveloper needs to make the HTTPS content available on a domain that matches the certificate. The only way to do that, would be for the GameHost to operate a gateway/DNS server that resolves the DNS names for each certificate within the LAN to the right IP.

In other words, the registration of the GameDeveloper happening on happyfuntimes.net needs to be happening within the LAN; and they should be registering with the GameHost -- not the CloudService. The GameHost could register with the CloudService to grab certs; or would be responsible for obtaining certs themselves.

Essentially, things need to be happening like the "Museum/Installation" model. Maybe you can write a small service that will allow GameDevelopers to register with a local GameHost, provision the certificate to them, and then make that IP/Game mapping into a friendly format to be imported into the local firewall/DNS server?

It sounds like your current approach will solve one SSL issue by creating another.

1 Like

I’m not planning “a” gamejam. Gamejams are happening all over the world. Gamedevs at those gamejams often use happyfuntimes. Some gamejams all devs are using happyfuntimes. On top of that people just make games with the system. Ucla is using it for their games as art classes. The National Video Arcade in Nottingham is commissioning a game. A museum in Toronto is having an exhibition. The Join 2016 festival in Berlin is having a gamejam before and then playing those games. There’s a plugin for unity gamedevs are downloading it and putting it in their games. 72andsunny is using it in advertising campaigns. There’s a presentation on it at glitchcon in Minneapolis. It was used at last year’s Northern Spark festival as well as the Steam Carnival

Everyone of those people making or running a game needs a cert

To be clear there’s 3 parts as it exists today

  1. The machine running the game.

    This is the user’s machine like a PC/Mac/Linux/AndroidTV

  2. Players smartphones

    These are people in the same room as #1 on the same LAN

  3. A rendezvous server

    It’s sole point is to make it easy for #2 to connect to #1. Once it redirects the phone the rendezvous server is out of the picture.

Only #1 needs certs.

Features that games need for the phones that require https

  • fullscreen (allows choosing screen orientation, also there’s browser chrome users press by accident)
  • deviceorientation (the compass and gyroscrope) see this game as a simple example
  • getUserMedia (access to camera and mic)
  • other up can coming specs like beacons (or their replacement).

None of those secure origins listed help. #1 above (PCs) needs to serve HTTPS to #2 above (phones)

Basically the system was working fine until browsers started banning all the features we were using. The only solution I can see is serving HTTPS to the phones from the games (which are currently serving HTTP). To do that requires certs and the solution needs to be non-techie (like Plex).

I don't see this system working as you want WITH HTTPS without a lot of network configuration.

Did you read the other thread and the plex solution? Handling this with zero network configuration is a solved problem. Please reference the solutions.

In your terms there's no GameHost per se. That's just the user's router running the LAN so

  • CloudHost (happyfuntimes.net)
  • GameDeveloper (the game running on a PC serving webpages to phones)
  • Player

In your example, a GameDeveloper will have a valid cert but it would be served off a local LAN ip address. That will generate an name mismatch / wrong domain error on many (all?) browsers.

No, the cert is for the domain. The domain points to their IP address. No problem. As far as getting the cert the CloudService controls the DNS so it can set a TXT record to prove it owns the domain to get the cert. The GameDeveloper does not need to be visible on the public internet. Once CloudServer has the cert it sends to the GameDeveloper and points dynamic domain to GameDeveloper's local-ip-address. Player connects to CloudServer. CloudServer redirects player to dynamic domain that happens to point to GameDeveloper's local-ip-address. Because Player and GameDeveloper are on same LAN that works. GameDeveloper serves cert for dynamic domain. Player is happy, gets HTTPS.

GameHost to operate a gateway/DNS

No need for that, CloudService runs the DNS

Ok I understand. The confusion was that you’ve shared bits in pieces across different posts and have shifted terms about ip addresses. this is clear now.

You do need an exception of sorts (and possibly a public suffix list)… but I think you should also focus on pre-generating certificates and have 100+ ready at any given time. If the LE service goes down for a few hours, your service would break.

1 Like

you should also focus on pre-generating certificates and have 100+ ready at any given time.

Thanks, that's a good idea.

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

This is extremely frustrating. I’ve spent 2 years on this project only to have it all effectively killed by this HTTPS stuff.

Isn’t there something letsencrypt can do? Setup some kind of exception or some generic subdomain where exceptions are allowed. For example *.dynamicdns.*.*

1 Like

Something else you could do, is offer a whitelabel option for the cloud service:

  • a gamejam host / classroom / museum can purchase a domain and list your nameservers
  • each game “host” can override happyfuntimes.net as their cloudservice
  • the whitelabel cloudservice might only show a selection of games on a branded page

You could do that for free, or charge a fee. Your call.

Assuming you don’t get an exception in time… Using that method, there are 20 individual domain certs per week off each domain. Across 12 weeks in the 90 day period, thats 240 active certs per domain once you’re up-and-running.

There’s also an clause in the ratelimit that deals with “renewing domains”. If you can tie each certificate to a developer/account, renewing that won’t count against your quota.

1 Like

240 is not nearly enough certs and besides I think you’re missing the point. This is a FREE OPEN SOURCE LIBRARY. Any user can download the library and add it to their game. It costs me all of $5 a month to run the rendezvous server and not much more to run the dynamic dns / cert getting if I needed to do that which I’m just doing out of love.

It also requires no maintenance (well except for this massively frustrating https stuff)

But managing a limited user set of domains is a much larger amount of work. Accounts need to be created, users tracked, domains expired, etc. Thanks for the idea but I don’t consider that a solution.

1 Like

You’re talking about libraries, games, users on phones et cetera. For me, it isn’t fully clear what the user/player runs or has to install: does it need a specific application on their phone? Or only a webbrowser which will run the game?

1 Like

TL;DR: Players just need a browser on their phone. No app. Separately, someone needs to install a game on their PC/Mac/Linux/Android and run it.

Users (mom, grandma, sister, dad, little brother) install a game on their PC/Mac/Linux/Android. That game runs a webserver (using the happyfuntimes library)

Players then connect to the game with their smartphone. First they need to be on the same LAN. Then they open their browser and connect to the game.

To make that easy there’s a public server at happyfuntimes.net. When the game starts it tells happyfuntimes.net “I’m running a game. My local ip address is 192.168.1.47”. Happyfuntimes.net records that IP address and the public IP address.

Players then also, on the phone’s browser, go to happyfuntimes.net. Since they are on the same lan happyfuntimes.net sees them as the same public IP as the game so it redirects the browser to the game’s local ip (in this example http://192.168.1.47:18679)

Boom! They’re in the game. I’ve had 89 people playing a bomberman clone for example

Now the problem is browsers are banning the features the phone’s browser needs for the games unless the pages are https.

So, I need certs. Certs are assigned to domains so I need domains. Domains are easy. I can run a dynamic dns server. Certs though are either $$$ a piece or free from letsencrypt but the limits on letsencrypt make it not a solution. If a game becomes indie popular and 1000 people install it that’s 1000 certs needed.