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.
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
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]
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.
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"
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.
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.
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 ...
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)
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
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?
Certbot properly installed all the certificates for all domains
Nice job.
In addition I have two more questions:
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?
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?
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.
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.
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.
