osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 62356] *:443 VirtualServer incorrectly fails with AH02572 on start up


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

Eric Covener <covener@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|                            |All

--- Comment #1 from Eric Covener <covener@xxxxxxxxx> ---
(In reply to ricky rocker from comment #0)

> sometimes however, instead of using the correct https://x.y.z to access the
> site, people use https://www.x.y.z
> 
> Certificates are pricey and I do not want to have to have 2 just so that
> people can connect via x.y.z and www.x.y.z
> 
> ...so what I have done is create 2 virtual servers as follows:
> 
> <VirtualHost *:443>
> ServerName www.x.y.z
> RewriteEngine On
> RewriteRule (.*) https://x.y.z/ [R]
> </VirtualHost>
> 
> <VirtualHost *:443>
> ServerName x.y.z
> SSLEngine on
> SSLCertificateFile /etc/pki/tls/certs/x_y_z.crt
> SSLCertificateKeyFile /etc/pki/tls/private/x_y_z.key
> .....
> 
> 
> As you can see, now what happens is that if someone connects using 
> 
> https://www.x.y.z all that happens is the url is rewritten to be
> https://x.y.z and the second virtual host is triggered, enabling the ssl
> engine and applying the appropriate certificate.

I don't see how that can work, the client using https://www.x.y.z will try to
handshake and your server will think you are sending gibberish (handshake
bytes) instead of an HTTP request.

> "the default https port" as sacrosanct and applying rules to it that may not
> be desired in every case; and are in any event configurable via other means
> should they be desired. 

It sounds like your desired behavior is a dead-end as only one side will
actually be using SSL. 

Presumably some piece of mod_ssl treats the canonical port for https as
implicitly https (although I didn't see it right away). It doesn't try to load
SSL if you explicitly code 'SSLEngine off'.  I don't think it's asking much to
have someone opt-out of SSL on port 443 on the server side to protect them from
an unusable-in-practice vhost.

In this case the startup failure looks like it has warned you about what is
basically a doomed configuration rather than starting up and logging cryptic
messages.

> I can - and should be able to - to start the SSL engine on any port and
> likewise I can - and should be able to - tell a browser to use any port for
> communicating via https - simply by doing https://x.y.z:[any port I choose]

What does this have to do with SSL being used by default in your config? 

-/-

I will leave the bug open for others more interested in SSL to review, but it
does not look like a default that I'd personally be keen on changing for the
reasons above

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