Certbot Apache Plugin Not Installing and Configuring VHOST files as Expected


i am just new to LetsEncrypt and i already like the idea behind it. I run a few personal websites and i have a bit complex setup on my machine. I am trying to run certbot --apache but currently i always end up with some sort of “Error: should only be one vhost in…” errors.

Maybe i am doing something wrong?

This is my setup:

  • main domain: mydomain.org (which has a virtualhost pointing to www.mydomain.org)
  • virtualhosts with only HTTP (at the moment): www, aaa, bbb, ccc, ddd, eee, fff, ggg
  • virtualhosts with HTTPS and HTTP: xxx
  • virtualhosts with only HTTPS: hhh, iii

All are currently working properly with self-signed certs or some other certs (free).

The webserwer is Apache and the server runs Gentoo Linux (certbot is latest from GIT installed trough portage).

The config files layout is this:

  • /etc/apache/httpd.conf (just modules setup and includes, no virtualhosts)
  • /etc/apache/vhosts.d/mydomain.org.conf (just includes the other same name file under [domain_home], no directive)
  • /etc/apache/vhosts/default.conf (only Port directive and not much more)

Then under the [domain_home] folders i have:
[domain_home]/conf/mydomain.org.conf (this one includes the following files, no directives)
[domain_home]/conf/_.conf (this one is the virtualhost for the “mydomain.org” main domain)

Each one of these files has ONE virtual host in it, except for the only one (xxx) which has TWO (one for port 80 one for the same virtualhost, port 443).

Certbot idendifies correctly all my domains…
Creates all the certs properly…

always fails at installing them with the “Error: should only be one vhost in [domain_home]/conf/yaddayadda.conf

If i remove the “yaddayadda” file, it will just fail again on another random one.

I tried to search the forums and the most obviuous issues… But i could not fix it at all.

Can anybody help me out? I am a total loss now.


Hi @gardiol,

I’m sorry that the “should only be one vhost” issue still exists; one of the developers has been getting close to an update that should remove this restriction. This issue has been one of the trickiest problems with Certbot over time and has caused trouble for many users.

It sounds like the version of Certbot you have might have a bug in detecting and reporting exactly which file is responsible for this error. So I can suggest four potential solutions:

① Make sure your Certbot is the most current version (using the self-updating certbot-auto script instead of an OS package), since some bugs related to this issue have been fixed over time.

② Wait for a future release which will remove this restriction entirely (this might take several more weeks, though).

③ Use an authentication method other than TLS-SNI-01, which then won’t require Certbot to be able to parse your Apache configuration files. The main alternative is the HTTP-01 method, used by the webroot plugin (certbot --webroot). This can work as long as each of your domain names has an HTTP listener on port 80 that can serve files publicly when they’re placed into a specified directory. When using --webroot or -a webroot, Certbot won’t need to parse Apache config files at all in order to obtain the certificate.

④ Change your config file structure to remove the one remaining case where multiple vhosts are present in the same file.


To fix this issue, i just run certbot with certonly and manually generated one certificate for each virtualhost, then i manually modified my config files to load those certificates. A bit more lengthy than the automatic solution, but it worked great.

I guess my main error was to assume that certbot should edit my apache config files. Better to it manually and all is well!


hi @gardiol

if you point all your certs to the live directory you shouldn’t have to do this again :smiley:

also there is an option to use post renewal scripts if the installers themselves don’t work as advertised

The renew command includes hooks for running commands or scripts before or after a certificate is renewed. For example, if you have a single cert obtained using the standalone plugin, you might need to stop the webserver before renewing so standalone can bind to the necessary ports, and then restart it after the plugin is finished. Example:

certbot renew --pre-hook “service nginx stop” --post-hook “service nginx start”



Yes, i am using the live folder… by ssl cert directives point to the live folder… Is this what you mean?


hi @gardiol

yup that is what i mean :smiley:

sounds like you have things sorted


I have to say it is not super-clear what you need to do. Providing a “bot” which automates it all it’s nice, but i guess it’s not very good for your audience, which is also composed of a bit more tech savvy people than the average. I mean, if you run your own webserver you must understand a bit of what goes on under the hood. A bot which automates it all with no clear documentation at what it does it’s not very nice nor very trustworthy.

Maybe a few mor lines detailing what goes on and what it actually does would help.

For example, in my case, just a note saying “by running certonly will require you to add the SSLCertificates directives to your conf files…” or something similar with a brief example would have saved me half day trying to figure out the stupid and obscure error message, which, to be honest, should NOT be there at all, since the BOT should NOT be writing to my apache config files at all, it’s just the wrong way to do it.

Sorry, my 2 cents! The all idea behind let’s encrypt is great and it feels butter smooth… just the bot (which is the “recomended” way to go) seems a bit creepy and frankly too dumbed-down for what it does. By dumbed down i mean it hides what it tries to do… assuming i would not understand or i don’t care.


Hi @gardiol,

I’m working on some documentation that explains how each of the authentication challenges works, so hopefully that will help. Meanwhile, one of my colleagues is working on fixing this bug so that people won’t have this particular problem in the future.

Sorry for the rough edges in Certbot. Having people come here and ask questions is a big part of helping us understand what we need to fix or make clearer! I hope you have a comfortable and reliable experience with Let’s Encrypt in the future.


Thank you! i am sure it will be greatly appreciated by many, miself included.


yeah that is a big challenge

ACME is a machine to machine protocol so clients are a big part of it

there is a range of clients available some which make things really easy some of which are slightly trickier

one of the things a lot of people forget is certbot is not the only client or always the best client for the job

for example: for quick tests i prefer manual-le as it just tells me what i needs to know and dumps certs where i need to find them

saying that certbot does do things really well as well which is really a nice feature

like most new technologies it’s a matter of getting the ideas behind it and then figuring out the implementations

if you try to jump straight into doing without orienting your way to the way the tool works then you can run in to trouble

My 2 cents as well :wink:



I fully agree with you. But, and this is why i emphatized it, certbot is the recomended tool… like, the tool supported and offered as “official” tool, and that is why i went for it. I would probably have settled for a bash client, as it is my preferred way to go usually, but i got certbot working satisfactory for my setup anyway, so i prefer to stay with the “recomended” tool.

I am just telling that to a newcomer (technical one, but not very strong on certs stuff) it looks like the “official” way is too much dumbed down to a point it feels… unconfortable. Yes there are other ways, but not being “recomended” or “official” in any way, i preferred banging my head on certbot.

Now, after “understanding” i like it and i just feel that if it was a bit less opaque from the beginning it would have saved me half day. No big deal, to be honest, but still… it’s my small way to try to contribute.


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