It's because Web Publishing is reverse-proxy. It terminates the inbound connection and creates a new one to the internal server. Since you're terminating the original SSL request, you need a valid certificate on the ISA server, or you have to server-publish the internal site. Personally, I prefer to server-publish SSL connections if the site is SSL-only (why would you mix them?). If the internal site disallows non-SSL connections, URL filtering can be performed with URLScan on the internal server.. Jim Harrison MCP(NT4, W2K), A+, Network+, PCG http://isaserver.org/pages/author_index.asp?aut=3 http://isatools.org Read the books! ----- Original Message ----- From: "Paul Nuernberger" <pen@xxxxxxxxx> To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx> Sent: Tuesday, September 03, 2002 8:16 AM Subject: [isalist] Confusion on SSL and ISA http://www.ISAserver.org OK, I am still a little confused regarding SSL and ISA. Am I correct in the understanding that to have SSL on a web server behind ISA you MUST either export the certificate to ISA or server publish the SSL port ?? This seems a bit daft as web publishing allows one to bridge the SSL request directly to the server. Is there something I've missed along the way. I have a customer that can connect to his SSL-enabled web server as long as it isn't behind ISA, but gets a blank page when attempts to connect through ISA are made (& obviously I have yet to either export or server publish SSL). Why would it be designed this way ?? What are the ramifications of each method (looking for response from those who are doing this in the field) ? I am leaning to server publishing the SSL port due to the software the customer is using (iCode). Any assistance, etc. greatly appreciated. Paul Nuernberger ------------------------------------------------------ You are currently subscribed to this ISAserver.org Discussion List as: jim@xxxxxxxxxxxx To unsubscribe send a blank email to $subst('Email.Unsub')