What happened?
Caddy automatically obtained a certificate for your domain, caddydemo.crowdcow.com, without any change to the server's configuration. We call this technology On-Demand TLS, and it's an exclusive feature of Caddy.
With On-Demand TLS, no config changes are required to serve more domains over HTTPS. This is perfect for servers hosting content or APIs for customer-owned domains because your HTTPS deployment scales as tall and wide as your business does.
Caddy's technology is the secret sauce of many SaaS products that offer custom domains. It generates hundreds of thousands of dollars in revenue every year while saving businesses tens of thousands of dollars in development and maintenance costs.
Fun fact: this feature earned standing ovations at more than one tech demo back in 2015 and 2016 when it was first introduced.
Easy, self-hosted HTTPS for customer domains
Use On-Demand TLS to grow your custom-domain SaaS business in a matter of minutes. A minimal config looks like this:
1. Prevent abuse
First, you'll configure an internal endpoint that Caddy can "ask" if a certificate should be allowed for a domain. This endpoint usually looks up the domain in a list or database and returns HTTP 200 if it's allowed. Make sure to reject domains you don't recognize. (This implies that customers have to tell your app what their domain is first.)
2. Enable On-Demand TLS
To finish, enable On-Demand TLS for a catch-all site.
{
on_demand_tls {
ask http://localhost:9123/check
}
}
https:// {
tls {
on_demand
}
# reverse_proxy, etc...
}
# other sites...
Actual production configs typically have more, but this is the minimal configuration needed to serve domain names that aren't in your control. All that's left is for the domain owner to set their DNS records (described below).
Brilliant customer experience
For domain owners, the flow is even simpler: set DNS records. The first visit to their site will provision a TLS certificate. Works like magic!
1. Point DNS records
The customer sets either a CNAME record or A/AAAA records on a domain or subdomain they control, so that their domain resolves to your server's IP address.
# Customer's DNS (example domains)
your-app.customer.com CNAME -> your-app.com
# Your DNS (example IPs)
your-app.com A -> 198.51.100.1
your-app.com AAAA -> 2001:db8::
There is no step 2. Caddy will obtain and serve a certificate for their domain as soon as a connection is made to it. Caddy keeps the certificates renewed as long as connections keep coming in. Once they stop, Caddy will let the certificate expire and then delete it automatically.
And that is how you save tens of thousands of dollars in development and infrastructure costs every year.