I assume that you have 2 Real World FQDN's that point to the same External IP address (ie owa.mydomain.com & nfuse.mydomain.com) and that you are using SSL for both sites...but you have problem with certificates...
Thank You very much, ljp. I would have phrased the question more intelligently if I had read through this site a little more. Microsoft should be paying You people money, because without the information on this site ISA server is worth only half. We've succeeded in publishing multiple sites distinguished only by the host header. It even works with SSL using the wildcard certificate. However, publishing the Cisco Secure Gateway results in the SSL error 4 described in the post http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=6;t=002427. The solution described by MarcusPA suggests that it should work if the ISA server passed it's internal IP to the CSG. As I understand, using Web publishing, this happens by design, as it shouls result in reverse proxying. Could this be a problem with non-http content? I thought ISA didn't care about the nature of the containded application protocol. Thanks for the help.
Is your ISA server behind a PIX (or other firewall)...?
Are you trying to Web Publish CSG...? If so you might need to do it another way. CSG is not actually a web site, it is only a service that listens on the port you specify (normally 443) with a certificate assigned to it (Important note: the certificate name has to match the FQDN that you specify in your Nfuse settings for CSG).
One way is to Server Publish CSG but you may need to change the port that it listens on to avoid contention with your SSL listener. This would also involve adding this port to your external firewall the same way you have done for port 443
If you Server Publish CSG then you might need to apply this MS Kb Article fix to enable ISA to send it's IP as the source address so CSG sends the reply back to ISA instead of trying to send direct to external client... (as per MarcusPA topic)
Side Note: In our environment we have 2 real world ip's published on the PIX for Citrix Nfuse and CSG, one is for the nfuse web publishing rule (via SSL) and the other is for the CSG service (both running on the ISA server itself which is in caching-only mode in a DMZ). Applied disablesocketpooling vbs scripts for Win2000 to get this to work.
I'm sorry, I intended to write Citrix Secure Gateway. What we're trying to do, basically, is trying to see if it's possible to run both CSG and OWA with SSL on one external IP, because our Internet Provider is low on public IPs. It all has to run on 443, because we want to be able to reach it from behind a firewall. After all, quite an ambitous configuration ;-). It appears that ISA Server, having unpacked the CSG request, isn't able to build a new SSL channel to the CSG server, whereas everything works fine with OWA. We have a working Split DNS configuration, so that shouldn't be the problem. Thanks for the help, although I don't know if this is feasible at all. I'm looking into ISA 2004 at the moment to see if there's maybe some new feature that could make this work.
Back to Citrix Secure Gateway, this is not actually a website, it is only a service that listens on 443 (or other port that you specify), so you will not be able to use web publishing in ISA to forward requests/traffic to the internal CSG box.
Options here are: (this only applies if your isa is behind another firewall, otherwise you might not be able to get CSG going)
1: to have 2 Real World IP's that NAT through the PIX to 2 DMZ IP's (actually 2 IP's on External Interface of your ISA box), one is used for a SSL Listener for your NFuse Web Publishing Rule, the other is used for the CSG service (which is installed on your ISA box itself), this is where you need to disable socketpooling.
Now, you said that you can only have one Real World IP which will make things a bit more difficult. This is where someone else might need to advise, but it could be an option for the PIX to examine the packets and forward them to either the 1st IP on ISA external interface or the 2nd IP on the ISA exteranl interface based on the header details in the packet, this may not be possible....