Welcome to ISAserver.org

SSL-SSL Bridging cert. management.

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [ISA Server 2004 General ] >> Server Publishing >> SSL-SSL Bridging cert. management.

Page: [1]

Message

<< Older Topic Newer Topic >>

SSL-SSL Bridging cert. management. - 26.Jun.2005 3:04:00 AM

talkstocomputers

Posts: 2
Joined: 26.Jun.2005
From: Northwest
Status: offline

I have come across several references in MS and 3rd party documentation regarding exporting an internal web server certificate and then importing this certificate into the ISA server's cert store.

This technique would be useful if only the server's name is listed and not the FQDN of the server.

However if the FQDN is used in the certificate the INTERNAL FQDN would have to match External FQDN. This in normally considered a Non-optimum security issue.

Since SSL-SSL bridging (aka SSL termination) uses two seperate SSL sessions the certificate names do not need to match each other, they simple have to match the name used to establish each session.

For Web Publishing (Reverse Proxy) configurations that use SSL to SSL bridging it seems best to create a certificate that provides the External FQDN in the certificate. The request from the client machine to https://external.fq.dn will receive the correct server name thus identifying the server to the client.

The web publishing rule can then be created to use either the internal FQDN or the simple server name as the name of the target server based on internal certificate standards.

An alternative to using FQDN and unique IP addresses for SSL enabled hosts, is to create a "wildcard" SSL certificate that is relavant for *.external.dom. This allows you to use a 'wildcard" DNS entry to point all server lookups for a specific domain to a single or multiple IP addresses. You ISA server publishing rules then direct the incoming requests to the appropriate internal server based on the server name portion of the request.

the question of whether to forward the Host Header Field send by the external client is determined by whether the internal web server uses this information to modify non-relative (hardcoded server name) links while building the web response. If "All" links are relative to the current server then HHF is not needed. If the web server does not have a mechanishm to detect and replace hardcoded links, then it is irrelavant.

Post #: 1

Featured Links*

RE: SSL-SSL Bridging cert. management. - 26.Jun.2005 9:45:00 AM

tshinder

Posts: 47659
Joined: 10.Jan.2001
From: Texas
Status: offline

Hi Talk,

Its a misconception that a split DNS is a security issue, becuase it is unequivocally is NOT a security issue.

Check out:
http://isaserver.org/tutorials/2004illegaltldsplitdns.html

Pay close attention to the misconceptions and misunderstandings section.

HTH,
Tom

(in reply to talkstocomputers)

Post #: 2