Certbot on Apache - Unable to Find Domains Due to Multiple Hosts in Config File


#1

Whenever I try to run the cli, it says that it can’t find my server names in the vhosts, despite them being setup and working correctly.

$ ./letsencrypt-auto --apache

No names were found in your configuration files.
You should specify ServerNames in your config files in order to
allow for accurate installation of your certificate.
If you do use the default vhost, you may specify the name manually.
Would you like to continue?

$ ./letsencrypt-auto --apache -d pressbuilt.com

No vhost exists with servername or alias of: pressbuilt.com. No
vhost was selected. Please specify servernames in the Apache config

$ apache2ctl -t -D DUMP_VHOSTS

VirtualHost configuration:
*:80                   is a NameVirtualHost
         default server forgue.net (/etc/apache2/sites-enabled/000-forgue.net.conf:1)
         port 80 namevhost forgue.net (/etc/apache2/sites-enabled/000-forgue.net.conf:1)
                 alias www.forgue.net
         port 80 namevhost aaronforgue.com (/etc/apache2/sites-enabled/aaronforgue.com.conf:1)
                 alias www.aaronforgue.com
         port 80 namevhost clients.pressbuilt.com (/etc/apache2/sites-enabled/clients.pressbuilt.com.conf:1)
         port 80 namevhost invoices.pressbuilt.com (/etc/apache2/sites-enabled/invoices.pressbuilt.com.conf:1)
         port 80 namevhost jeaniedstylist.com (/etc/apache2/sites-enabled/jeaniedstylist.com.conf:1)
                 alias www.jeaniedstylist.com
         port 80 namevhost karens-studio.com (/etc/apache2/sites-enabled/karens-studio.com.conf:1)
                 alias www.karens-studio.com
         port 80 namevhost pluginforge.com (/etc/apache2/sites-enabled/pluginforge.com.conf:1)
                 alias www.pluginforge.com
         port 80 namevhost pressbuilt.com (/etc/apache2/sites-enabled/pressbuilt.com.conf:1)
                 alias www.pressbuilt.com
         port 80 namevhost trekkingpoleguide.com (/etc/apache2/sites-enabled/trekkingpoleguide.com.conf:1)
                 alias www.trekkingpoleguide.com

$ lsb_release -a

No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 12.04.5 LTS
Release:	12.04
Codename:	precise

$ apache2 -v

Server version: Apache/2.4.16 (Ubuntu)


#2

I would recommend running the script with the -vv argument for debugging purposes. Now we’d be just guessing…


#3

I ran it with the -vv option and just saw a bunch of “Requirement already up to date” messages, but nothing that looked like an error.

When I got to the “No names specified” screen and answered “No”, the following output was dumped:

