Need to have https for every new domain added


#1

I host a single website on a bare install Debian server. It has a simple Apache HTTP server with PHP, nothing else. I forward different domains to it based on the campaign I’m promoting for a country. For example, if I’m targeting Australian traffic, I will have a different domain for that, and for USA I will have a different domain name, etc… All together there may be around 10-15 domains pointing to the server’s IP.

From the research I did, it looks like HTTP certificates are attached to the domain name? the tutorials I followed all do this with configuring virtual hosts. But I add domains frequently and they point to the same webpage/directory on the server, so there is no need for virtual hosts for me.

I’m hoping that I can do this without messing with virtual hosts. I want to buy a domain, point it to my server’s IP and have https work without manually having to configure anything. Is that possible?


#2

Hi @xpro

it’s simple, use a wildcard-certificate *.yourdomain.com. So you need to use dns-01 - validation.

I don’t know enough about Apache, but I am sure there is also a wildcard-solution.

A host without a special hostname should work. So this host catches all http- and https-traffic.


#3

But what about when I’m generating the certificate using certbot? In the tutorials I see examples like below. But that is for only one domain name. In this case “example.com

certbot --apache -d example.com


#4

There is separate documentation about creating a wildcard certificate, but this requires making DNS updates to prove your control over the domain name (by Let’s Encrypt policy about wildcards), and so you would have to think about things like a DNS provider API in that case.

A certificate can cover multiple names, so you can get one certificate that covers a.example.com, b.example.com, c.example.com, and d.example.com. In Certbot this looks like

certbot --apache -d a.example.com -d b.example.com -d c.example.com -d d.example.com

The resulting certificate will cover all four names and be valid regardless of which of the four names was used to access the site. Would that work for your use case? (Let’s Encrypt allows up to 100 different names in a single certificate.) In this case if the certificate is presented for all HTTPS connections, you wouldn’t need to use virtual hosts to tell Apache how to select the appropriate certificate because the certificate would already be valid for all of the possible names.


#5

Then the documentation is incomplete. I don’t use Certbot, but in this forum, there are a lot of samples with multiple -d *.example.com -d example.com - variants used in a single command.

PS: Your two questions are completely different. The one - “how to setup apache with hosts a.example.com, when a may be b, c or xyz”. The other - “how to create certificates”.

PPS: The first question is simple:

https://httpd.apache.org/docs/2.4/vhosts/examples.html

Ensure that Apache listens on port 80
Listen 80
<VirtualHost *:80>
DocumentRoot “/www/example1”
ServerName www.example.com

# Other directives here
... Due to the fact that the virtual host with ServerName www.example.com is first in the configuration file, it has the highest priority and can be seen as the default or primary server. That means that if a request is received that does not match one of the specified ServerName directives, it will be served by this first

Later do the same with port 443.

The wildcard-solution has the effect, that you don’t need to create a new certificate if you have a new subdomain.


#6

I was not clear enough in my question. I don’t need to configure Apache virtual hosts, since I am only using one webpage.

What I do now is I point my domain ns servers to cloudflare and in cloudflare I create A records to my server’s IP. Since there is only one webpage on the whole server everything is located in /var/www/html every new domain I add will also point to the same webpage in /var/www/html directory

I’m looking for a way to add HTTPS for all domains, and not having to mess with the server every time I add a new domain name


#7

Then you need a wildcard-certificate *.example.com. That works, I am using the same. Every customer has his own subdomain. I add only the dns-entry, the certificate is a wildcard-certificate.


#8

would a wildcard like this work *.* ? because I would have domains like

mysiteaa.us
mysitebb.ca
mysitecc.co.uk


#9

No, . doesn’t exist. A wildcard certificate works only with subdomains. Something like

usa.example.com
australia.example.com
gb.example.com

Then you can use *.example.com. Letsencrypt must verify that you are the owner of the domain, so . can’t work.

Edit: I wrote wildcard dot wildcard, I see only the dot - .


#10

since I’m not adding subdomains, then I have to generate new ones for each domain right? somehow I should find a way to call script that does this for me?


#11

Can’t you start this manual? Adding the domain, wait a moment, start Certbot with the new domain.


#12

yes, but I’m trying to not add more steps. Right now adding domains takes a good time out of the day. especially if I’m adding 10 domains. And the more manual work, the higher chance I may make a mistake by typing a typo somewhere. Below are the steps I have to follow for each domain I add

  1. Buy domains
  2. change nameservers
  3. add domain to cloudflare
  4. add a records to cloudflare
  5. test them

#13

How many domains will you have, and how often will you add or remove (sub)domains?

Let’s Encrypt certificates can have up to 100 names. It’s no problem to do:

certbot --apache -d example.com -d www.example.com -d example.net -d www.example.net ...

It’s as simple as using one domain.

But, due to the rate limits, adding or removing names too frequently would be problematic.

It may be easier, or necessary, to have multiple virtual hosts. Maybe a few, maybe one per domain.

Most typos will result in an error message – for example, example.ocm isn’t a real TLD, wwww.example.com probably doesn’t resolve, xample.com is probably a real domain but you don’t control it and can’t validate it… – instead of unexpectedly succeeding. Still, you have to be careful about typos.


#14

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