_default_ VirtualHost overlap on port 443, the first has precedence

  • I have managed to get it all set up and RT running OK with named virtual
    host over http. However, I am having problems with getting them to work over
    https. When I set a virtual host name, it always serves the first listed
    domain. See settings below. https:firstone serves the correct folder, but
    https:rt serves firstone’s documents

my settings:

<VirtualHost *:443>

DocumentRoot "C:/Development/firstone"
ServerName firstone
ServerAdmin webmaster@localhost
ErrorLog logs/ssl/error.log
TransferLog logs/ssl/access.log

SSLEngine on…etc

<VirtualHost *:443>
ServerName rt.hostname.com
DocumentRoot /data/rt3/share/html
AddDefaultCharset UTF-8
PerlModule Apache::DBI
PerlRequire /data/rt3/bin/webmux.pl
<Location /NoAuth/images>
SetHandler default

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSLRequireSSL

SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/sslcertificate/server.crt
SSLCertificateKeyFile /etc/sslcertificate/server.key

while restarting apache I get a warning << default VirtualHost overlap on
port 443, the first has precedence>>

Any suggestions???

Thanks in advance,
rq

Each SSL site pretty much needs to be on it’s own IP address, the
reasoning is the cert negotiation isn’t name based header as apache
would. The only other way would be to have them on different ports but
then you’d have to specify the port when going to the site.

testwreq wreq wrote:

Actually, I should have mentioned before that our rt installation is on a
different IP.On Fri, Aug 21, 2009 at 11:09 AM, Curtis Bruneau curtisb@vianet.ca wrote:

Each SSL site pretty much needs to be on it’s own IP address, the reasoning
is the cert negotiation isn’t name based header as apache would. The only
other way would be to have them on different ports but then you’d have to
specify the port when going to the site.

testwreq wreq wrote:

I have managed to get it all set up and RT running OK with named virtual
host over http. However, I am having problems with getting them to work over
https. When I set a virtual host name, it always serves the first listed
domain. See settings below. https:firstone serves the correct folder, but
https:rt serves firstone’s documents

my settings:

<VirtualHost *:443>

DocumentRoot "C:/Development/firstone"
ServerName firstone
ServerAdmin webmaster@localhost
ErrorLog logs/ssl/error.log
TransferLog logs/ssl/access.log

SSLEngine on…etc

<VirtualHost *:443>
ServerName rt.hostname.com http://rt.hostname.com
DocumentRoot /data/rt3/share/html
AddDefaultCharset UTF-8
PerlModule Apache::DBI
PerlRequire /data/rt3/bin/webmux.pl
<Location /NoAuth/images>
SetHandler default

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSLRequireSSL

SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/sslcertificate/server.crt
SSLCertificateKeyFile /etc/sslcertificate/server.key

while restarting apache I get a warning << default VirtualHost overlap
on port 443, the first has precedence>>
Any suggestions???

Thanks in advance,
rq
*


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media. Buy a
copy at http://rtbook.bestpractical.com

Try naming the virtual hosts. *:443 means any domain that resolves to that
machine will get the first one, since it matches.

Curtis may also be right (never tried two https sites on the same box), but
try having the first one be and the second one
and see if it works for you.On 8/21/09 11:13 AM, “testwreq wreq” testwreq@gmail.com wrote:

Actually, I should have mentioned before that our rt installation is on a
different IP.

On Fri, Aug 21, 2009 at 11:09 AM, Curtis Bruneau curtisb@vianet.ca wrote:

Each SSL site pretty much needs to be on it’s own IP address, the reasoning
is the cert negotiation isn’t name based header as apache would. The only
other way would be to have them on different ports but then you’d have to
specify the port when going to the site.

testwreq wreq wrote:

I have managed to get it all set up and RT running OK with named virtual
host over http. However, I am having problems with getting them to work over
https. When I set a virtual host name, it always serves the first listed
domain. See settings below. https:firstone serves the correct folder, but
https:rt serves firstone’s documents

my settings:

<VirtualHost *:443>

DocumentRoot "C:/Development/firstone"
ServerName firstone
ServerAdmin webmaster@localhost
ErrorLog logs/ssl/error.log
TransferLog logs/ssl/access.log

SSLEngine on…etc

<VirtualHost *:443>
ServerName rt.hostname.com http://rt.hostname.com/
<http://rt.hostname.com http://rt.hostname.com/ <http://rt.hostname.com
<http://rt.hostname.com/> >

  DocumentRoot /data/rt3/share/html
  AddDefaultCharset UTF-8
  PerlModule Apache::DBI
  PerlRequire /data/rt3/bin/webmux.pl
   <Location /NoAuth/images>
           SetHandler default
   </Location>
  ErrorLog logs/ssl_error_log
  TransferLog logs/ssl_access_log
  LogLevel warn
  <Directory />
     SSLRequireSSL
  </Directory>
   SSLEngine on
   SSLProtocol all -SSLv2
   SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
   SSLCertificateFile /etc/sslcertificate/server.crt
   SSLCertificateKeyFile /etc/sslcertificate/server.key
