Do you plan to scale to many hundreds of domains, or thousands of domains? Most decent ACME clients can probably handle 200 domains without much fuss, but many more than that and some might run into limitations – e.g. performance issues, or insufficient automation to be easy to work with.
Lots of ACME clients have a “run one command in a terminal to onboard a new domain” interface (with fully automated renewal afterwords). Which is great when you’re setting things up by hand, but not so much if you want complete “signing up on my web control panel automatically creates certificates” automation.
Let’s Encrypt has some documentation on the subject:
In my opinion, yes. Other options require complicated and hairy logic:
What if a customer’s domain expires, or they leave your service (sorry)? The certificate will fail to renew. If you have one certificate per domain, that doesn’t harm your other customers. If it has multiple domains, you need logic to eventually issue a new certificate with the remaining domains.
What do you do when onboarding new domains? Repeatedly issuing certificates with N domains, N+1 domains, N+2 domains… implicates the 50 certificates per domain per week rate limit.
What if a customer wants to leave your service (sorry) and revoke relevant certificates?
Well, pretty much every ACME client supports automated renewal.
cPanel has AutoSSL and other ACME clients, but there are lots of non-cPanel ACME clients too. It’s your choice what to do.
and it would create a certificate for that virtual host, and also take care of automatically renewing it. Repeat 100x for each virtual host.
The benefit of cPanel would be that this entire process would be easier to setup and harder to mess up. The cost of licensing 100 cPanel accounts is not insignificant; it’s up to you to trade-off your time and money.
Thanks for the clarifications–
so, in the interrim, i’ve learned that cpanel isn’t compatible with ubunto so we can nix that.
assuming no cpanel/plesk etc ’
with the process that you’ve described:
i would leave domains DNS as they are with A record pointing to IP of uplcoud sever
i would create a virtual host for each domain
certbot -? would be scheduled every ? 45 days or ?
is there a limit to the number of domains (as there was when i had a cpanel on MICFO hosting of 100) – or if i have my own ubunto and this, no limit?
based on what i’ve described, doing by hand - it seem like it would require a few hours to setup, as each domain needs alias created ? but thereafter, once set up, would any additional time be neceesary for its upkeep?
Anyway, sorry if I didn’t follow this thread correctly, but from my understanding, you want to keep certificates for 200+ registered domains (i.e. not a lot of subdomains – in which case you should use a wildcard certificate) renewed?
Based on the concerns that @mnordhoff brought up, it sounds like you’d want a client like CertMagic, which is a Go library, but it can be used pretty directly through Caddy (Caddy uses CertMagic).
This requires no cron jobs or certbot or any other external dependencies on your system: it’s a self-contained solution in a single static binary that “just works” with some modest configuration.
Here’s a quick tutorial explaining how your config would look:
Basically, you just list the domain names you need certificates for and Caddy will obtain and renew certificates for you. Unlike most ACME clients, this is designed to handle tens or hundreds of thousands of domains/certificates: Caddy has internal throttling and job scheduling that will obtain certs for domain names as fast as it can without hammering CA servers. If there are errors, it will backoff and retry for up to a month. Just let it keep running while you solve the problems that you see appear in the logs (for example, fix a domain’s DNS records if it has validation errors).
If you don’t control these domain names, you will probably want to use Caddy’s unique on-demand TLS feature. This feature defers certificate management until the first TLS handshake that requires it, i.e. only after the DNS records have been pointed to your server and clients start accessing it. The first client to connect can trigger the certificate obtain/renew operation. Caddy will process the certificate during the handshake and use it for future connections, keeping it renewed as long as clients keep needing it. Some time after the certificates expire, Caddy will delete them for you.
It’s a unique feature that many businesses have already built their SaaS on top of, and we’ve been using it in production for several years now.
(I should probably disclose that I’m the author of these tools – for full transparency – although I don’t really gain anything by recommending this here.)
I bet you can get this set up in about 5 minutes (plus time to get familiar with Caddy – the actual config you want should only take you a few minutes with that wiki link above).
It sounds like you are hosting for others, or have a whitelabel service. In those situations, you ABSOLUTELY POSITIVELY want to do at-the-very-least each Second Level Domain on a separate certificate (e.g. example.com). If you control/own multiple domains, mixing them into a cert isn’t necessarily bad.
One of the big reasons why one-domain-per-cert is recommended, is this: when it comes time to renew, if you no longer have one of the domains (owned, active, configured), a single domain failing validation during a renewal will fail the entire order (certificate). That means you will need to actively audit your system and make corrections (fix a domain, or renew a certificate without the broken domains) - otherwise all of your domains will not be able to renew.
By implementing one-domain-per-cert, if one domain fails, only that domain’s renewal will fail.