Hi (sorry for the X-Post),

In a bit of a hole here.  I currently have a Load Balanced environment
(using an ancient LocalDirector 417) currenrly over 2 Web Servers.  Each
Web Server has its own SSL Certificate installed for secure.mysite.com
from Verisign using standard Port 443.  We are using a Checkpoint
Watchguard Firewall.

Currently Port 80 traffic is fine and if I browse to
http://secure.mysite.com it displays the screen I want to see but when I
try and resolve https://secure.mysite.com I immediately get a cannot
be loaded error and if I try and refresh that screen it just hangs and
displays nothing.

Now, I am sure that the Certs are all installed correctly so I am trying
to rule them out (in any case would a bad cert stop HTTPS working?)  We
have made changes to the Load Balancer recently for SSL Sticky Sessions
but I know that the LB is not the problem as when I bypass the LB the
error still happens, what it could be is the Firewall as we havent
totally ruled that out or tested it?

Anyone else seen issues like this before?

Windows 2000 Server
IIS 5.x
SSL (Verisign)
Port 443
Cisco LD-417
Checkpoint Watchguard Firewall/VPN

Thanks

Neil

[ Post a follow-up to this message ]

On Sat, 17 Apr 2004 10:48:11 +0100, Team Macromedia
<nospam@nospam.com> wrote:

>Hi (sorry for the X-Post),
>
>In a bit of a hole here.  I currently have a Load Balanced environment
>(using an ancient LocalDirector 417) currenrly over 2 Web Servers.  Each
>Web Server has its own SSL Certificate installed for secure.mysite.com
>from Verisign using standard Port 443.  We are using a Checkpoint
>Watchguard Firewall.
>
>Currently Port 80 traffic is fine and if I browse to
>http://secure.mysite.com it displays the screen I want to see but when I
>  try and resolve https://secure.mysite.com I immediately get a cannot
>be loaded error and if I try and refresh that screen it just hangs and
>displays nothing.
>
>Now, I am sure that the Certs are all installed correctly so I am trying
>to rule them out (in any case would a bad cert stop HTTPS working?)  We
>have made changes to the Load Balancer recently for SSL Sticky Sessions
>but I know that the LB is not the problem as when I bypass the LB the
>error still happens, what it could be is the Firewall as we havent
>totally ruled that out or tested it?
>
>Anyone else seen issues like this before?
>
>Windows 2000 Server
>IIS 5.x
>SSL (Verisign)
>Port 443
>Cisco LD-417
>Checkpoint Watchguard Firewall/VPN
>
>Thanks
>
>Neil

Neil,

I've implemented a very similar setup myself using a hardware
load-balancer and mutliple identical web servers all serving up SSL
content without problems.

I'd certainly suggest checking your firewall logs for any clues and
you might also want to take a look at this KB article :

HOW TO: Determine If SSL Connectivity Is Not Working on the Web Server
or on an Intermediate Device
http://support.microsoft.com/?id=290051


Regards,

Paul Lynch
MCSE

[ Post a follow-up to this message ]

I just read : http://support.microsoft.com/defaul...kb;EN-US;260096

and funnily enough this did happen, I did install by accident an SSL
cert on the Default Web Site and removed it and installed on the correct
Host Header (I am also reading about HTTP 1.1 Host Headers being an
issue - but that could be something else), I wonder if the fact that an
SSL was installed on the Default Web Site that the process of removing
it again needs to be performed?

TIA

Neil




Paul Lynch wrote:
> On Sat, 17 Apr 2004 10:48:11 +0100, Team Macromedia
> <nospam@nospam.com> wrote:
>
> 
> 
> 
>
>
> Neil,
>
> I've implemented a very similar setup myself using a hardware
> load-balancer and mutliple identical web servers all serving up SSL
> content without problems.
>
> I'd certainly suggest checking your firewall logs for any clues and
> you might also want to take a look at this KB article :
>
> HOW TO: Determine If SSL Connectivity Is Not Working on the Web Server
> or on an Intermediate Device
> http://support.microsoft.com/?id=290051
>
>
> Regards,
>
> Paul Lynch
> MCSE

[ Post a follow-up to this message ]

Hey Paul,

Yes I have a group of these articles open at present.  And these are the
problems I am having.  One thing which does confuse me is the part
which explains to use https://www.commonnameonthecertificate.com.   The
certs on the 2 web servers have registered common names as
secure.test.reedexpo.com so to test do I test with

https://www.secure.test.reedexpo.com.com or simply
https://secure.test.reedexpo.com

Is there a way to get the common name from the machine?  I assume that I
can just visit Verisign and get that info.

Do you think that the fact they have the same common name is a problem?
(I dont think it does - but you never know! )  All the other data such
as the Country and State are the same except department as it would not
allow us to create or request more than one certificate with the same
information so we had to modify the department to be slightly different
based on the machine request.

its a doozy alright...

N






Paul Lynch wrote:

> On Sat, 17 Apr 2004 10:48:11 +0100, Team Macromedia
> <nospam@nospam.com> wrote:
>
> 
> 
> 
>
>
> Neil,
>
> I've implemented a very similar setup myself using a hardware
> load-balancer and mutliple identical web servers all serving up SSL
> content without problems.
>
> I'd certainly suggest checking your firewall logs for any clues and
> you might also want to take a look at this KB article :
>
> HOW TO: Determine If SSL Connectivity Is Not Working on the Web Server
> or on an Intermediate Device
> http://support.microsoft.com/?id=290051
>
>
> Regards,
>
> Paul Lynch
> MCSE
Yes,