while restarting apache I get a warning <> Any suggestions???

Thanks in advance,
rq
*


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
http://wiki.bestpractical.com/
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media. Buy a
copy at http://rtbook.bestpractical.com http://rtbook.bestpractical.com/


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


Drew Barnes
Applications Analyst
Network Resources Dept.
Raymond Walters College

I tried and the second one
but still https://rt.hostname.com goes to https;//firstone

While restarting apache, the warning message now was:
[Fri Aug 21 11:20:23 2009] [warn] VirtualHost firstname:443 overlaps with
VirtualHost rt.hostname.com:443, the first has precedence, perhaps you need
a NameVirtualHost directive

Not sure what NameVirtualHost directive is…On Fri, Aug 21, 2009 at 11:17 AM, Drew Barnes barnesaw@ucrwcu.rwc.uc.eduwrote:

Try naming the virtual hosts. *:443 means any domain that resolves to that
machine will get the first one, since it matches.

Curtis may also be right (never tried two https sites on the same box), but
try having the first one be and the second one
and see if it works for you.

On 8/21/09 11:13 AM, “testwreq wreq” testwreq@gmail.com wrote:

Actually, I should have mentioned before that our rt installation is on a
different IP.

On Fri, Aug 21, 2009 at 11:09 AM, Curtis Bruneau curtisb@vianet.ca wrote:

Each SSL site pretty much needs to be on it’s own IP address, the reasoning
is the cert negotiation isn’t name based header as apache would. The only
other way would be to have them on different ports but then you’d have to
specify the port when going to the site.

testwreq wreq wrote:

I have managed to get it all set up and RT running OK with named virtual
host over http. However, I am having problems with getting them to work over
https. When I set a virtual host name, it always serves the first listed
domain. See settings below. https:firstone serves the correct folder, but
https:rt serves firstone’s documents

my settings:

<VirtualHost *:443>

DocumentRoot "C:/Development/firstone"
ServerName firstone
ServerAdmin webmaster@localhost
ErrorLog logs/ssl/error.log
TransferLog logs/ssl/access.log

SSLEngine on…etc

<VirtualHost *:443>
ServerName rt.hostname.com http://rt.hostname.com/http://rt.hostname.com/ <http://rt.hostname.com
http://rt.hostname.com/http://rt.hostname.com+<http//rt.hostname.com/>

  DocumentRoot /data/rt3/share/html
  AddDefaultCharset UTF-8
  PerlModule Apache::DBI
  PerlRequire /data/rt3/bin/webmux.pl
   <Location /NoAuth/images>
           SetHandler default
   </Location>
  ErrorLog logs/ssl_error_log
  TransferLog logs/ssl_access_log
  LogLevel warn
  <Directory />
     SSLRequireSSL
  </Directory>
   SSLEngine on
   SSLProtocol all -SSLv2
   SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
   SSLCertificateFile /etc/sslcertificate/server.crt
   SSLCertificateKeyFile /etc/sslcertificate/server.key
while restarting apache I get a warning <> Any suggestions???

Thanks in advance,
rq
*


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
http://wiki.bestpractical.com/ http://wiki.bestpractical.com/
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media. Buy a
copy at http://rtbook.bestpractical.com http://rtbook.bestpractical.com/http://rtbook.bestpractical.com/



http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


Drew Barnes
Applications Analyst
Network Resources Dept.
Raymond Walters College

Each SSL site pretty much needs to be on it’s own IP address, the
reasoning is the cert negotiation isn’t name based header as apache
would. The only other way would be to have them on different ports but
then you’d have to specify the port when going to the site.

In practice yes, but technically no. SNI allows https to do name-based
virtual hosts,
although mod_ssl (and older browsers) do not support it. For this reason we use
mod_gnutls. http://www.outoforder.cc/projects/apache/mod_gnutls/sni/
Cambridge Energy Alliance: Save money. Save the planet.

Hmm, actually it looks like Apache just picked up SNI a few months ago in 2.3

Cambridge Energy Alliance: Save money. Save the planet.

SNI looks interesting. We set up this using a SAN cert and info from http://blog.revolunet.com/index.php/reseau/administration/hosting-multiple-ssl-vhosts-on-a-single-ipportcertificate-with-apache2

Regards,
JasonOn 21 Aug 2009, at 16:35, Jerrad Pierce wrote:

Hmm, actually it looks like Apache just picked up SNI a few months
ago in 2.3


Cambridge Energy Alliance: Save money. Save the planet.


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com