<VirtualHost *> problems

[bmw]

Steps to reproduce:

1. Take the default Apache config and change the default vhost from <VirtualHost *:80> to <VirtualHost *>.
2. Run certbot -d <domain> --apache for any domain name pointing at that server.

Domain validation fails. The vhost the Apache plugin makes is something like the following:

<IfModule mod_ssl.c>
<VirtualHost *>
    ServerName 996de558c87bf78211dfe71c0cfa7f33.8bfada933e08175738f69ac8321bf840.acme.invalid
    UseCanonicalName on
    SSLStrictSNIVHostCheck on

    LimitRequestBody 1048576

    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /var/lib/letsencrypt/_Ql9ONFhja57j8csu0ORv8MGshr_1dtCyNa8AuP4h1Q.crt
    SSLCertificateKeyFile /var/lib/letsencrypt/_Ql9ONFhja57j8csu0ORv8MGshr_1dtCyNa8AuP4h1Q.pem

    DocumentRoot /var/lib/letsencrypt/tls_sni_01_page/
</VirtualHost>

</IfModule>

Trying to connect to the server using openssl s_client for the above ServerName causes:

140246747047576:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

At first glance the generated vhost looks right to me. Perhaps the problem is having both HTTP and HTTPS vhosts using <VirtualHost *> and we should make the challenge vhost <VirtualHost *:443> in this case?

Any thoughts @joohoi?

[jenlampton]

I'm having the same problem described in #3103 with an Apache / CentOS server. I believe the site is using a certificate from let's encrypt I set up last June, but when I tried to update it today using Certbot the bot was unable to read my ViurtualHost configurations.

• My vhosts are in the bottom of my httpd.conf file, so I'm not running into the problem of them not being located because they are in separate files.
• My virtualhost directives are spelled out <VirtualHost *:8080> so I am not running into an issue with capitalization.

I've also been displeased with the lack of the most basic of documentation on CertBot. For example, where do I need to be on the server before running the commands listed on https://certbot.eff.org/#centos6-apache? How many times do I need to run through those instructions if I have three sites/domains I want certificates for on the same server? Three times, or just once? Does the certbot-auto file really need to be placed into the document root for each site on the server? If not, where is the correct location(s) for that file?

These instructions seem to assume a very high level of understanding of how certbot works - or at the very least what it's doing - but none of that information is provided before we're launched into running these commands. Even just a paragraph saying what will happen when you run it would be helpful. Something like "THESE files will be placed in THIS directory" might help us figure out where to run the commands.

(I'm hoping my problem isn't that I was in the wrong directory when I ran certbot-auto --apache.)

[osirisinferi]

At first glance the generated vhost looks right to me. Perhaps the problem is having both HTTP and HTTPS vhosts using <VirtualHost *> and we should make the challenge vhost <VirtualHost *:443> in this case?

That is correct. See for more information about the selection process how Apache ends up at which VirtualHost section:

• https://httpd.apache.org/docs/2.4/vhosts/name-based.html
• https://httpd.apache.org/docs/2.4/mod/core.html#virtualhost

This causes trouble like in #4169 (we've seen a lot of those on the Community!)

TL;DR version with my interpretation:

• First, Apache will select the VirtualHost corresponding with the most detailed (i.e., non-wildcard) IP and port combination. If such a VirtualHost exists, wildcard VirtualHosts will be ignored. If more than one VirtualHost based on IP/port remains, Apache will look at the ServerName directive, but again, ignore the other "wildcard" VirtualHosts;
• If such an IP/port match doesn't exist, Apache will look at VirtualHost sections with wildcards;
• It probably will prefer wildcard IP's with a specified port number above just a wild card without specifying a port number;
• If nothing gives a specific (IP/port) matches, Apache will look at the ServerName directive.

As the tls-sni-01 challenge always uses port 443, I see no harm in always specifying that port?

Edit:
Just changed a virtualhost on my test system from *:80 to * and indeed, certbot fails.

I just don't understand how someone gets a <VirtualHost *> actually working. If I'm working with a system with *:80 or :443 mixed with just *, every <VirtualHost *> directive doesn't work! It just.. Doesn't work? It always picks one of the virtualhosts with a port specified, also over plain HTTP.. And it's impossible to get TLS working without specifying a port! If I only have plain HTTP <VirtualHost *> sections, Boulder replies with "Failed to connect to [2001:xxx:xxx:1::2]:443 for TLS-SNI-01 challenge: Server only speaks HTTP, not TLS"

[bmw]

@joohoi are you expecting to get this done for the release next week?

[joohoi]

Yes, it should be a short PR to review as well.

[narcisgarcia]

I have this same problem in separated scenario (webserver:443 certificateshost:80) sharing single public IP (1.2.3.4) with Apache profiles:

<VirtualHost *:443>
   ...
   SSLCertificateFile ".../default.example.net/fullchain.pem
</VirtualHost>
<VirtualHost *:443>
   ServerName      www.example.net
   ...
   SSLCertificateFile ".../www.example.net/fullchain.pem
</VirtualHost>

I run this, forwarding only port 80 to renewals host:
certbot certonly ... --standalone -n -d www.example.net
But ACME actions seem to include getting any certificate CN found when visiting client IP:
https://1.2.3.4:443/
https://1.2.3.4:80/

1. ACME server should not assume any served certificate and CN when "visiting" client HTTP/S. That certificate could be wrong, obsolete, self-signed, or default one for no-SNI clients.
2. ACME server should forget any :443 information if is switching to another port (:80).

[stale]

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no further activity, this issue will be automatically closed.

[narcisgarcia]

Solution to my particular problem has been:

$ certbot certonly --preferred-challenges http --standalone -n -d www.example.net

[bmw]

The issue I described in my original post has been resolved. If you're continuing to have problems here, please open a new issue and fill out the issue template so we can better help you.