[ Post a follow-up to this message ]

In an effort to debug I have shutdown our second web server and our
initial web server is having the problems standalone. I did remove the
cert but when I go to enter re-assign it, when the Select a Certificate
dialog appears there are 2 in the box to
select....erm....wierd....anyone know why or how to clear this box out
so it only has one?

N





Team Macromedia wrote:

> Hey Paul,
>
> Yes I have a group of these articles open at present.  And these are the
>  problems I am having.  One thing which does confuse me is the part
> which explains to use https://www.commonnameonthecertificate.com.   The
> certs on the 2 web servers have registered common names as
> secure.test.reedexpo.com so to test do I test with
>
> https://www.secure.test.reedexpo.com.com or simply
> https://secure.test.reedexpo.com
>
> Is there a way to get the common name from the machine?  I assume that I
> can just visit Verisign and get that info.
>
> Do you think that the fact they have the same common name is a problem?
> (I dont think it does - but you never know! )  All the other data such
> as the Country and State are the same except department as it would not
> allow us to create or request more than one certificate with the same
> information so we had to modify the department to be slightly different
> based on the machine request.
>
> its a doozy alright...
>
> N
>
>
>
>
>
>
> Paul Lynch wrote:
> 
>
> Yes,

[ Post a follow-up to this message ]

On Sat, 17 Apr 2004 12:24:07 +0100, Team Macromedia
<nospam@nospam.com> wrote:

>I just read : http://support.microsoft.com/defaul....com/?id=187504


Regards,

Paul Lynch
MCSE

This could be the reason!!!!! though how  will the Web Server know what
site to serve up if I am not using Host Headers?



Paul Lynch wrote:

> On Sat, 17 Apr 2004 12:24:07 +0100, Team Macromedia
> <nospam@nospam.com> wrote:
>
> 
>
>
> Neil,
>
> Host headers will not work with SSL. For best results the SSL enabled
> web site on your server should have its own dedicated IP address.
>
> Refer to this KB article if you haven't found it already :
>
> HTTP 1.1 Host Headers Are Not Supported When You Use SSL
> http://support.microsoft.com/?id=187504
>
>
> Regards,
>
> Paul Lynch
> MCSE

[ Post a follow-up to this message ]

This does help - it helps a lot!  I am a tad annoyed with Verisign now
as I spend quite a long time on the phone with them explaining the
situation and they argued that we had to buy one cert for each server
(then of course they would), time to get on their case methinks.

Thanks Paul for taking time out at the weekend! I will look into these
on Monday.

Thanks, I will update the NNTP as soon as I get some results.





Paul Lynch wrote:

> On Sat, 17 Apr 2004 12:25:30 +0100, Team Macromedia
> <nospam@nospam.com> wrote:
>
> 
>
>
> The browser request has to match the registered common name exactly.
> To have more than one identity per web site requires the use of host
> headers and this will not work with SSL.
>
> By way of example, browse to this URL :
> https://online.lloydstsb.co.uk
>
> and now try browsing to to this one :
> https://www.online.lloydstsb.co.uk
>
> 
>
>
> The common name is the FQDN you entered when you made the request for
> the certificate - usually something like secure.domain.com - in the
> above example, check the certificate properties on the site, they
> match exactly the URL in the browser request. If you click on the
> Details tab and click on Subject you'll see that the CN= field also
> matches the URL exactly.
>
> 
>
>
> No, if I have understood you correctly (and I think I have) then you
> should have the same certificate on each server, so they would, by
> definition, have the same information. If the site is load balanced
> across two servers then the correct procedure is to install the
> certificate on one server and then export that certificate to the
> other servers in the cluster.
>
> Refer to this KB article for an explanation :
>
> HOW TO: Load Balance a Web Server Farm Using One SSL Certificate in
> IIS
> http://support.microsoft.com/?id=313299
>
> HTH !
>
>
> Regards,
>
> Paul Lynch
> MCSE

[ Post a follow-up to this message ]

I did find this technote but I have to say that SSL worked on another
server using Host Headers? or is it the case that the headers themselves
are not encrypted but the SSL traffic will still work.

N



Paul Lynch wrote:

> On Sat, 17 Apr 2004 12:24:07 +0100, Team Macromedia
> <nospam@nospam.com> wrote:
>
> 
>
>
> Neil,
>
> Host headers will not work with SSL. For best results the SSL enabled
> web site on your server should have its own dedicated IP address.
>
> Refer to this KB article if you haven't found it already :
>
> HTTP 1.1 Host Headers Are Not Supported When You Use SSL
> http://support.microsoft.com/?id=187504
>
>
> Regards,
>
> Paul Lynch
> MCSE

[ Post a follow-up to this message ]

On Sat, 17 Apr 2004 14:56:55 +0100, Team Macromedia
<nospam@nospam.com> wrote:

>I did find this technote but I have to say that SSL worked on another
>server using Host Headers? or is it the case that the headers themselves
>are not encrypted but the SSL traffic will still work.
>
>N

No it didn't Neil. SSL will not work with host headers.


Regards,

Paul Lynch
MCSE

[ Post a follow-up to this message ]