Best Practice for multiple domains on single server

Help
1

Scenario:
My question relates to the best solution to the problem of providing SSL to 200 domains pointed to server.

Details
I am hosting on upcloud, ubunto 18.4; no cPanel at present
I have 100 domains pointed via A record to the IP currently (including www, more than 100)

Goal
I would like each of the domains to be secured and for the process to be automated without having to do perform manual renewals

I understand that 1 certificate can cover 100 domains, - which would be 50, x 2 (with and without www.) etc

what is the best approach? one certificate per domain?
how best to automate initial SSL and rnewak?
does buying cPanel license help me?

thanks

1 Like
2

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.

3 Likes
3

I expect I will have 100 -200 domain names

e.g drmarkbrown.com

but then I know that SSL get’s issued for both drmarkbrown.com and
www.drmarkbrown.com

as I mentioned, the domains have A record set to the IP of the server

in the past, I had been on managed server with MICFO managed hosting (they went belly up last week)

domains are registered on godaddy, I set A record to the IP of the upcloud server

previously, domains were on server as ‘add-oin’ domains—

do I need to have domains as add-on domains or just set as they are for SSL to work?

Thanks

1 Like
4

“Addon domains” is a piece of terminology from cPanel - they don’t really exist outside of that context.

On a regular Ubuntu webserver, they would just be known as “virtual hosts”.

In your webserver configuration (Apache, nginx, whatever), you would setup 100 different virtual hosts for each of your distinct domains.

With Apache, this would look something like:

<VirtualHost *:80>
  ServerName drmarkbrown.com
  ServerAlias www.drmarkbrown.com
  # And then the rest of the virtual host configuration
</VirtualHost>

https://httpd.apache.org/docs/current/vhosts/name-based.html

To then protect this domain with SSL, you would use an ACME client (like Certbot), and do something like:

certbot --apache -d drmarkbrown.com -d www.drmarkbrown.com

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.

2 Likes
5

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:

  1. i would leave domains DNS as they are with A record pointing to IP of uplcoud sever
  2. i would create a virtual host for each domain
  3. 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?

thanks

1 Like
6

Yes, that is a recommended best practice: https://docs.https.dev/acme-ops#use-one-name-per-certificate

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

1 Like
7

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.

1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.