Wouldn’t it be great to have a fallback for auto-issuance of certs using the same ACMEv2 protocol if rate-limits are reached? For example, Secured website | Buypass.com could be used.
That’s on the long-term roadmap, but is technically complex.
Also, I don’t think falling back to a different CA is the right answer for rate limits. If rate limits are reached, that usually means something is wrong with the configuration of the server, network, or local/internal system, and that should be fixed instead. 99.99% of the time, there’s no really convincingly-good reason to hit LE’s rate limits.
Caddy uses 1 SAN name per cert automatically, it does not combine multiple domains to a single cert. Current LE limit is:
50 Certificates per Registered Domain per week
Let’s think what would happen in a shared webhosting environment with Caddy, let’s take freehost.com as an example. Let’s say we have 5 names pre-defined by default per-domain, and we give our customers free hosting on theirname.freehost.com. Names needed for ‘own’ domain:
www.freehost.com
freehost.com
mail.freehost.com
ftp.freehost.com
webmail.freehost.com
So, we’ve used 5 out of 50. Now we want to create some of your customers with theirname.freehost.com having the same DNS records, secured with SSL:
customer1.freehost.com
...
customer9.freehost.com
We’ve reached the rate-limit here, as we’ve used 9*5+5=50 cert requests per registered domain.
It can simply be regular subdomains/own-vhosts on owned domain, not separate customers too, same scenario 
If the idea is not to use Caddy as “Let’s Encrypt” client, let’s say we don’t have ftp/mail certs generated form Caddy. That’d still be 3 entries, meaning max 16 theirname.freehost.com customers per week.
Please correct me if I’m wrong (I wish “usually means something is wrong with the configuration of the server, network, or local/internal system” was correct).
For those cases, use a wildcard certificate instead.
Yes, wildcard would be best option, but it requires DNS validation. In shared webhosting environments (where control panels are mainly used) some end-customers might not have their external API configured for Caddy. Plus we’d need some auto-detection of end-user behaviour in our control panel… For example, if customer is trying to create more and more subdomains using HTTP-based validation - try to switch them to wildcard automatically (I guess Caddy has no logics for it, right?).
We could use our own auto-generation of LE certs to include N domains per cert for those cases and just include Caddy without auto-provisioning of SSL certs on DirectAdmin-based systems. I was just thinking about using Caddy auto-provisioning when possible
I thought you said this was for subdomains of a web host, though (e.g. customer.freehost.com)? In this case, you’re in control of the domain, and lego (Caddy’s underlying cert library) supports over 60 DNS providers (maybe more since I last checked).
Your customers don’t need to configure anything for the DNS challenge if you’re managing the wildcard certificate for them, and by extension, the domain name too.
If you’re not managing the domain(s), the right thing to do here is just to have the customer indicate which kind of certificate to use. Limit them to some number of subdomains per week or have them use a wildcard. (Or, use on-demand TLS, a feature only Caddy offers. As long as they don’t use 50+ subdomains all at once, you could spread out the ACME transactions until they are actually needed. But I don’t recommend this approach either unless absolutely necessary.)
If you need more help about Let’s Encrypt’s rate limits, I suggest their forum.
I’m not, I’m just designing Caddy integration with DirectAdmin control panel. The domain-owner can be the server-owner, but it can also be an end-customer using the hosting service.
They would need to manage it in their user-level (DirectAdmin control panel), because we’re just providing a product for shared webhosting companies. They place their customers on the server. End-customers might have their own cloudflare (or other) accounts managing their DNS records. Thus we’ll need to create additional endpoint where they could specify API data, and when DNS changes need to be done for these particular domains, it’d use end-customer defined DNS provider endpoint.
We have our own client written, in effect since 2015 or so, that’s why I was concerned on rate-limits of Caddy, because it uses 1:1 relationship and no SAN domains. We use SAN for auto-generated certs, so that way we could use up to 100 different names per-certificate, up to 50 requests a week, meaning up to 5000 certificates per registered domain vs. 50 in Caddy. I think we’ll just use our own client for now, until there are more options in Caddy or until we code something to ‘predict’ end customer needs, and force Caddy to issue wildcard for their different domains (does Caddy auto-detect that wildcard cert is already there, and skips issuance of HTTP-based cert for new vhosts that fall under the ‘wildcard’ cert?)
Thank you for the information/suggestions!
Alright, that’s fine.
Just be aware that we recommend against managing multi-SAN certificates: https://docs.https.dev/acme-ops#use-one-name-per-certificate
Case study: Caddy was the only ACME client unaffected by Let’s Encrypt’s recent CAA rechecking bug, which led to the mass-revocation event, because Caddy doesn’t use multi-SAN certificates. (It also does revocation checking and OCSP stapling, so even if it was affected, Caddy sites wouldn’t have gone down. It was also the only client at the time known to have this feature.)
As far as using multi-SAN certs to avoid rate limits, all that really does is lengthen the runway, but it doesn’t solve the actual problem. Caddy is designed to scale to millions of certificates; your client (or any client that uses multi-SANs as a way to circumvent CA limitations) is not.
Cloudflare also switched to single-SAN certificates. And they probably manage tens of millions of domain names.
Just saying, these are solved problems already at much larger scales than what any shared web host is operating at. Something to keep in mind.
Why predict? Just have them configure it. You can’t just switch from HTTP or TLS-ALPN challenges to DNS challenge anyway. You’ll need them to configure it if they’re controlling the domain.
If Caddy has already loaded a certificate with a subject that matches a candidate domain name, it will use that instead of obtaining a new one. (Unless of course you tell it to obtain a new one anyway.)
You really should go to the Let’s Encrypt forums about this though. They’ve had this conversation dozens upon dozens of times.
1 Like
Nice ideas, great article!
I didn’t know this!
I already have an idea for this 
Is there a way to tell caddy to generate a wildcard for that particular vhost without specifying *.domain.com as vhost name? Something like:
"automation": { "policies": [{ "wildcard": true }]}
BTW, does Caddy use Lego for external DNS providers APIs?
Caddy 1 had this option, and we can add this, probably for 2.1. Feel free to open an issue and we can track it.
For the time being, yep.
Does it mean all endpoints available in Lego can be used in Caddy as well? JSON Config Structure - Caddy Documentation names just 3.
Yes and no… technically those providers are the same code that Caddy users, but lego has a different config surface from Caddy, so there needs to be a little bit of code that translates from Caddy config to lego config.
It’s pretty trivial, but also menial and tedious work. For one provider, it only takes about 3-5 minutes, but there are getting close to a hundred of them, that’s over 8 hours at 5 minutes each, assuming no hiccups or edge cases!
Further, lego’s exported API has diverged further from what Caddy 2 requires. So I have only implemented 3 providers for Caddy so far. After 2.0 is released I will spend some time on that.
1 Like
Wouldn’t it be better to unify it? That would let people use caddy/lego interchangeably, for example, if Caddy has no DNS hook for specific provider - people could call lego in some pre-generation step of the wildcard cert
Edge cases like ‘manual’ DNS provider option would still need some integration from Caddy’s side, but all the others would work out-of-the-box, if unavail in Caddy.
If you’re planning to add all the providers they support and update the list when it gets updated in lego, this would make no sense, otherwise - I see the need for it.
Thank you!
Yes and no
Yes because: I am thinking of forking it. But this is a huuuge maintenance burden that I could only expect the community to help me carry since I won’t be able to do it myself.
No because: lego is an ACME client implementation, CertMagic (which Caddy uses for most of its TLS magic) is a layer above that, and we don’t want leaky/weak abstractions.
Ability to use Caddy/Lego interchangeably (even if lego would need some different env params) would be really nice!
If you go another route (fork it and include as a lib to Caddy), it’d be nice to have caddy as a standalone ACME client, which could be called directly from CLI and replace Lego for issuance of the certs.
Not going to happen, sorry. Lego, Certbot, and other one-off commands are incomplete and unsatisfactory solutions to proper TLS certificate management.
1 Like
Not a problem at all, if Caddy gives more control. As discussed earlier - at this moment there is even no way to get *.domain.com cert if you specify just domain.com as vhost name. And not only that - mentioned DNS providers is another place. If it gets mature - why not.
Keep in mind that CLI utility could simply start Caddy and use the same logics to generate a cert on the servers not needing the webserver at all (for example, mail-only server).
Thank you!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.