Multiple virtual hosts, multiple domains in host one cert for each host


#1

I’m confused about the initial command, I thought by entering each virtual host behind -w dir x -d urthllc.com, www.urthllc.com -w dir y -d unitedrealtytexas.com, www.unitedrealtytexas.com would issue separate certificates for each host? I got all my sites working but it seems to point to one cert?

My domain is: urthllc.com, www.urthllc.com, unitedrealtytexas.com, .net etc…

I ran this command: certbot --apache -w /var/www/xxxxx -d urthllc.com, www.urthllc.com -w /var/www/yyyy -d unitedrealtytexas.com, www.unitedrealtytexas.com

It produced this output: It it gave me all my certs and updated all the .conf files in apache but it seems to point to just one certificate, I thought by listing each directory using the -w would give a separate certificate for each host?

My web server is (include version):Apache 2.4.18

The operating system my web server runs on is (include version):Ubuntu 16.04.5 LTS

My hosting provider, if applicable, is:

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


#2

When you string them together in one single command request, they generally all get done at the same time and are placed into a single cert.
I’m not even sure you can explicitly request them to be separate from a single command line request.
But that may be possible, maybe, with something like:
--certname first-cert -d first.domain
--certname second-cert -d second.domain
Ideally you could just make separate requests; one for each cert.

…or we can ask just an expert @schoen


#3

Thanks for the reply, guess I was just confusing that entering each directory separately was going to issue a cert just for that directory/domain group.
At this point do I just delete the /etc/letsencrypt directory to start over?

Thanks,
Tony


#4

The way that Certbot is designed, it issues one certificate per run. To get multiple certificates, you need to run Certbot multiple times.

You could delete the certificate that you didn’t want with certbot delete (specifying its name with --cert-name) and you can use certbot certificates to confirm which certificates you’ve issued.

People often want this. :slight_smile: But it has more benefits when the names are mostly subdomains of a single registered domain. In this case, combining them into a single certificate would avoid hitting Let’s Encrypt’s Certificates Per Registered Domain rate limit on issuance. Since you’re requesting certificates for different registered domains, that’s not an issue for you.


#5

Sorry for all the questions but just to clarify in my head:

Running certbot multiple times (once per virtual host) the -w argument would not be needed correct? just the -d for each of the included domains?


#6

You only need multiple -w arguments if the different domains have different webroots individually (which would normally be the case if the associated site content is different).


#7

You still need as many -w arguments as are necessary for the domain(s) you’re including. Using the example in your first post, that’s one for each command.


#8

@mnordhoff’s answer is better than mine because I misread the question and answered a different question instead.


#9

Prior to seeing this answer, I had already redone my certs but I didn’t use the -w on any virtual host that had all domains pointing to one web directory, I only used the -d for each of the domains and subdomains that were listed in that particular virtual host. The only time I actually used the -w was when I had a subdomain that actually pointed to a different web directory than the upper level domain yet I wanted those two listed on the same cert. Everything worked as planned or so it appeared. Should I redo everything again using the -w on every single run of certbot based on your statement or wait and see?

Thanks


#10

Did you maybe get prompted interactively by Certbot asking you for the webroot directory in each case?


#11

No, only the question about redirecting choose 1,2


#12

Well, I don’t know how you managed to specify the webroots. Maybe you could look at or post some of the renewal configurations from /etc/letsencrypt/renewal to make sure that they make sense.


#13

Here is one that I did not use the -w:

# renew_before_expiry = 30 days
version = 0.26.1
archive_dir = /etc/letsencrypt/archive/tonyhager.com
cert = /etc/letsencrypt/live/tonyhager.com/cert.pem
privkey = /etc/letsencrypt/live/tonyhager.com/privkey.pem
chain = /etc/letsencrypt/live/tonyhager.com/chain.pem
fullchain = /etc/letsencrypt/live/tonyhager.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
installer = apache
authenticator = apache
server = https://acme-v02.api.letsencrypt.org/directory

This one I did use the -w:

# renew_before_expiry = 30 days
version = 0.26.1
archive_dir = /etc/letsencrypt/archive/urthllc.com
cert = /etc/letsencrypt/live/urthllc.com/cert.pem
privkey = /etc/letsencrypt/live/urthllc.com/privkey.pem
chain = /etc/letsencrypt/live/urthllc.com/chain.pem
fullchain = /etc/letsencrypt/live/urthllc.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
server = https://acme-v02.api.letsencrypt.org/directory
installer = apache
authenticator = apache
account = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
webroot_path = /var/www/urthllc/html, /var/www/urthllc/crm
[[webroot_map]]
urthllc.com = /var/www/urthllc/html
urtholdingsllc.com = /var/www/urthllc/html
www.urthllc.com = /var/www/urthllc/html
www.urtholdingsllc.com = /var/www/urthllc/html

#14

Thanks for posting those. The difference is that one of them uses --apache and the other uses --webroot. These are different Certbot plugins which perform slightly different actions to satisfy the CA’s challenge. The --apache method temporarily modifies your Apache configuration (and then restores it at the end of the process), while --webroot creates a temporary file. Because of this difference, --apache doesn’t need a directory to be specified, while --webroot does.

If the --apache method works for your needs, it may be preferable (among other things because it wouldn’t be as sensitive to later changes in the individual virtual hosts’ configurations).


#15

You’re welcome.
By the way, when running I did not type --apache so it did that on its own.

I’m curious about the latter one. Why is there not a [webroot_map] for the crm.urthllc.com domain?

Is it in fact setup correctly?


#16

Could you give an example of one of the command lines that ended up using the Apache plugin?

Hmmm, maybe not! The webroot_path there contains two directories but should only contain one. The webroot_map, as you pointed out, doesn’t mention the CRM subdomain. The webroot_map takes priority over the webroot_path when both exist, but it seems like each of them is incorrect in a different way. Could you also show the command line that resulted in this one?

You can test the renewal of this certificate with

certbot renew --dry-run --cert-name urthllc.com

(This won’t update your certificate on disk or count against your renewal rate limit, because it will use the staging server for the renewal and not save the resulting test certificate.)


#17

Here is how I submitted the first with only one directory:

certbot -d tonyhager.com -d www.tonyhager.com -d tonyhager.net -d www.tonyhager.net -d tonyhager.org -d www.tonyhager.org -d hagerhome.com -d www.hagerhome.com

And the other :

Initially ran this but forgot the crm.urthllc.com so I then expanded it.

certbot -d urthllc.com -d www.urthllc.com -d urtholdingsllc.com -d www.urtholdingsllc.com

certbot --expand -w /var/www/urthllc/html -d urthllc.com -d www.urthllc.com -d urtholdingsllc.com -d www.urtholdingsllc.com -w /var/www/urthllc/crm -d crm.urthllc.com


#18

Which version of Certbot are you running?


#19

0.26.1

Didn’t I read somewhere that the server stores my default once I run it one time? It only prompted for my email one time so does it just recognize that I’m using apache?


#20

The defaults in question are mostly per-certificate and shouldn’t apply to future certificates (although the account registration-related items, including e-mail, do!).