Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Chris Gordon
Sorry, brevity is not my strong point.  
 
Because I do not know what your certs look like as far as what domain(s) are 
considered CNs I'm going to guess it has something to do with the following...
 
SSL wraps http and you need a cert to decrypt the data sent via SSL.  If you 
have 3 virtual hosts and you are using Name Based Virtual Hosting how does the 
Apache web server know which cert to use to decrypt and read the header so it 
can properly route the data.  The short answer per my understanding is that 
Apache has no clue and uses the default vhost's cert (the first one in the 
confi file) to read the SSL.  If these were all the same domain such as 
tuna.foo.com, seabass.foo.com and marlin.foo.com you could get away with using 
the same *.foo.com wildcard cert.   Here is a good doc with these work arounds: 
https://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf
 
I'm guessing your problem is somewhere in this domain.  I believe that Name 
Based Virtual Hosting is not the answer for you.  Try IP Based: 
http://httpd.apache.org/docs/2.2/vhosts/ip-based.html
 
or use a wildcard cert...  Here is a warning about your config and a better 
explanation I presume: 
http://wiki.apache.org/httpd/NameBasedSSLVHosts
 
I just ran into this.  Silly me for not realizing that a Web Server that routes 
bases on headers would need to read the encrypted header to route it.  
Chicken-Egg problem.
 
Chris --V


>>> Dennis Putnam  10/22/2013 8:26 AM >>>
I have 3 virtual hosts that for all I can see are configured identically
other the the obviously needed differences. The same is true of the 3
crt files.


ServerName public.mydomain.com
DocumentRoot /var/www/html
SSLEngine on
SSLCertificateFile /etc/httpd/SSL/public.crt
SSLCertificateKeyFile /etc/postfix/SSL/server.key


ServerName distrib.mydomain.com
DocumentRoot /var/www/html/distrib
SSLEngine on
SSLCertificateFile /etc/httpd/SSL/distrib.crt
SSLCertificateKeyFile /etc/postfix/SSL/server.key


ServerName mail.mydomain.com
DocumentRoot  /usr/local/squirrelmail/www
SSLEngine on
SSLCertificateFile /etc/httpd/SSL/mail.crt
SSLCertificateKeyFile /etc/postfix/SSL/server.key


The problem is that 2 of them work perfectly and the lock shows up in
the browser. With the third (public), I get a gray globe indicating
partial encryption which does not prevent eavesdropping. I have no clue
how to debug this or even where to look. Can someone point me in the
right direction? Thanks.




The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited.


Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Pete Houston
On Tue, Oct 22, 2013 at 08:26:57AM -0400, Dennis Putnam wrote:
> I get a gray globe indicating
> partial encryption which does not prevent eavesdropping. I have no clue
> how to debug this or even where to look. Can someone point me in the
> right direction? Thanks.

This is usually indicative of a page served over https which references
some elements served over http (ie. unencrypted). These unencrypted
elements are usually images, stylesheets, script files, etc. As such
it is unrelated to your server configuration and is entirely down to
the content.

HTH,

Pete
-- 
Openstrike - improving business through open source
http://www.openstrike.co.uk/ or call 01722 770036 / 07092 020107


