[Bug 65591] New: Standard + non-standard SSL port + name-based vhosts + SNI: Port number disregarded when selecting certificate?

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65591

            Bug ID: 65591
           Summary: Standard + non-standard SSL port + name-based vhosts +
                    SNI: Port number disregarded when selecting
                    certificate?
           Product: Apache httpd-2
           Version: 2.4.6
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_ssl
          Assignee: bugs@httpd.apache.org
          Reporter: bjorn.wiberg@uu.se
  Target Milestone: ---

It appears that when using both a standard (443) and a non-standard (8443) SSL
port together with name-based virtual hosts and SNI, Apache does not consider
the port number when selecting which certificate to serve to the client if
multiple vhosts have equal ServerNames (but different ports).

Instead, Apache appears to serve the certificate from the first listed vhost
with a matching ServerName, regardless of the port number.

Furthermore, ServerAliases appear not to be considered when determining which
vhost will serve the actual web content.


Consider the following configuration. Two default vhosts to catch "unexpected"
requests, followed by two "real" vhosts serving the actual web content:

Listen 443 https
Listen 8443 https

<VirtualHost *:443>
  ServerName default_vhost_ssl

  SSLEngine on
  SSLCertificateFile /etc/pki/tls/certs/idp-frontend.crt
  SSLCertificateKeyFile /etc/pki/tls/private/idp-frontend.key
  SSLCertificateChainFile /etc/pki/tls/certs/idp-frontend.chain

  <Location "/">
    Options None
    Require all denied
  </Location>
</VirtualHost>

<VirtualHost *:8443>
  ServerName default_vhost_ssl_8443

  SSLEngine on
  SSLCertificateFile /opt/shibboleth-idp/credentials/idp-backchannel.crt
  SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp-backchannel.key
  # no SSLCertificateChainFile as the certificate is self-signed

  <Location "/">
    Options None
    Require all denied
  </Location>
</VirtualHost>

<VirtualHost *:443>
  ServerName myservice.com

  SSLEngine on
  SSLCertificateFile /etc/pki/tls/certs/idp-frontend.crt
  SSLCertificateKeyFile /etc/pki/tls/private/idp-frontend.key
  SSLCertificateChainFile /etc/pki/tls/certs/idp-frontend.chain
</VirtualHost>

<VirtualHost *:8443>
  ServerName myservice.com

  SSLEngine on
  SSLCertificateFile /opt/shibboleth-idp/credentials/idp-backchannel.crt
  SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp-backchannel.key
  # no SSLCertificateChainFile as the certificate is self-signed
</VirtualHost>

Testing with:

openssl s_client -connect myservice.com:8443 -no_ssl2 -no_ssl3 -debug
-servername 'myservice.com' < /dev/null

...appears to yield the idp-frontend.crt certificate (incorrect), but no
certificate chain (correct).

I would have expected Apache to serve the idp-backchannel.crt certificate and
no certificate chain. I would definitely not have expected to get the wrong
certificate but the correct (no) certificate chain.

Is this expected behavior, or could there perhaps be some kind of bug in the
vhost/certificate selection process when using SNI?


Adjusting the ServerName in the "real" (last) 8443 vhost to:

  ServerName myservice.com:8443

...as per https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23 will
instead cause the SNI name (which is "myservice.com") not to match the
ServerName, causing Apache to select the default 8443 vhost, so not serving any
"real" content any longer (yielding 404s to the client).

Trying to add a ServerAlias in the "real" (last) 8443 vhost to overcome this:

  ServerName myservice.com
  ServerAlias myservice.com:8443

...appears not to work. Apache appears to only consider ServerNames when
determining which vhost will serve the web content when using SNI.

The only easy work-around for this that I can think of would be to skip having
a default 8443 vhost.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org