Seeing Encountered vhost ambiguity but unable to ask for user guidance below when running certbot renew --dry-run, similar to Auto renewal ambiguity with certbot but I have multiple vhosts
I am seeing errors with vhost ambiguity. One of my config files (scoretility.com.conf) has an alias between www.scoretility.com and scoretility.com but the other files do not.
When I ran this with just beta.scoretility.com configured, the command ran clean.
Can I ignore these errors, or do I have to make some changes before renewal?
[root@loutilities sites-available]# ls /etc/letsencrypt/live
beta.scoretility.com sandbox.scoretility.com scoretility.com
[root@loutilities sites-available]# certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/scoretility.com.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for scoretility.com
tls-sni-01 challenge for www.scoretility.com
Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories.
Falling back to default vhost *:443...
Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories.
Falling back to default vhost *:443...
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0005_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0005_csr-certbot.pem
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/beta.scoretility.com.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for beta.scoretility.com
Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories.
Falling back to default vhost *:443...
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0006_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0006_csr-certbot.pem
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/sandbox.scoretility.com.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for sandbox.scoretility.com
Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories.
Falling back to default vhost *:443...
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0007_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0007_csr-certbot.pem
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/scoretility.com/fullchain.pem (success)
/etc/letsencrypt/live/beta.scoretility.com/fullchain.pem (success)
/etc/letsencrypt/live/sandbox.scoretility.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
Thanks for the response. Is there something I should do differently so this runs clean? One issue with these errors is the cron job will send me an email twice a day.
I’m not sure what Certbot is expecting here instead (I assume it’s possible to edit the Apache config files in a way that does avoid the errors, I just don’t know what that way is).
You could suppress the particular error by wrapping the call to certbot renew in a shell script, for example like
Sorry for my delayed response here. I agree with @schoen that if --dry-run worked you can reasonably expect renewal to work properly. With that said, I think there may either be a bug in our Apache plugin or your server is misconfigured. I have a couple of questions:
What version of Certbot are you using?
What’s the output of grep -ir -e servername -e serveralias /etc/apache2/sites-available/? If you’re not on a Debian based system, you should change /etc/apache2/sites-available to the path to your vhosts being used by Apache.
Ah. While I was unable to reproduce the exact problem, I suspect it is due to you have multiple virtual hosts in a single file. While this completely valid in Apache, Certbot doesn’t properly support this yet (see our GitHub). We’re actively working on this and planning to have full support in the next release.
In the meantime, if your sites are working properly (no TLS errors, proper redirects, etc.) and certbot --dry-run works, you won’t have any problems with renewal. If you do any manual modification of the virtualhosts, it’s not a bad idea to try certbot --dry-run again to make sure everything still works as intended.
Thanks. Let me know if you’d like copies of my apache config files to reproduce. Think it may not be a good idea to post here, but would email or put on shared google drive. BTW I also had trouble with the initial configuration. I had to use --certonly to make certbot work at all. Was chicken/egg problem with cert directives in the apache config file. I could try to reconstruct and open a separate discussion topic if you want and post the log files, but I had successful workaround so didn’t bother at the time.
When you finally got it to work with certonly did you know if you used the Apache plugin or another method like webroot or standalone?
And that’d be great if you could share your config files with me just so I can verify there’s not another problem here beyond Certbot not currently supporting multiple vhosts per file. My e-mail address is bmw@eff.org.
I sent you the files which were in /etc/httpd/sites-available. Note I use apache 2.4.6, which comes with the latest distributed CentOS 7, yum update run weekly.
On the certonly question, I think I used the Apache plugin, because I don’t know what webroot or standalone means. Here is my log contents (note reverse time order). I can also supply the referenced certbot logs if that would be helpful.
### set up ssl certifications {server}scoretility.com per https://letsencrypt.org/getting-started/, https://wiki.centos.org/HowTos/Https
### NOTE: after each of these changes sudo apachectl restart was done
2017-03-26 06:21 (root) crontab -e # add calls /root/bin/checkcerts (https://community.letsencrypt.org/t/autorenew-vhost-ambiguity/30580)
2017-03-24 09:00 (root) certbot renew --dry-run # errors - see letsencrypt-2017-03-24-09-00.log
2017-03-24 08:40 add extra directives to scoretility.com.conf
2017-03-24 08:36 (root) certbot --apache -d scoretility.com -d www.scoretility.com certonly
2017-03-24 08:27 add extra directives back to sandbox.scoretility.com.conf
2017-03-24 08:24 (root) certbot --apache -d sandbox.scoretility.com certonly
2017-03-24 08:23 removed extra directives from sandbox.scoretility.com.conf
2017-03-24 08:18 (root) certbot --apache -d sandbox.scoretility.com certonly
2017-03-24 08:18 sudo vim /etc/httpd/sites-available/sandbox.scoretility.com.conf # removed SSLCertificateFile and SSLCertificateKeyFile directives
2017-03-24 08:13 (root) certbot --apache -d sandbox.scoretility.com *** Error while running apachectl configtest - see certbot-log-2017-03-24-08-15.txt
2017-03-24 08:12 sudo vim /etc/httpd/sites-available/sandbox.scoretility.com.conf # add SSLEngine, SSLCertificateFile and SSLCertificateKeyFile directives
2017-03-23 16:23 sudo vim /etc/httpd/sites-available/beta.scoretility.com.conf # add SSLEngine on -- https://beta.scoretility.com is now secure
2017-03-23 16:06 (root) certbot --apache -d beta.scoretility.com *** Error while running apachectl graceful see certbot-log-2017-03-23-16-06.txt
2017-03-23 15:53 sudo vim /etc/httpd/sites-available/beta.scoretility.com.conf # add SSLCertificateFile and SSLCertificateKeyFile directives
2017-03-23 15:48 (root) certbot --apache -d beta.scoretility.com *** Cannot find a cert or key directive - see see certbot-log-2017-03-23-15-48.txt
2017-03-23 13:49 (root) certbot --apache -d beta.scoretility.com *** internal error occurred - see certbot-log-2017-03-23-13-49.txt
2017-03-23 13:47 updated beta.scoretility.com to support port 443 (ssl)
2017-03-23 13:32 (root) yum install mod_ssl openssl [Nothing to do -- see https://wiki.centos.org/HowTos/Https]
2017-03-23 10:57 (root) certbot --apache *** timeout getting to https port on server - see certbot-log-2017-03-23-11-03.txt
2017-03-23 10:25 sudo yum install python-certbot-apache
### end set up ssl certifications {server}scoretility.com
Interestingly, after taking a fresh Apache install on CentOS7, removing existing vhosts in /etc/httpd/conf.d, adding your files, commenting out WSGI directives, and making sure existing paths have exist/have certs, I was unable to reproduce the problem.
I have another additional theory though. Do you have files in /etc/httpd/conf.d? Are those files being loaded by Apache? If not, if you temporarily move the files there to another location, does it remove the warning about vhost ambiguity?
Thanks for your log as well. I’m sorry you had so many issues getting Certbot to work. I believe these issues will be resolved when we properly support multiple vhosts per file and better support WSGI modules though.
I do have files in /etc/httpd/conf.d, and yes they are loaded by apache. My apache install is whatever is the latest by yum from base or epel for CentOS 7. I’ve also installed some php stuff like phpAdmin if that matters. Should I send these to you as well? Is my WSGI vhost causing the problem?
My failure to reproduce earlier was my own fault. I’m sorry about that. I appreciate you following up with more information and offering to provide even more though. People like you make debugging Certbot easy.
After digging into this, the problem is the multiple virtual hosts per file. To complete the domain validation challenge necessary for renewal, Certbot needs to find the IP address and port you’re using for your vhost for that domain. Currently, however, Certbot just ignores files with multiple vhosts in them so it fails to find the vhost and falls back to *:443 as you can see from its output. This works for your setup though and again we expect this problem to be fixed in the next release. In the meantime, I encourage you to do something like what schoen provided above to avoid getting e-mail from cron for the next month.
Thanks again for taking the time to report this and provide all the information you have!
You’re welcome. Happy to help. Being a software developer myself, I understand how difficult it must be to build software for and provide support to the many environments you must encounter.
Thanks for providing this service to the internet community, and if there’s anything else I can do to help please let me know.