pgpASDvapH3Ar.pgp
Description: PGP signature


Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Dennis Putnam
On 10/22/2013 9:10 AM, Chris Gordon wrote:
> Sorry, brevity is not my strong point. 
>  
> Because I do not know what your certs look like as far as what
> domain(s) are considered CNs I'm going to guess it has something to do
> with the following...
>  
> SSL wraps http and you need a cert to decrypt the data sent via SSL. 
> If you have 3 virtual hosts and you are using Name Based Virtual
> Hosting how does the Apache web server know which cert to use to
> decrypt and read the header so it can properly route the data.  The
> short answer per my understanding is that Apache has no clue and uses
> the default vhost's cert (the first one in the confi file) to read the
> SSL.  If these were all the same domain such as tuna.foo.com,
> seabass.foo.com and marlin.foo.com you could get away with using the
> same *.foo.com wildcard cert.   Here is a good doc with these work
> arounds:
> https://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf
>  
> I'm guessing your problem is somewhere in this domain.  I believe that
> Name Based Virtual Hosting is not the answer for you.  Try IP Based:
> http://httpd.apache.org/docs/2.2/vhosts/ip-based.html
>  
> or use a wildcard cert...  Here is a warning about your config and a
> better explanation I presume:
> http://wiki.apache.org/httpd/NameBasedSSLVHosts
>  
> I just ran into this.  Silly me for not realizing that a Web Server
> that routes bases on headers would need to read the encrypted header
> to route it.  Chicken-Egg problem.
>  
> Chris --V
>
>
> >>> Dennis Putnam  10/22/2013 8:26 AM >>>
> I have 3 virtual hosts that for all I can see are configured identically
> other the the obviously needed differences. The same is true of the 3
> crt files.
>
> 
> ServerName public.mydomain.com
> DocumentRoot /var/www/html
> SSLEngine on
> SSLCertificateFile /etc/httpd/SSL/public.crt
> SSLCertificateKeyFile /etc/postfix/SSL/server.key
> 
> 
> ServerName distrib.mydomain.com
> DocumentRoot /var/www/html/distrib
> SSLEngine on
> SSLCertificateFile /etc/httpd/SSL/distrib.crt
> SSLCertificateKeyFile /etc/postfix/SSL/server.key
> 
> 
> ServerName mail.mydomain.com
> DocumentRoot  /usr/local/squirrelmail/www
> SSLEngine on
> SSLCertificateFile /etc/httpd/SSL/mail.crt
> SSLCertificateKeyFile /etc/postfix/SSL/server.key
> 
>
> The problem is that 2 of them work perfectly and the lock shows up in
> the browser. With the third (public), I get a gray globe indicating
> partial encryption which does not prevent eavesdropping. I have no clue
> how to debug this or even where to look. Can someone point me in the
> right direction? Thanks.
>
>
>
>
> The information contained in this e-mail and any accompanying
> documents may contain information that is confidential or otherwise
> protected from disclosure. If you are not the intended recipient of
> this message, or if this message has been addressed to you in error,
> please immediately alert the sender by reply e-mail and then delete
> this message, including any attachments. Any dissemination,
> distribution or other use of the contents of this message by anyone
> other than the intended recipient is strictly prohibited.
Thanks for the reply. Now I'm confused. Doesn't the SSLCertificate
parameter for each VH say which cert to use? Why does it work for 2 of
the VH's but not the 3rd?


signature.asc
Description: OpenPGP digital signature


Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Yehuda Katz
On Tue, Oct 22, 2013 at 9:10 AM, Chris Gordon  wrote:

>  SSL wraps http and you need a cert to decrypt the data sent via SSL.  If
> you have 3 virtual hosts and you are using Name Based Virtual Hosting how
> does the Apache web server know which cert to use to decrypt and read the
> header so it can properly route the data.  The short answer per my
> understanding is that Apache has no clue and uses the default vhost's
> cert (the first one in the confi file) to read the SSL.  If these were all
> the same domain such as tuna.foo.com, seabass.foo.com and marlin.foo.comyou 
> could get away with using the same *.
> foo.com wildcard cert.   Here is a good doc with these work arounds:
> https://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf
>
> I'm guessing your problem is somewhere in this domain.  I believe that
> Name Based Virtual Hosting is not the answer for you.  Try IP Based:
> http://httpd.apache.org/docs/2.2/vhosts/ip-based.html
>

If that were the case, the browser would show a certificate error on all
but one host, not a partial error on just one of them.
I would go with Pete's answer first (that there might be images or
javascript served from http).


> or use a wildcard cert...  Here is a warning about your config and a
> better explanation I presume:
> http://wiki.apache.org/httpd/NameBasedSSLVHosts
>
> I just ran into this.  Silly me for not realizing that a Web Server that
> routes bases on headers would need to read the encrypted header to route
> it.  Chicken-Egg problem.
>

There is a solution for this which Apache supports: Server Name Indication
(SNI)
This lets the browser send the domain name requested before Apache chooses
a certificate to help it choose the correct one.

See http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

