Wildcard certificates and Certificates per Registered Domain limit

[hbagdi]

Let’s Encrypt limits the number of certificates that can be issued on a domain; this is referred to as Certificates per Registered Domain, which is something you link in your documentation as well.

I have a use-case where I want to issue a *.example.tld wildcard certificate once. I will then create:

• App1 with app1.example.tld as hostname
• App2 with app2.example.tld as hostname

I’m confident that I will hit the 50-per-week limit for Certificates per Registered domain.

Is there any way around this?
Can I create the wildcard certificate at an organization level somehow and then create “hostnames” instead of certs at the app level?

[lubien]

@hbagdi

Can I create the wildcard certificate at an organization level somehow and then create “hostnames” instead of certs at the app level?

Good call, we actually have a feature that works perfectly for what you need, it’s called Fly-Replay.

How to route certain paths to another Fly app without a reverse proxy? Meet Fly-Replay

We have an amazing feature called Fly-Replay that let anyone hosting apps on Fly teach our proxy how to reroute requests. Want to make a request go to another region? No problem. Should this request go to one specific machine? We can do that too. Should this request go to another app entirely? Eeeeasy. In this demo yall can see how to make an app rerout all requests under /blog* to another app. Don’t even open that link, here’s the entire code block for that: app.all('/blog*', function replay…

For your use-case I’d say:

• Create a router-app
• Add a wildcard certificate to router-app (ensure it has IPv4 and IPv6 so you can use certificates)
• Create the minimal possible Fly-Replay router like the one mentioned on the guide above to route foo.example.tld to foo-app.
• The “child apps” don’t need their own IP addresses anymore, feel free to remove them if you want

[hbagdi]

Do you cache that, or is that request made for each request?
This will be an extremely latency-sensitive and often high-throughput app (it is not an app, it is a reverse proxy).

What you are proposing totally make sense for most Apps, it just doesn’t work for my use-case.

[lubien]

The router machine will get the request each time an HTTP request first comes in.

Can I ask a bit more about your use case?

[hbagdi]

The router machine will get the request each time an HTTP request first comes in.

Each request going back and forth between fly-proxy and Kong won’t work.

The app is an nginx-like proxy.

I am happy to provide more info about the case. Could you ask something specific?
I want two things from Fly:

• fly provisions a wildcard certificate
• I can then use subdomains with apps to set up routing; the number of apps started weekly can be 50+.

[hbagdi]

So, I tested this a little bit more.

I added the hostname *.test.example.com to an app (call it app-1). I set up the DNS and issued the wildcard certificate is issued. Routing to the App is working as expected.

Next, I create another app, app-2. To this app, I added the hostname app-2.test.example.com.
The certificate isn’t issued for this app.
Furthermore, even non-TLS (plain old HTTP) seems to be bound for app-1 instead of the more specific app-2.

What I was trying to figure out was:

• If I could provision a wildcard certificate in app-1
• and then create sub-domain-specific apps, and fly-proxy will be smart enough to use the wildcard cert AND route the request to the more specific hostname to the appropriate app

It seems the first app to call dibs wins.

Is there any way to tweak routing in fly-proxy so that the wildcard certificate is used for TLS handshake, and then routing is done based on the most specific hostname match (common in some proxies)?