mp4 issues

I am having an issue where I have 2 virtual hosts. One is ssl and the
other is not. Same web directory. I have some mp4 files that are
suppose to be played on the host with ssl. The files open quicktime
fine when it isn't ssl, but the open as text with ssl. I add the mime
settings in the global mime.types file, and other than ssl, the apache
config files for the two hosts are the same.

Can someone explain why the videos would play via http, but not via
https?


Mike

Re: mp4 issues

mtuller schrieb:
> I am having an issue where I have 2 virtual hosts. One is ssl and the
> other is not. Same web directory. I have some mp4 files that are

Virtual hosts does not exists for SSL connections. You can only have one
HTTPS web host service per IP address.

> suppose to be played on the host with ssl. The files open quicktime
> fine when it isn't ssl, but the open as text with ssl. I add the mime
> settings in the global mime.types file, and other than ssl, the apache
> config files for the two hosts are the same.
>
> Can someone explain why the videos would play via http, but not via
> https?

Normally it should work, but I think its a mime problem, the apache
server sends the wrong mime.

--
Regards,
Trinity Of Matrix
E-Mail (only for spammer): trinity.matrix@localhost.localdomain

Re: mp4 issues

Post removed (X-No-Archive: yes)

Re: mp4 issues

Davide Bianchi schrieb:
> On 2007-09-13, Trinity Of Matrix wrote:
>> Virtual hosts does not exists for SSL connections. You can only have one
>> HTTPS web host service per IP address.
>
> Not completely correct, you can have as many ssl site as you want per
> IP address but only one certificate.

You can not, because of a SSL certificate design problem and because its
not technically implemented:

1. In the certificate is hard written the full qualified domain name
(FQDN), which means that if your registered FQDN would be
myhost.domain.com and then you would like to use the same certificate on
myhome.foobar.com, then your web browser will complain that
"myhome.foobar.com" does not match with the FQDN in your registered SSL
certificate.

2. Your web browser is not sending the "Host:" tag in the HTTPS/1.1
header which is normally sent on HTTP/1.1 connections. Without this tag,
the apache server does not know with which website content it should
respond to your browser Request, so it will respond with the first one
you have set up in apache.

--
Regards,
Trinity Of Matrix
E-Mail (only for spammer): trinity.matrix@localhost.localdomain

Re: mp4 issues

Post removed (X-No-Archive: yes)

Re: mp4 issues

Davide Bianchi schrieb:
> On 2007-09-13, Trinity Of Matrix wrote:
>> myhost.domain.com and then you would like to use the same certificate on
>> myhome.foobar.com, then your web browser will complain that
>
> Yes, exactly. All of your ssl site will use the same certificate, that
> is fine as long as you're just interested in encryption, not in
> authentication or if you have a 'wildcard' certificate. It only depends
> on what you want to do. If is for an internal site (not exposed to the
> internet) I don't think anybody would complaint about it. In fact I
> said not _completely_ correct.

I agree for the point 1, however the wildcard certificate did not worked
out for me when I tested it.
But what is with point 2? If the web server does not know which hostname
you typed in your browser, you will never be able to have more than one
ssl host on your IP address.

--
Regards,
Trinity Of Matrix
E-Mail (only for spammer): trinity.matrix@localhost.localdomain

Re: mp4 issues

Post removed (X-No-Archive: yes)

Re: mp4 issues

Davide Bianchi schrieb:
> On 2007-09-13, Trinity Of Matrix wrote:
>> I agree for the point 1, however the wildcard certificate did not worked
>> out for me when I tested it.
>
> Hummm... strange... it did for me.

Its possible that I made somewhere a mistake in the configuration or
that Firefox does not support wildcards in SSL certificate (maybe IE
supports this).