- Y


Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Dennis Putnam
On 10/22/2013 9:12 AM, Pete Houston wrote:
> On Tue, Oct 22, 2013 at 08:26:57AM -0400, Dennis Putnam wrote:
>> I get a gray globe indicating
>> partial encryption which does not prevent eavesdropping. I have no clue
>> how to debug this or even where to look. Can someone point me in the
>> right direction? Thanks.
> This is usually indicative of a page served over https which references
> some elements served over http (ie. unencrypted). These unencrypted
> elements are usually images, stylesheets, script files, etc. As such
> it is unrelated to your server configuration and is entirely down to
> the content.
>
> HTH,
>
> Pete
Thanks. That might make more sense (at least to me). After more reading,
I am not sure that I don't have SNI capable version of httpd already
installed (how do I tell?). The pages that work are very simple but the
one that doesn't is complex and has lots of graphics. If that is the
case, why are they not encrypted like everything else (assuming they are
not referenced on a different server)?



signature.asc
Description: OpenPGP digital signature


Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Yehuda Katz
On Tue, Oct 22, 2013 at 9:39 AM, Dennis Putnam  wrote:

> Thanks. That might make more sense (at least to me). After more reading,
>  I am not sure that I don't have SNI capable version of httpd already
> installed (how do I tell?). The pages that work are very simple but the
> one that doesn't is complex and has lots of graphics. If that is the
> case, why are they not encrypted like everything else (assuming they are
> not referenced on a different server)?
>

As I mentioned, if you don't have SNI, then you should see major warnings
from the browser that something is wrong when you go to any site but the
first one.

As far as finding the offending image: Go to the page in your browser,
right click on the page and choose view source (or a similar option). Then
search in the source for http://
That should let you find which images are not secure.
If the URLs are publicly accessible, post them here if you want someone to
have a specific look (or email me privately if you don't want them to be
public and I will try to have a look).

- Y


Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Dennis Putnam
On 10/22/2013 9:44 AM, Yehuda Katz wrote:
> On Tue, Oct 22, 2013 at 9:39 AM, Dennis Putnam  > wrote:
>
> Thanks. That might make more sense (at least to me). After more
> reading,
> I am not sure that I don't have SNI capable version of httpd already
> installed (how do I tell?). The pages that work are very simple
> but the
> one that doesn't is complex and has lots of graphics. If that is the
> case, why are they not encrypted like everything else (assuming
> they are
> not referenced on a different server)?
>
>
> As I mentioned, if you don't have SNI, then you should see major
> warnings from the browser that something is wrong when you go to any
> site but the first one.
>
> As far as finding the offending image: Go to the page in your browser,
> right click on the page and choose view source (or a similar option).
> Then search in the source for http://
> That should let you find which images are not secure.
> If the URLs are publicly accessible, post them here if you want
> someone to have a specific look (or email me privately if you don't
> want them to be public and I will try to have a look).
>
> - Y
>
Ah ha! You hit it. There are references to social media on the page that
use http (Facebook, LinkedIn and Twitter). Since they reference a
different site will just changing it to https be sufficient or is there
some other workaround? Thanks.


signature.asc
Description: OpenPGP digital signature


Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Yehuda Katz
If the sites you are referencing allow you to access them over https, that
will solve the problem.
My prefered solution is to omit the http: altogether. If a url just starts
with "//example.com/rest/of/url", the browser will use the appropriate
protocol automatically.

- Y


On Tue, Oct 22, 2013 at 9:59 AM, Dennis Putnam  wrote:

>  On 10/22/2013 9:44 AM, Yehuda Katz wrote:
>
> On Tue, Oct 22, 2013 at 9:39 AM, Dennis Putnam  wrote:
>
>> Thanks. That might make more sense (at least to me). After more reading,
>>  I am not sure that I don't have SNI capable version of httpd already
>> installed (how do I tell?). The pages that work are very simple but the
>> one that doesn't is complex and has lots of graphics. If that is the
>> case, why are they not encrypted like everything else (assuming they are
>> not referenced on a different server)?
>>
>
>  As I mentioned, if you don't have SNI, then you should see major
> warnings from the browser that something is wrong when you go to any site
> but the first one.
>
>  As far as finding the offending image: Go to the page in your browser,
> right click on the page and choose view source (or a similar option). Then
> search in the source for http://
> That should let you find which images are not secure.
> If the URLs are publicly accessible, post them here if you want someone to
> have a specific look (or email me privately if you don't want them to be
> public and I will try to have a look).
>
>  - Y
>
>   Ah ha! You hit it. There are references to social media on the page
> that use http (Facebook, LinkedIn and Twitter). Since they reference a
> different site will just changing it to https be sufficient or is there
> some other workaround? Thanks.
>


Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Chris Gordon
I think the previous poster, I shift deleted the mail but I think it is a 
prominent poster here 'Pete Houston' who had a very good point.  It could just 
be that you have mixed content.  You can use a development mode of a browser to 
find any links to http content, that will certainly break the prety green lock. 
 Maybe just view source and search for a link to something served vie http.
 
