Best practice for 124 VirtualHosts, one IP Address, w. Apache

Hi,
What are the best practices to enable https with Apache, with 124 VirtualHosts, all on the same IP Address, since there is a limit of 100 entries (SAN)?
If multiple certs, will certbot manage them all and configure them in Apache? How?
Thank you.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: dna-os.com

I ran this command: Certbot --apache

It produced this output: Error creating new order :: Order cannot contain more than 100 DNS names

My web server is (include version): Intel Xeon

The operating system my web server runs on is (include version): ubuntu/debian 22.04

My hosting provider, if applicable, is: n/a

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 2.4.0

Personally I like to keep my domains separate. If you require a cert for 124 subdomains of the same domain, I'd personally go for a wildcard certificate, if possible.

You could also go with ZeroSSL, another free ACME enabled CA, which offers more than 100 hostnames in the SAN. It's possible to keep using Certbot for this. Note that the limit of 100 hostnames with Let's Encrypt is also for performance reasons: more hostnames means larger certs means slower handshake for each TLS connection. So I'd go with separate certs per domain if I were you :slight_smile:

5 Likes

Generally speaking: Yes.
But things may depend on the current state and how well Apache has been configured.
If each FQDN has its' own virtual host, then certbot --apache should do the trick.
[just don't chose to do all of them at once - in one cert]

5 Likes

Please define "manage"?

5 Likes

Hi Osiris,
Thank you for the support.
I logically split the names in close to ten groups/certs so far.
I can get the certs some have been successfully installed.
I still have some different issue so I may post a different question, not to mix it all up.
Thank you.

1 Like

Hi rg305,

Yes, in principle each FQDN has its vhosts (80/443), but in fact, some have subdomains, of which some have their own vhosts while others simply appear in ServerAlias of others.
I am unsure of the pros&cons.

One question that I still don't have an answer for is if I have subdomains, from a first domain, referring to other domains that have their own different certs, could there be issues?

As well out of over 20 so far, there is one subdomain that is giving me this error:
Failed redirect for plan.hyperbase.com
Unable to set the redirect enhancement for plan.hyperbase.com.
Unable to find corresponding HTTP vhost; Unable to create one as intended addresses conflict; Current configuration does not support automated redirection"

Finally, I am impressed and somewhat worry of what I find here:
https://check-your-website.server-daten.de/?q=plan.hyperbase.com.

All support is much appreciated.

Thank you.

1 Like

First, having certs with many domains is often problematic. I think it is easiest to manage long-term if you have one cert for each of your Apache VirtualHost's. If a VHost has only one name in ServerName then the cert has just one name. If you also have 10 ServerAlias names then your cert would have 11 names.

Second, is it really necessary to use the ::ffff:69.70.39.170 mapped address in your AAAA record for your plan.hyperbase.com domain? I'll let more DNS experienced volunteers comment further but it seems unnecessary. If you have a valid IPv6 address please use it. But, this IPv4 mapped address is very unusual at least.

Third, your problem with Certbot not finding the VirtualHost for that domain redirection is probably an Apache config problem. Check to make sure that domain name appears once and only once in a VirtualHost for each listening port. That is, one and only one VirtualHost *:80 should have that name.

Lastly, what exactly are you concerned about in the check-your-website results? It is difficult to interpret and covers a wide variety of items. Only some of these items are pertinent to this forum.

3 Likes

What do you mean by "referring"?

3 Likes

Hi rg305,

Good question.
Referring here is : providing the same DocumentRoot/path.

Regards.

1 Like

Hi MikeMcQ,

The AAAA IP address I see in the DNS config is 0:0:0:0:0:ffff:4546:27aa so I wonder where/why the Make your website better - DNS, redirects, mixed content, certificates report has the ::ffff:69.70.39.170 address, as you noted, I do not.

If subdomains have different DocumentRoot-s, they require a separate vhosts, and if they are "synonyms" then they are ServerAlias-es. Typically, in practice, when subdomains have different DocumentRoot and vhost, they do not need their own ServerAlias.
Right now the plan subdomain is sort of an exception as it is one of two ServerAlias-es to a subdomain with its own vhost. The other one of these two ServerAlias-es has not generated any error. The cert is installed for that vhost. In fact, all vhosts for hyperbase.com have cert references, except one and certbot tells that that subdomain (dnaos.hyperbase.com) has been installed successfully.

As for being somewhat worried about the check-your-website report, the IP6 address is a sample. I was mostly wondering if any info there could help us see more clearly about the certs installation issues. The rest, I will deal with later.

Thank you for working with me on this.
Regards.

1 Like

Hi Osiris,

By "manage" I meant installing and configuring certs so that they do not conflict, in practice. This setup is for one IP address with many certs, domains, subdomains, vhosts ...

Regards.

Hmm. Then I don't think you are looking at the authoritive DNS servers. Because DNSviz, a tool we use often in this forum, shows the same AAAA record as check-your-website and which is the same I see from my own DNS lookup of your authoritive DNS. (DNSviz link here)

dig +noall +short AAAA plan.hyperbase.com @ns1.dnsowl.com
::ffff:69.70.39.170

As for how to combine hostnames into certs, my suggestion was simply that each HTTPS (port 443) VirtualHost use a cert containing the names listed in that VHost's ServerName and ServerAlias - none missing and none extra. You then have one cert for each HTTPS VHost. Based on my own experience and what I've seen in the thousands of threads I've seen in this forum that works well.

Each of those VHost's has a matching HTTP VHost (port 80) which redirects to HTTPS (and handles a cert HTTP Challenge if used). You are of course free to organize your stuff as you prefer. You did after all ask for "Best practice" suggestions. These are mine :slight_smile:

4 Likes

Hi MikeMcQ,

I appreciate and trust your opinion and ask for it. And I did ask for best practices. Thank you.

You were right about apache config issue, as I found a comma between two ServerAlias-es, on the port80 vhost for plan.hyperbase.com. Removing it allowed certbot to successfully complete installation for those domains. I still have more to do.

I am also checking dns configs and trying to workout the ip6 issue with the domain provider. I will keep you posted on that.

I much like the idea of minimal and structured vhosts, which leads me to ask for possibly more best practices advice:

I see that certbot has added RewriteRules in the port80 vhosts. Do the port80 vhosts still need the repeated info or just the ServerName?

Thank you.
Regards.

1 Like

Hi,

Certbot properly installed all the certificates for all domains
Nice job.

In addition I have two more questions:

  1. Certbot split some conf files to separate the port80 from port443 vhosts. It did not split the more elaborate conf files. Should I split them also? Or should I reassemble them, or just put everything in a single conf instead?

  2. Now that everything is setup, if I need to change things and ungroup or change grouping of names per cert, what is the best approach? How can I cancel the certs and ask certbot to replace them with, or generate and install, new ones?

Thank you again.
Regards.

1 Like

You can leave them as is. The certbot renew will process them in that way.

It depends how you chose to organize your certs. If you used one cert per HTTPS VHost like I suggested you just use the certbot --expand option to add your new ServerAlias/ServerName to the list for that cert (maybe even using --cert-name option too). To remove a name just reissue the original command omitting the deleted name.

A similar approach is used even if your cert has domain names in it from multiple VHosts. You just need to keep track of which cert cover which HTTPS VHosts.

4 Likes

Not sure what you mean by "repeated info". If you want to post an example HTTP VHost we can be sure to be accurate with our response.

3 Likes

Hi MikeMcQ,

Below are the two main vhosts for hyperbase.com.

The ServerAdmin, DocumentRoot, ServerAlias, ErrorLog, and CustomLog stanza are identical for both port80 and port443 vhosts. Can/should these be removed from the port80 versions?

As for the certificate/domain grouping, I would split them further to reach your suggestion of 1 cert per vhost. The exception would be for those domains that have subdomains that have different DocumentRoots. I know and have noted precisely which domains go with which certs.

Note: hyperbase.com, the largest, has 9 pairs (port80, port443) of vhosts for 24 domains/sub-domains, on 1 cert, with no other domain on that cert.

Great help.

Thank you.
Regards.

<VirtualHost *:80>
    ServerAdmin webmaster@hyperbase.com
    DocumentRoot /var/www/html
    ServerName www.hyperbase.com
    ServerAlias hyperbase.com *.hyperbase.com
    ErrorLog /var/www/logs/hyperbase.com-error_log
    CustomLog /var/www/logs/hyperbase.com-access_log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.hyperbase.com [OR]
RewriteCond %{SERVER_NAME} =*.hyperbase.com [OR]
RewriteCond %{SERVER_NAME} =hyperbase.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<VirtualHost *:443>
    ServerAdmin webmaster@hyperbase.com
    DocumentRoot /var/www/html
    ServerName www.hyperbase.com
    ServerAlias hyperbase.com *.hyperbase.com
    ErrorLog /var/www/logs/hyperbase.com-error_log
    CustomLog /var/www/logs/hyperbase.com-access_log combined
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/hyperbase.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/hyperbase.com/privkey.pem
</VirtualHost>
1 Like

Do NOT remove the ServerAlias. The ServerName and ServerAlias names are used by Apache SNI matching to determine which VHost will process the incoming request. See Apache docs.

Logging options on your port 80 VHost is up to you.

The DocumentRoot is best to leave in place.

4 Likes

I would NOT recommend doing that.

5 Likes

Be aware that using a wildcard there will overlap any other such names when they appear later in the overall configuration.

5 Likes