Exiting abnormally:                                                  │  
                                                 │ Traceback (most recent call last):                                   │  
                                                 │   File "/home/aaron/.local/share/letsencrypt/bin/letsencrypt", line  │  
                                                 │ 11, in <module>                                                      │  
                                                 │     sys.exit(main())                                                 │  
                                                 │   File                                                               │  
                                                 │ "/home/aaron/.local/share/letsencrypt/local/lib/python2.7/site-packa │  
                                                 │ ges/letsencrypt/cli.py", line 1283, in main                          │  
                                                 │     return args.func(args, config, plugins)                          │  
                                                 │   File                                                               │  
                                                 │ "/home/aaron/.local/share/letsencrypt/local/lib/python2.7/site-packa │  
                                                 │ ges/letsencrypt/cli.py", line 465, in run                            │  
                                                 │     domains = _find_domains(args, installer)                         │  
                                                 │   File                                                               │  
                                                 │ "/home/aaron/.local/share/letsencrypt/local/lib/python2.7/site-packa │  
                                                 │ ges/letsencrypt/cli.py", line 111, in _find_domains                  │  
                                                 │     raise errors.Error("Please specify --domains, or --installer     │  
                                                 │ that "                                                               │  
                                                 │ Error: Please specify --domains, or --installer that will help in    │  
                                                 │ domain names autodiscovery

#4

Try the manual mode with certonly --manual -d …


#5

Did you ever figure this out? I am running into the exact same problem, exact same platform.


#6

Unfortunately, no. I was able to get a cert generated using certonly, but I had to do all the Apache vhost configuration by hand.


#7

Oh ok thanks. Yeah will probably just do that. I still keep wondering what it is… hmmm…


#8

Had the same problem. Turns out the solution was fairly simple. . . YMMV.

It seems letsencrypt looks in /etc/apache2/sites-available and not /etc/apache2/sites-enabled. The trick is to create the .conf files in sites-available and have a symbolic link in sites-enabled, just like the default apache conf file.

It was a wonderfully simple exercise after that.


#9

I had the same problem (letsencrypt 0.3.0 on debian). What helped in my case was changing the order of the VirtualHost entries:

Command: /root/.local/share/letsencrypt/bin/letsencrypt certonly --apache -d xxx.de -d www.xxx.de --renew-by-default
Error message: No vhost exists with servername or alias of: xxx.de. No vhost was selected. Please specify servernames in the Apache config

Not working:
<VirtualHost xxx.de:443>
SSLEngine on
ServerName xxx.de
ServerAlias www.xxx.de
SSLCertificateFile /etc/letsencrypt/live/xxx.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxx.de/privkey.pem
DocumentRoot /var/www/xxx
</VirtualHost>
<VirtualHost *:80>
ServerName xxx.de
DocumentRoot /var/www/xxx/
</VirtualHost>
<VirtualHost *:80>
ServerName www.xxx.de
...
</VirtualHost>
<VirtualHost *:80>
ServerName yyy.xxx.de
DocumentRoot /var/www/yyy
</VirtualHost>

Working:
<VirtualHost *:80>
ServerName xxx.de
DocumentRoot /var/www/xxx/
</VirtualHost>
<VirtualHost *:80>
ServerName www.xxx.de
...
</VirtualHost>
<VirtualHost *:80>
ServerName yyy.xxx.de
DocumentRoot /var/www/yyy
</VirtualHost>
<VirtualHost xxx.de:443>
SSLEngine on
ServerName xxx.de
ServerAlias www.xxx.de
SSLCertificateFile /etc/letsencrypt/live/xxx.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxx.de/privkey.pem
DocumentRoot /var/www/xxx
</VirtualHost>

With earlier letsencrypt versions it worked without this modification.


#10

This is upsetting. Software should be both documented and stable, and letsencrypt is neither. (Gentoo, letsencrypt-0.5.0)


#11

I think it’s more like the service “Let’s Encrypt” is stable, not specifically the client… As the version numbering shows, it’s still in its 0.x.x phase.


#12

While the official client isn’t stable (as a 0.5 version number clearly indicates), it is well documented. But if you don’t like that, you can always use one of the other clients that are stable (as well as well documented) such as NeilPang’s acme.sh client, which is already at version 2.

This seems to be a very common mistake, conflating the service with the client. I see people in these forums do it all the time. The front page of the community forums clearly has a list of available clients from various authors for various platforms to suit various needs. And it’s the first thing on the page. I’m not sure how it could be made more prominent.


#13

By the way, do you miss Gentoo specific documentation? I’ve tried to make the documentation rather complete for Gentoo: http://letsencrypt.readthedocs.io/en/latest/using.html#operating-system-packages Should get anyone pretty much started.


#14

Actually, only the git version of letsencrypt-apache is in portage. The versioned ones are in my overlay :slight_smile: That is interesting what you figured out about httpd.conf. I wonder if I could modify the ebuild to make it work correctly. Of course, it worked in 0.4.2 just fine, but not in 0.5.0, so something changed somewhere…


#15

There were a few unfortunate regressions in 0.5 (e.g. domain order being scrambled). 0.6 was supposed to be out weeks ago, but something is delaying it. I’m guessing it’s taking a lot longer to squash all the known bugs than expected.


#16

I wonder what you think the best resolution would be for Gentoo. Should we just use 0.4.2, mask 0.5.0 preventing its use, and wait for 0.6.0, or is there a patch we should try?


#17

When I had a bug due to a python cryptography library being outdated in ports (I’m on FreeBSD), I downgraded to 0.4.2, and it worked like a charm. Everything worked flawlessly. (Then later that same day the library was updated and 0.5 started working again!)

I don’t know how easy it is in Gentoo’s portage, but it was easy in FreeBSD after installing portdowngrade. Do you have anything similar?


#18

In Gentoo, downgrading is as simple as choosing which version you want to install. It is even possible, depending on the package, to have several versions installed simultaneously, such as with python. Gentoo is the only flavor of Linux I have ever been able to get to do what I want.

I downgraded to 0.4.2 and it was giving a different error, complaining that I was running an outdated version. Now I am using the git version, and after struggling with this for a while I have my certificates renewed.

My point is that since you put this in cron and forget about it, the behavior cannot change or the renewals will fail.


#19

I figured out the “No names were found in your configuration files” problem. If you have multiple v-hosts in one config file, LE freaks out. You have to split every vhost up into its own config file in sites-available, make a symbolic link to sites-enabled, remove your default config, restart apache and LE worked as expected.


#20

Bummer! The ports version leaves updating up to the sysadmin, so it doesn’t run a version check at all.

I’m glad you got it working, even though it took more effort than it should have.

I don’t understand what you mean. Automation is one of the key goals of Let’s Encrypt (second only to “free”). What do you mean “behaviour cannot change”? The official client is beta software! Of course I’m still monitoring it’s behaviour and development! For example, starting with 0.6 (which is already overdue), it will be known as “certbot”. Besides, behaviour can change without a failure, as you demonstrated - renewal didn’t fail, it’s just the certificate names were in the wrong order. The certificate will still work for most things.

Once the client development reaches a more stable and mature level, I’m going to start trusting it more and monitoring it less (just like you trust what’s in your crontab). It’s the Nirvana Fallacy to pretend everything must be perfectly trustworthy before it can be used via cron.