To answer your questions:
"Doesn't the SSLCertificate parameter for each VH say which cert to use? 


Yes, but how does Apache know which VH to get the cert from until it has used a 
cert to decrypt the SSL?  It just used the first cert in this case.  IP Bases 
will get you around this.  I said chicken - egg because Apache needs to read a 
header to know what VH to use but it can't read the header until it picks a 
vhost and uses the cert to decrypt the message.

 
Why does it work for 2 of the VH's but not the 3rd?"


I'm not sure, but like I mention above, it may be worth looking for non SSL 
content before going further down this rabbit hole.  Order of Vhouts could be 
one answer, but your public is 3rd.  If you used to have a wiild card cert as 
the first vhost and now its not a wald card host that could explain issues.  
Maybe the CN values in the first host covered the first 2 domains and not the 
third?  WAGing here, so I'll stop.  I'm not an expert, just offering help 
because I just setup a similar environment.

I hope I'm not taking you in the wrong direction with this.  It is worth 
understanding though.  I'm very sure I have a good deal to learn as well.

>>> Dennis Putnam  10/22/2013 9:20 AM >>>
On 10/22/2013 9:10 AM, Chris Gordon wrote:


Sorry, brevity is not my strong point.  
 
Because I do not know what your certs look like as far as what domain(s) are 
considered CNs I'm going to guess it has something to do with the following...
 
SSL wraps http and you need a cert to decrypt the data sent via SSL.  If you 
have 3 virtual hosts and you are using Name Based Virtual Hosting how does the 
Apache web server know which cert to use to decrypt and read the header so it 
can properly route the data.  The short answer per my understanding is that 
Apache has no clue and uses the default vhost's cert (the first one in the 
confi file) to read the SSL.  If these were all the same domain such as 
tuna.foo.com, seabass.foo.com and marlin.foo.com you could get away with using 
the same *.foo.com wildcard cert.   Here is a good doc with these work arounds: 
https://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf
 
I'm guessing your problem is somewhere in this domain.  I believe that Name 
Based Virtual Hosting is not the answer for you.  Try IP Based: 
http://httpd.apache.org/docs/2.2/vhosts/ip-based.html
 
or use a wildcard cert...  Here is a warning about your config and a better 
explanation I presume: 
http://wiki.apache.org/httpd/NameBasedSSLVHosts
 
I just ran into this.  Silly me for not realizing that a Web Server that routes 
bases on headers would need to read the encrypted header to route it.  
Chicken-Egg problem.
 
Chris --V


>>> Dennis Putnam  ( mailto:d...@bellsouth.net ) 10/22/2013 
>>> 8:26 AM >>>
I have 3 virtual hosts that for all I can see are configured identically
other the the obviously needed differences. The same is true of the 3
crt files.


ServerName public.mydomain.com
DocumentRoot /var/www/html
SSLEngine on
SSLCertificateFile /etc/httpd/SSL/public.crt
SSLCertificateKeyFile /etc/postfix/SSL/server.key


ServerName distrib.mydomain.com
DocumentRoot /var/www/html/distrib
SSLEngine on
SSLCertificateFile /etc/httpd/SSL/distrib.crt
SSLCertificateKeyFile /etc/postfix/SSL/server.key


ServerName mail.mydomain.com
DocumentRoot  /usr/local/squirrelmail/www
SSLEngine on
SSLCertificateFile /etc/httpd/SSL/mail.crt
SSLCertificateKeyFile /etc/postfix/SSL/server.key


The problem is that 2 of them work perfectly and the lock shows up in
the browser. With the third (public), I get a gray globe indicating
partial encryption which does not prevent eavesdropping. I have no clue
how to debug this or even where to look. Can someone point me in the
right direction? Thanks.




