We plan to implement this as well very soon. Following
An example for something like this would be amazing! We had something like this in production a few years ago now on the original fly model and only found the experience to be amazing.
Having an example that makes something like this super simple to understand and implement is pretty valuable to the platform as a whole, specially for SAAS partners.
Another note, in the past, we had to do some CNAME flattening on Route53 in order to give out more friendly on brand CNAME’s to our customers and to have the nameservers where we can change where they point at any moment. Would love to hear more on this as well
I can give you a quick outline of how it could work:
Create a wildcard certificate with Fly for *.our-platform.com and go through the steps necessary for us to generate a certificate for it.
You create wildcard A and AAAA records for *.our-platform.com and point them at your Fly app’s IPs
For higher plans, you tell your users to create a CNAME record for their hostname and point it at manager.our-platform.com (or their <workspace>.our-platform.com, this might be easier if you want to move some workspaces at some point)
Every time you create a new “higher plan” workspace in your app, you can call our hostname API to create a certificate for this custom hostname (this is detailed here: Custom Domains and SSL Certificates · Fly Docs, this whole doc might be of some help!)
You can stay with Cloudflare, but regarding GCP: it would be best to host your app on Fly! It’s also possible to keep GCP and just create an app on Fly that’s a reverse-proxy (like nginx, Caddy, etc.) to it. This adds an extra layer though, where things can go wrong and definitely adds latency.
The client wouldn’t. We use the ACME TLS ALPN challenge for everything but wildcard certificates. As long as there’s an AAAA record pointing to your IP (a CNAME will od that if the DNS provider flattens them), certificates will get renewed automatically without any intervention.
Im sorry just to clarify, I meant this for the https://manager.mywebsite.com certificates the customer would only add the CNAME pointing to manager.our-platform.com correct?
Yes. Or a CNAME to any other hostname pointing at both A and AAAA. As long as the AAAA is being flattened to your app’s IPv6, then we can issue certificates.
I’m afraid there aren’t any alternatives other than asking them to switch to a support provider or point their A and AAAA records to your IP on Fly.
These IPs will stay yours. It will be a bit painful if you move away from Fly, to get them to change their DNS records.
Perfect, that is fine, we can always have the IP A/AAAA records in our back pocket for our support team to use as a backup. Being thats its so rare, we can just instruct these clients to use the IP if they are having issues.
@jerome This is pretty awesome. However we setup our Fly account before there were Wildcard certs and have created hundreds of .listingvillage.com certs. We’ve tried adding a *.listingvillage.com cert to the Fly dashboard and have setup the * CNAME record on our end, but the wildcard cert has not been created.
Are there any known issues when trying to create a wildcard cert when single site certs have already been created?
Should we email support if we have setup the _acme-challenge, the DNS is “resolved”, but the SSL is “missing”? Normally the SSL is ready to go in a few minutes and it’s been several hours.