Letsencrypt messed up Apache2 multidomain config


#1

Hello!

I recently received the letsencrypt Digest mail where I spotted the topic “Help us test renewal with “letsencrypt renew”” and today I received the expiry warning. So I did give it a try and followed the instructions. But the renew command failed, it used standalone plugin while Apache was running. Which is fine, because I initially used the standalone plugin.

Now I have a Apache2 config with three domains, one domain uses the letsencrypt certs. Since renew param didn’t work, I started letsencrypt directly and it didn’t show me the correct domains to request certificates for. It showed only one domain from the three domains in the Apache2 config. So I cancelled and added -d param with my domains (-d example.com -d www.example.com).

letsencrypt somehow managed to renew the certificates, but changed the Apache2 config and left it messed up. The problem was letsencrypt added the various cert entries to the other domains. Best thing would be letsencrypt just does the renewal and does not change the Apache2 configuration at all.

The question is, how can I prevent letsencrypt from editing the Apache2 configuration but in the same time, make letsencrypt renew work?

And is it save to post letsencrypt logs so you guys can take a look at?

Best regards,
Billie


#2

Hi @Billie, are you saying that you want the cert to cover those domains but you don’t want to reference it in the Apache config for the virtual hosts for two of them?

If you want to change the configuration to no longer attempt to install those certificates, you could try

letsencrypt certonly -a apache -i None -d onedomain.example.com -d anotherdomain.example.com -d thirddomain.example.com

You might have to add --force-renew if the certificate is not near to expiry.

If you obtain a new version of the certificate this way, then I would expect that letsencrypt renew would no longer try to install it upon renewal.

Another option is to change the certificate lineage to use webroot (for example -a webroot -i None), to avoid modifying the Apache configuration at all, even for authentication purposes.

With client version 0.4.0 it should only be necessary to do the certonly command once and then the settings should be saved and apply to any future renew. Feel free to let me know if this doesn’t make the appropriate changes and we can try to figure out what went wrong (or to correct me if I’ve misunderstood what you’re looking for).


#3

Hi @Schoen. If I run letsencrypt like you suggested, the same problem seems to occur. So I get the message:

We were unable to find a vhost with a ServerName or Address of example.com.
Which virtual host would you like to choose?
default-ssl.confg | Multiple Names | HTTPS
000-default.conf | Multiple Names

If I select “More Info”, is shows me only one vhost of the three existing. I cancel now and wait for your expert opinion.

Best regards,
Billie


#4

All my VHosts were in a single file, turns out letsencrypt’s apache plugin can’t handle that by now and I had to move each VHost to its own file under sites-available.


#5

Or use “certonly” and then manually adjust your vhosts to point at the certificates. That’s what I did :wink:

This is one of those things that really irk me. It’s not a vhost file, it’s a vhosts file, plural. Until I read these forums and realised the client expected each vhost in it’s own file, I didn’t even know that was possible.

Given that the second key goal of Let’s Encrypt is automation, this is a pretty big oversight. Especially given how quite the documentation is about it - you have to read appropriate issues in the forums to find out the client can’t handle vhosts in a vhosts file.