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.wib...@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-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org