The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. 
Thanks for the reply. Now I'm confused. Doesn't the SSLCertificate parameter 
for each VH say which cert to use? Why does it work for 2 of the VH's but not 
the 3rd?

The informa

Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Yehuda Katz
On Tue, Oct 22, 2013 at 10:08 AM, Chris Gordon  wrote:

>  To answer your questions:
> *"Doesn't the SSLCertificate parameter for each VH say which cert to use*?
>
>
> Yes, but how does Apache know which VH to get the cert from until it has
> used a cert to decrypt the SSL?  It just used the first cert in this case.
> IP Bases will get you around this.  I said chicken - egg because Apache
> needs to read a header to know what VH to use but it can't read the header
> until it picks a vhost and uses the cert to decrypt the message.
>
> As I already pointed out, this is not correct. SNI 
> support has
been included in Apache for years as have most browsers (except Windows XP).

- Y


Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Dennis Putnam
On 10/22/2013 10:03 AM, Yehuda Katz wrote:
> If the sites you are referencing allow you to access them over https,
> that will solve the problem.
> My prefered solution is to omit the http: altogether. If a url just
> starts with "//example.com/rest/of/url
> ", the browser will use the
> appropriate protocol automatically.
>
> - Y
>
>
> On Tue, Oct 22, 2013 at 9:59 AM, Dennis Putnam  > wrote:
>
> On 10/22/2013 9:44 AM, Yehuda Katz wrote:
>> On Tue, Oct 22, 2013 at 9:39 AM, Dennis Putnam
>> mailto:d...@bellsouth.net>> wrote:
>>
>> Thanks. That might make more sense (at least to me). After
>> more reading,
>> I am not sure that I don't have SNI capable version of httpd
>> already
>> installed (how do I tell?). The pages that work are very
>> simple but the
>> one that doesn't is complex and has lots of graphics. If that
>> is the
>> case, why are they not encrypted like everything else
>> (assuming they are
>> not referenced on a different server)?
>>
>>
>> As I mentioned, if you don't have SNI, then you should see major
>> warnings from the browser that something is wrong when you go to
>> any site but the first one.
>>
>> As far as finding the offending image: Go to the page in your
>> browser, right click on the page and choose view source (or a
>> similar option). Then search in the source for http://
>> That should let you find which images are not secure.
>> If the URLs are publicly accessible, post them here if you want
>> someone to have a specific look (or email me privately if you
>> don't want them to be public and I will try to have a look).
>>
>> - Y
>>
> Ah ha! You hit it. There are references to social media on the
> page that use http (Facebook, LinkedIn and Twitter). Since they
> reference a different site will just changing it to https be
> sufficient or is there some other workaround? Thanks.
>
>
Thanks. I'll give that a try.


signature.asc
Description: OpenPGP digital signature


Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-22 Thread Chris Gordon
Thank you for the enlightenment Yehuda! 
 
I must not be meeting one of the SNI prerequisites (maybe LD_LIBRARY_PATH, 
maybe TLS Extensions) because I get a warning message on startup about using 
* and Name Based Hosting with SSL.  I have a secure workaround so as long 
as it works and security is not compromised I'm OK with the warning since it's 
only temporary for me.  
 
The // for finding appropriate protocol is also a great pointer.  I'm curious 
if that will work with a mod_rewrite rule and if placement in the conf file 
makes a difference, but a quick test will tell me.
 
--Chris

>>> Dennis Putnam  10/22/2013 10:37 AM >>>
On 10/22/2013 10:03 AM, Yehuda Katz wrote:


If the sites you are referencing allow you to access them over https, that will 
solve the problem. 
My prefered solution is to omit the http: altogether. If a url just starts with 
"//example.com/rest/of/url", the browser will use the appropriate protocol 
automatically.

- Y


On Tue, Oct 22, 2013 at 9:59 AM, Dennis Putnam  wrote:


On 10/22/2013 9:44 AM, Yehuda Katz wrote:


On Tue, Oct 22, 2013 at 9:39 AM, Dennis Putnam  wrote:


Thanks. That might make more sense (at least to me). After more reading,
I am not sure that I don't have SNI capable version of httpd already
installed (how do I tell?). The pages that work are very simple but the
one that doesn't is complex and has lots of graphics. If that is the
case, why are they not encrypted like everything else (assuming they are
not referenced on a different server)?


As I mentioned, if you don't have SNI, then you should see major warnings from 
the browser that something is wrong when you go to any site but the first one.

As far as finding the offending image: Go to the page in your browser, right 
click on the page and choose view source (or a similar option). Then search in 
the source for http://
That should let you find which images are not secure.
If the URLs are publicly accessible, post them here if you want someone to have 
a specific look (or email me privately if you don't want them to be public and 
I will try to have a look).

- Y


Ah ha! You hit it. There are references to social media on the page that use 
http (Facebook, LinkedIn and Twitter). Since they reference a different site 
will just changing it to https be sufficient or is there some other workaround? 
Thanks.


Thanks. I'll give that a try.

The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited.


RE: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-23 Thread Tushar Chavan

 
> Date: Tue, 22 Oct 2013 08:26:57 -0400
> From: d...@bellsouth.net
> To: users@httpd.apache.org
> Subject: [users@httpd] Virtual Hosts and SSL Puzzler
> 
> I have 3 virtual hosts that for all I can see are configured identically
> other the the obviously needed differences. The same is true of the 3
> crt files.
> 
> 
> ServerName public.mydomain.com
> DocumentRoot /var/www/html
> SSLEngine on
> SSLCertificateFile /etc/httpd/SSL/public.crt
> SSLCertificateKeyFile /etc/postfix/SSL/server.key
> 
> 
> ServerName distrib.mydomain.com
> DocumentRoot /var/www/html/distrib
> SSLEngine on
> SSLCertificateFile /etc/httpd/SSL/distrib.crt
> SSLCertificateKeyFile /etc/postfix/SSL/server.key
> 
> 
> ServerName mail.mydomain.com
> DocumentRoot  /usr/local/squirrelmail/www
> SSLEngine on
> SSLCertificateFile /etc/httpd/SSL/mail.crt
> SSLCertificateKeyFile /etc/postfix/SSL/server.key
> 
> 
> The problem is that 2 of them work perfectly and the lock shows up in
> the browser. With the third (public), I get a gray globe indicating
> partial encryption which does not prevent eavesdropping. I have no clue
> how to debug this or even where to look. Can someone point me in the
> right direction? Thanks.
> 
> 
> 
  

Re: [users@httpd] Virtual Hosts and SSL Puzzler

2013-10-23 Thread Matthew Bachmann
Use debug mode in your browser to verify that all of the contents of the
page are actually coming from that server.  I had a problem where
javascript was importing some public library, and it was fetching it via
plain http, so I got the grey globe for the whole page.


On Wed, Oct 23, 2013 at 11:00 AM, Tushar Chavan
wrote:

>
>
> > Date: Tue, 22 Oct 2013 08:26:57 -0400
> > From: d...@bellsouth.net
> > To: users@httpd.apache.org
> > Subject: [users@httpd] Virtual Hosts and SSL Puzzler
> >
> > I have 3 virtual hosts that for all I can see are configured identically
> > other the the obviously needed differences. The same is true of the 3
> > crt files.
> >
> > 
> > ServerName public.mydomain.com
> > DocumentRoot /var/www/html
> > SSLEngine on
> > SSLCertificateFile /etc/httpd/SSL/public.crt
> > SSLCertificateKeyFile /etc/postfix/SSL/server.key
> > 
> > 
> > ServerName distrib.mydomain.com
> > DocumentRoot /var/www/html/distrib
> > SSLEngine on
> > SSLCertificateFile /etc/httpd/SSL/distrib.crt
> > SSLCertificateKeyFile /etc/postfix/SSL/server.key
> > 
> > 
> > ServerName mail.mydomain.com
> > DocumentRoot /usr/local/squirrelmail/www
> > SSLEngine on
> > SSLCertificateFile /etc/httpd/SSL/mail.crt
> > SSLCertificateKeyFile /etc/postfix/SSL/server.key
> > 
> >
> > The problem is that 2 of them work perfectly and the lock shows up in
> > the browser. With the third (public), I get a gray globe indicating
> > partial encryption which does not prevent eavesdropping. I have no clue
> > how to debug this or even where to look. Can someone point me in the
> > right direction? Thanks.
> >
> >
> >
>