>
>> But what is with point 2? If the web server does not know which hostname
>> you typed in your browser
>
> It will know as soon as he decrypt the request, to do so, you'll have
> to go through the warning that your browser will spit at you
> (the site and the certificate name don't match). Once this is out of
> the way, everything works as intended.

Its not possible because only in plain text connection the browser sends
in the HTTP request the requested FQDN.
Which means that in your case, once the data would be decrypted, there
should be a "Host: host.domain.com" field but this is missing because it
has not been implemented by the HTTPS protocol definition.
Look at here: http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html :

*** FAQ ***

Why is it not possible to use Name-Based Virtual Hosting to identify
different SSL virtual hosts?

Name-Based Virtual Hosting is a very popular method of identifying
different virtual hosts. It allows you to use the same IP address and
the same port number for many different sites. When people move on to
SSL, it seems natural to assume that the same method can be used to have
lots of different SSL virtual hosts on the same server.

It comes as rather a shock to learn that it is impossible.

The reason is that the SSL protocol is a separate layer which
encapsulates the HTTP protocol. So the SSL session is a separate
transaction, that takes place before the HTTP session has begun. The
server receives an SSL request on IP address X and port Y (usually 443).
Since the SSL request does not contain any Host: field, the server has
no way to decide which SSL virtual host to use. Usually, it will just
use the first one it finds, which matches the port and IP address specified.

You can, of course, use Name-Based Virtual Hosting to identify many
non-SSL virtual hosts (all on port 80, for example) and then have a
single SSL virtual host (on port 443). But if you do this, you must make
sure to put the non-SSL port number on the NameVirtualHost directive, e.g.

NameVirtualHost 192.168.1.1:80

Other workaround solutions include:

Using separate IP addresses for different SSL hosts. Using different
port numbers for different SSL hosts.

--
Regards,
Trinity Of Matrix
E-Mail (only for spammer): trinity.matrix@localhost.localdomain

Re: mp4 issues

Post removed (X-No-Archive: yes)

Re: mp4 issues

"Trinity Of Matrix" wrote in message
news:XxaGi.34177$jJ5.15224@newsfet03.ams...
>>> But what is with point 2? If the web server does not know which hostname
>>> you typed in your browser
>>
>> It will know as soon as he decrypt the request, to do so, you'll have
>> to go through the warning that your browser will spit at you (the site
>> and the certificate name don't match). Once this is out of
>> the way, everything works as intended.
>
> Its not possible because only in plain text connection the browser sends
> in the HTTP request the requested FQDN.
> Which means that in your case, once the data would be decrypted, there
> should be a "Host: host.domain.com" field but this is missing because it
> has not been implemented by the HTTPS protocol definition.

"that the SSL protocol is a separate layer which
encapsulates the HTTP protocol"

The SSL protocol does not have a host header, which is why you get a
certificate error (with the exception of wildcarded certs). Once past that
step the http protocol inside has the Host header and apache will locate the
correct virtual host using it.

Re: mp4 issues

phantom schrieb:
> "Trinity Of Matrix" wrote in message
> news:XxaGi.34177$jJ5.15224@newsfet03.ams...
>>>> But what is with point 2? If the web server does not know which hostname
>>>> you typed in your browser
>>> It will know as soon as he decrypt the request, to do so, you'll have
>>> to go through the warning that your browser will spit at you (the site
>>> and the certificate name don't match). Once this is out of
>>> the way, everything works as intended.
>> Its not possible because only in plain text connection the browser sends
>> in the HTTP request the requested FQDN.
>> Which means that in your case, once the data would be decrypted, there
>> should be a "Host: host.domain.com" field but this is missing because it
>> has not been implemented by the HTTPS protocol definition.
>
> "that the SSL protocol is a separate layer which
> encapsulates the HTTP protocol"
>
> The SSL protocol does not have a host header, which is why you get a
> certificate error (with the exception of wildcarded certs). Once past that
> step the http protocol inside has the Host header and apache will locate the
> correct virtual host using it.

But in the FAQ of Apache is clearly written:
"Since the SSL request does not contain any Host: field, the server has
no way to decide which SSL virtual host to use."

This means that your web browser is not sending this field?!

--
Regards,
Trinity Of Matrix
E-Mail (only for spammer): trinity.matrix@localhost.localdomain

Re: mp4 issues

"Trinity Of Matrix" wrote in message
news:c_aGi.34314$jJ5.31091@newsfet03.ams...
> phantom schrieb:
>> "Trinity Of Matrix" wrote in
>> message news:XxaGi.34177$jJ5.15224@newsfet03.ams...
>>>>> But what is with point 2? If the web server does not know which
>>>>> hostname you typed in your browser
>>>> It will know as soon as he decrypt the request, to do so, you'll have
>>>> to go through the warning that your browser will spit at you (the site
>>>> and the certificate name don't match). Once this is out of
>>>> the way, everything works as intended.
>>> Its not possible because only in plain text connection the browser sends
>>> in the HTTP request the requested FQDN.
>>> Which means that in your case, once the data would be decrypted, there
>>> should be a "Host: host.domain.com" field but this is missing because it
>>> has not been implemented by the HTTPS protocol definition.
>>
>> "that the SSL protocol is a separate layer which
>> encapsulates the HTTP protocol"
>>
>> The SSL protocol does not have a host header, which is why you get a
>> certificate error (with the exception of wildcarded certs). Once past
>> that step the http protocol inside has the Host header and apache will
>> locate the correct virtual host using it.
>
> But in the FAQ of Apache is clearly written:
> "Since the SSL request does not contain any Host: field, the server has no
> way to decide which SSL virtual host to use."
>
> This means that your web browser is not sending this field?!
>

Not in the SSL request, but it *IS* in the http request encapsulated inside.

Re: mp4 issues

Trinity Of Matrix wrote:
> Davide Bianchi schrieb:
>> On 2007-09-13, Trinity Of Matrix
>> wrote:
>>> myhost.domain.com and then you would like to use the same certificate
>>> on myhome.foobar.com, then your web browser will complain that
>>
>> Yes, exactly. All of your ssl site will use the same certificate, that
>> is fine as long as you're just interested in encryption, not in
>> authentication or if you have a 'wildcard' certificate. It only depends
>> on what you want to do. If is for an internal site (not exposed to the
>> internet) I don't think anybody would complaint about it. In fact I
>> said not _completely_ correct.
>
> I agree for the point 1, however the wildcard certificate did not worked
> out for me when I tested it.
> But what is with point 2? If the web server does not know which hostname
> you typed in your browser, you will never be able to have more than one
> ssl host on your IP address.
>

We use a wildcard certificate across a web server farm that handles 3+
million page requests/day. It works fine.

Jim

Re: mp4 issues

I don't have 2 separate sites. They are 2 virtual hosts for the same
site. One runs under https, the other under http. The domain is the
same.

Now, what about the problem with mp4 files?


On Sep 13, 10:56 am, Jim Hayter wrote:
> Trinity Of Matrix wrote:
> > Davide Bianchi schrieb:
> >> On 2007-09-13, Trinity Of Matrix
> >> wrote:
> >>> myhost.domain.com and then you would like to use the same certificate
> >>> on myhome.foobar.com, then your web browser will complain that
>
> >> Yes, exactly. All of your ssl site will use the same certificate, that
> >> is fine as long as you're just interested in encryption, not in
> >> authentication or if you have a 'wildcard' certificate. It only depends
> >> on what you want to do. If is for an internal site (not exposed to the
> >> internet) I don't think anybody would complaint about it. In fact I
> >> said not _completely_ correct.
>
> > I agree for the point 1, however the wildcard certificate did not worked
> > out for me when I tested it.
> > But what is with point 2? If the web server does not know which hostname
> > you typed in your browser, you will never be able to have more than one
> > ssl host on your IP address.
>
> We use a wildcard certificate across a web server farm that handles 3+
> million page requests/day. It works fine.
>
> Jim