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?
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.
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)?