No vhost was selected #2776
Comments
|
@joohoi want to take this? |
|
@hugo-connery the fact that you have a |
|
Yeah, I'll take this. @hugo-connery thanks for extensive information about the environment! However if you could send us the output of: python -c 'import platform;print([platform.system(),platform.linux_distribution()[0]])' to make sure we end up using the correct system layout and defaults for your distribution (want to verify that we are actually searching correct paths for the vhosts) |
|
Hi, No problem. Will do. I appreciate the fast response. Long live LE. Hugo ConneryHead of IT, DTU Environment, http://www.env.dtu.dk From: Joona Hoikkala [notifications@github.com] Yeah, I'll take this. @hugo-conneryhttps://github.com/hugo-connery thanks for extensive information about the environment! However if you could send us the output of: python -c 'import platform;print([platform.system(),platform.linux_distribution()[0]])' to make sure we end up using the correct system layout and defaults for your distribution (want to verify that we are actually searching correct paths for the vhosts) � |
|
Hi, I'm not sure that this is going to help you much, but ['Linux', 'CentOS Linux'] is the output of the command you wished me to run. I would think that this is a sub-set of the information Whatever. Hugo ConneryHead of IT, DTU Environment, http://www.env.dtu.dk From: Joona Hoikkala [notifications@github.com] Yeah, I'll take this. @hugo-conneryhttps://github.com/hugo-connery thanks for extensive information about the environment! However if you could send us the output of: python -c 'import platform;print([platform.system(),platform.linux_distribution()[0]])' to make sure we end up using the correct system layout and defaults for your distribution (want to verify that we are actually searching correct paths for the vhosts) � |
|
Yeah, it's just the actual calls we're using to get the distribution / os string, so wanted to make sure that it's detected correctly - just like it seems to be. I confirmed that your VirtualHost configuration parses fine, so it must be something related to configuration layout / distribution defaults. Does your virtualhost configuration file reside under /etc/httpd/conf.d and does the configuration file that holds the vhost have other vhosts in it? |
|
Perhaps another instance of this? |
|
In case it is, here is some information: /etc/apache2/sites-available/cbmission.org.conf says at the top: and later: python -c 'import platform;print([platform.system(),platform.linux_distribution()[0]])' says: Let me know if there's other information that would be helpful. |
|
Got the same issue with two vhosts which where perfectly configured before - and destroyed after the renewal process.
|
|
@bret-miller & @thorstensiefert & @hugo-connery : could you post the contents of LE log file to a pastebin in case it has some more information on this. The file in question is /var/log/letsencrypt/letsencrypt.log |
|
I did several domains on Friday. Here's the log from then: |
|
@bret-miller The log file doesn't seem to have a reference to the failed run you reported earlier, or did the run(s) on the log also result into similarily broken config files? If not, could you check /var/log/letsencrypt/letsencrypt.log.1 letsencrypt.log.2 and so on, for the one that has the information on the run with domain www.cbmission.org |
|
@joohoi Every run on that server since has had the same issue. Unfortunately, I'm in the middle of moving a bunch of websites from DreamHost to Google Cloud where the issue occurred. The .10 file is the oldest and it's from 2016-04-08. It had the same issue--just a different domain. A thought occurred to me this morning that I have a couple of default Apache config files in sites-available that aren't linked from sites-enabled. Maybe the fact that those don't contain a ServerName or ServerAlias directive is confusing the LE client. Was going to try deleting them today and trying another domain to see if that worked around the issue... just haven't had a chance yet. |
|
OK. That was worse. Having the 000-default.conf and ssl-default.conf in place, the LE client still acquires the certificate for the requested domain, then prompts for which .conf to update. Then I 'c' for cancel and manually update the $domain.conf manually. At least that works around it. When I remove the default .conf files, the LE client doesn't even try to get the certificate. It just fails. |
|
@bret-miller I still can't reproduce the problem, any chance you could provide me with an tarball of your |
|
As requested by Joona Hoikkala, here are some more details. I re-ran letsencrypt-auto --apache -d sec.it.env.dtu.dk and selected 'update' the existing cert (which I got using --certonly). Error: No vhost exists with servername or alias of: sec.it.env.dtu.dk. No vhost was selected. Please specify servernames in the Apache config The config is unchanged from above (and as you can see does declare the vhost). letsencrypt.log 2016-04-12 07:10:02,451:DEBUG:letsencrypt.main:Root logging level set at 30 |
|
@hugo-connery Thanks for the additional data, the followup questions: Does your virtualhost configuration file reside under /etc/httpd/conf.d and does the configuration file that holds the vhost have other vhosts in it? |
|
@bret-miller Thanks for the apache configuration tarball. I'll investigate the problem and the error messages further with your configuration. However it should be noted that LE client expects a single virtualhost configuration inside a configuration file, and your setup seems to have both: <VirtualHost *:80> and <VirtualHost *:443> configurations within a file per domain. For better compatibility as of now, I'd suggest that you'd split the config files in two: one for the HTTP vhost config and one for the HTTPS one. As said above, we'll continue to look into this matter and at minimum - work to ensure that the config won't get broken. |
|
@bret-miller for reference, this issue is reported in #1042 We'll keep this issue open as others in the discussion most likely have different issue at hand. |
|
In my case I am not using 000-default but just defined conf files for each tool I am using. Since the upgrade I also cannot get it to detect the different conf files. It keeps wanting me to use 000-default and other default files but not the actual conf files. When I run the renew command it has a record of the proper conf files but resorts to the 000-default again? |
|
@shaneonabike The client doesn't actually save the config file paths, only the domains. And while default domains don't have ServerName or ServerAlias defined, they actually match them all. This issue is most likely due to your vhost files not being properly parsed. I would need to get hold of your apache configuration directory to be able to look further into it. |
|
OK. So for new domains I will start making separate files for the ssl and non-ssl vhosts. Did my first one. LE client is still not installing the certificate in the configuration. I emailed the log and vhost files to @joohoi again. Command line is: |
|
I answered you via email, but I think it's best to continue the discussion here: The relevant part from logs, anonymized: Unfortunately I’m unable to reproduce the problem. Looking at the logs, it seems like Let’s Encrypt thinks it’s creating a new configuration file, but in reality the file already exists, and is enabled. LE fails when trying to activate an already activated vhost. Could you describe your setup before, and after. Also were you renewing the domains or getting the initial certificate? What I suppose your configuration looks before: Vhost for HTTP : apache/sites-available/domain.conf -> apache/sites-enabled/domain.conf So the both are active before run, right? I’m trying to pinpoint why |
|
I'm not sure what the issue was earlier, but I did have to create the domain-ssl link in sites-enabled manually, so that was probably it. I have been splitting the conf files up to get this working correctly, and the last one I did issued and installed its certificate perfectly. So while combining single domain vhosts in a conf file worked in LE client 0.4.2, it does not in LE client 0.5.0. The answer is split them all up. |
|
Are we still able to use the multiple -d options for one certificate rather than declaring one certificate for each conf file? Meaning... can I do ./letsencrypt-auto --apache -d beesonabike.com -d www.beesonabike.com -d somethingelse.beesonabike.com Before this worked properly but I suspect in my case at least this might be the reason that it is now failing because it's trying to find the "one" conf file that matches all of these defined URLS |
|
@shaneonabike All of my certificates are issued with at least the domain and www.domain. Several have a dozen or more subdomains in them. However, I recently changed from using -d on the command line to creating a .ini file with domains=domain1,domain2,domain3,... and using -c ini-file on the command line. This makes scripting the command easier when you're adding a domain to an existing certificate. I know it works with 0.5.0 because I used it today. |
|
I could try using the ini file... did you find that in the docs? |
|
@shaneonabike Yes, it is mentioned in the docs. It also tells you more about the available parameters in the command-line help. I only use it for the domains= list, but you can pretty much put everything in the .ini file if you want. |
|
@joohoi I can't find your contact info so am unable to fire off a tarball your way |
|
Oh, sorry. Try joona@kuori.org |
|
@shaneonabike I checked through your apache configuration, and seems like your issue is similar - you have multiple VirtualHost definitions per file. Split your configuration up to have a single VirtualHost per file and you should be ok. |
|
@hugo-connery @thorstensiefert If you are still having problems, (and it's not caused by having multiple vhosts in single file), could you provide some more information, for example the tarball of your apache config to enable me to look further into this matter? |
|
@joohoi I can confirm that separating them out makes it work perfectly (although this is a change since the last major release). Can this be documented somewhere unless I missed it previously. For other users to be clearer:
Then you want to convert this to and 80-mysite.conf |
|
I'll see if I can split the virtual host definitions into separate /Hugo |
|
Or better yet put that into the help documentation of the command-line tool |
|
I'll give it a try.
|
|
Hi, Much improvement. The cert was renewed and installed and configured. It complained about: Unable to add title IMPORTANT NOTES:
And the certificate configuration lines do not use either Cheers, Hugo |
|
@joohoi I tried (#2776 (comment)) and it works fine for me. |
|
Where to put the documentation? I suggest a page at letsencrypt.org which talks about the recommended structure for vhost definitions under /etc/httpd/conf.d/ That page, which should show a minimal server config with two sites, can be linked to from the getting started page in the section where it discusses Apache. Secondly, it can be issued as an information message if someone uses letsencrypt-auto --apache. i.e "Please use our recommended configuration layout for virtual hosts for better results: https://letsencrypt.org/apache-vhost-config.html" or equivalent. Thanks to all who have contributed to the thread. I'm happy to have a working model which I can then use for all my other sites and servers :) /Hugo |
|
@thorstensiefert awesome! @hugo-connery I think that the correct place would actually be a notification that the client emits when it stumbles across a vhost file with more than one VirtualHost definition. I'll create a new issue for that, because this issue is too long to quickly get a glimpse of what's going on. Another thing: that message "Unable to add title" is emitted by reverter, which handles config rollbacks, and it basically gets printed when the reverer is unable to add a checkpoint for a file. Might be worthwhile to investigate further, if on the next run it still gets displayed, but I wouldn't worry for it as of now. |
|
Reason: User has multiple VirtualHost configurations per file. 0.5.0 enforces stricter rules on vhost configuration, so the client is unable to find correct VirtualHost configurations. Solution: Split VirtualHost configurations to one vhost per file. I think this issue is pretty much solved. @hugo-connery I think you can close this for now, and open a new one for the reverter error if you stumble upon it again, it's outside of the scope of this issue. |
|
Yes. Issue is closed. Source of problem (multiple vhosts in a config file) identified and fixing this fixes the problem. /Hugo |
|
I also had the same issue with the same resolution. My HTTP and HTTPS vhosts were defined in the same config file. Separating them solved the issue. |
|
I've experienced the same issue and was very sad to see that the support for multiple vhosts per config file was removed - and even worse no correct error message was displayed :( |
|
Everything was working fine with multiple VHosts per config file provided that they weren't for the same port (i.e. VHost:80 and VHost:443 in the same config file was ok, whereas Vhost:443 + VHost:443 was not supported). And now this doesn't work anymore? Why? That's quite a PITA since I have a long list of conf files for each subdomain which combines the VHost 80 and the VHost 443 and now I have to split all of them in two... I know that multiple HTTPS VHosts per file was never supported, but one HTTPS VHost + the HTTP one did work fine before. And now it's not supported anymore apparently? To me that looks like a regression... |
|
In case it may be useful to someone else, I've used a small bash script to help me split my numerous config files: #!/bin/bash
set -e
NAME=$1
#csplit -f $NAME.conf $NAME.conf '/^<VirtualHost \*:443>$/'
csplit -f $NAME.conf $NAME.conf '/^<IfModule mod_ssl\.c>$/'
mv $NAME.conf00 $NAME-80.conf
mv $NAME.conf01 $NAME-443.conf
a2dissite $NAME.conf
a2ensite $NAME-80.conf
a2ensite $NAME-443.confIt uses the Depending on your config files, the pattern can be The convention assumed here is that:
Now it's still your job to check that the resulting files are correct and to reload apache. The original config files are not deleted, you may want to do it manually once you've made sure everything works. |
|
The fix for this shipped today. Please open a new ticket if you're seeing this problem in Certbot 0.6.0! |
Firstly, I ran a successful certonly -d ... type run yesterday, and deployed that to https://sec.it.env.dtu.dk So, well done LetsEncrypt for that.
Today, with the release of 0.5.0 I wanted to re-try the --apache plugin, as it failed yesterday.
I'm running RHEL 7 with IPv6 as a virtual machine over a Windows HyperV installation (just to make stuff interesting ;).
$ uname -a
Linux vwww3.env.dtu.dk 3.10.0-327.13.1.el7.x86_64 #1 SMP Thu Mar 31 16:04:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ httpd -V
Server version: Apache/2.4.6 (CentOS)
Server built: Nov 19 2015 21:43:13
Server's Module Magic Number: 20120211:24
Server loaded: APR 1.4.8, APR-UTIL 1.5.2
Compiled using: APR 1.4.8, APR-UTIL 1.5.2
Architecture: 64-bit
Server MPM: prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/usr/sbin/suexec"
-D DEFAULT_PIDLOG="/run/httpd/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
$ ./letsencrypt-auto --version
Checking for new version...
Requesting root privileges to run letsencrypt...
/root/.local/share/letsencrypt/bin/letsencrypt --version
letsencrypt 0.5.0
$ ./letsencrypt-auto --apache -d sec.it.env.dtu.dk
ncurses display .... No names were found in your configuration files.\nYou should specify ServerNames...
Config:
<VirtualHost 192.38.76.15:443 [2001:878:200:2000:0003::2]:443>
ServerAdmin webmaster@env.dtu.dk
DocumentRoot /var/www/html/sec.it.env.dtu.dk
ServerName sec.it.env.dtu.dk
ErrorLog logs/sec.it.env.dtu.dk-error_log
CustomLog logs/sec.it.env.dtu.dk-access_log common
DirectoryIndex index.html
#
# SSL Config
#
SSLEngine on
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK"
SSLCertificateKeyFile /etc/letsencrypt/live/sec.it.env.dtu.dk/privkey.pem
SSLCertificateFile /etc/letsencrypt/live/sec.it.env.dtu.dk/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/sec.it.env.dtu.dk/chain.pem
# HSTS
Header add Strict-Transport-Security "max-age=15768000"
<Directory /var/www/html/sec.it.env.dtu.dk>
AllowOverride none
Require all granted
Options +Indexes
As you can verify the site works, thus the config is fine. Apache 2.4.6 does not seem to need NameVirtualHost directives, and they are not in the config.
I dont have a problem as the cert isn't expiring soon, and the "certonly" method works fine and I can easily install them. But, it is funny that the client cant see this obvious virtual host. IPv6 ??
Thanks all for the LE efforts.
/Hugo
The text was updated successfully, but these errors were encountered: