SSL port 443 for ITS and Certificates

[Former Member]

IIS and SSL question

I am setting up SSL for my ITS 6.20 Instances and using windows 2003 IIS 6. On my Wgate I have 3 ITS instances R3 uses port 91 crm uses port 92 and the admin uses port 93

http\server:91\scripts\wgate\webgui!

http\server:92\scripts\wgate\webgui!

http\server:93\scripts\wgate\admin!

I have 2 issues.

Within ISS I have given the hostheaders value as UATIST.domain.com

So if the users enters the following:-

http\UATIST.domain.com:91\scripts\webgui! Directs them to my R3 system

http\UATIST.domain.com:92\scripts\webgui! Directs them to my CRM system

http\UATIST.domain.com:93\scripts\admin! Directs met o my admin client

I am in the process of setting up SSL. I have generated the certificate for my instance for port 91, as my registered URL is going to be UATIST.domain.com I assume that I can use the same certificate on the other 2 instances. Am I correct in thinking this ? I am not sure if I have to generate 3 separate certificates.

My second query is that the default ssl port is 443. Do I have my 3 ports 91, 92 and 93 going all through port 443 or do I have to create separate SSL ports for each ITS instance.

To activate SSL I am assuming that once I have obtained the certificate within ISS I just use the web configuration tool as described in note 688295 and make the following entries: -

Goto 'Matching URLS' and look for button 'add' and press it.

You should see an additional line like:

http xxxx 9999 /scripts/wgate ADM yes no

change that line to

https default 443 /scripts/wgate ADM yes yes

I have the following

Protocol Domain Port Scriptpath Instance Available Require SSL add

any default 91 /scripts/wgate DRI0 yes no

any default 92 /scripts/wgate DCI0 yes no

any default 93 /scripts/wgate ADM yes no

If they all use port 443 how will the use be directed to the correct system.

Any help would be useful

Thanks

[Former Member]

Hi Fekke,

Apologies by brain was a little tired yesterday, the script path works. Which helps me with my solution, I am still awaiting for my certificate for my webserver which I assume I have to import it within all 3 web pages instances, however have 1 last question.

Within my Matching URL’s (in the Wgate config tool) I have the following :-

Protocol Domain Port Scriptpath Instance Available Require SSL add

any default 91 /scripts/wgate/RI0 DRI0 yes no del

any default 92 /scripts/wgate/CI0 DCI0 yes no del

any default 93 /scripts/wgate ADM yes no del

Once I obtain my certificate I assume that I have to do the following :

Protocol Domain Port Scriptpath Instance Available Require SSL add

https default 91 /scripts/wgate/RI0 DRI0 yes yes del

https default 92 /scripts/wgate/CI0 DCI0 yes yes del

https default 93 /scripts/wgate ADM yes no del

As there will be all using the default SSL port (443) for my users to access ITS will they have to change there url settings to :-

https\UATIST.domain.com:443\scripts\RI0\webgui! Directs them to my R3 system

https\UATIST.domain.com:443\scripts\CI0\webgui! Directs them to my CRM system

or can they use the same as before and just type

http\UATIST.domain.com:91\scripts\RI0\webgui! Directs them to my R3 system

http\UATIST.domain.com:92\scripts\CI0\webgui! Directs them to my CRM system

Thanks

[Former Member]

Hello Ajay,

it is one or the other:

• all users access one port (e.g. 443) which implicates one certificate for SSL and distinguish between R3-systems on "scriptpath"

• have access on different ports (91,92,..) which implicates SSL for all those ports and use the standard "scripts/wgate" path.

The second one is more difficult on both the client side (https with a non default port) and the server side (SLL for all those ports).

Just play with it now you know the basics of dispatching in the wgate, may be you manage to get https running for the outside and keep the internal access on http (for performance reasons)

Regards,

Fekke

[Former Member]

Fekke,

This does resolve the issue, but present me with another issue.

I have 2 wgates. 1 to handle internet requests which resides within the DMZ and the 2nd to recieve internal requests which resides in my internal network.

Within IIS I have set Host Header Value on the the Wgates as the same _ie ISTUAT.com Then created DNS settings for both.

My internet facing ITS instances are called BRI0 and BCI0 and internal instances are called DRI0 and CRI0. I am using the ITS as part of a portal solution.

Within the portal configuration I can only put in the server name, then for the script patch can only

input one path.

For example for R/3

server name : http//servername:port

Script patch: /scripts/wgate

Do you have any other suggestions.

Thanks

[Former Member]

Hello Ajay,

if I understand you well, then you have

• overloaded the internal wgate host DNS to point to an internal IP and the entry exists under the same name as an external entry

i.e.

my.hello.com >> external >> resolves to public IP

my.hello.com >> internal >> resolves to private IP

This to keep internal users at the internal wgate.

• somehow you can distinguish between the systems on host:port

• now you want to go public with SSL and do not want to have three non default https ports (say 491, 492, 493) since the external users might not have access other then 443

• there are two systems with ITS instances involved (let us skip the ADM since it probably will only be used internally) which have different ITS instance names external and internal.

The above implicates that you cannot distinguish on:

• port

• protocol

That leaves us with:

• (full)host

• scriptpath (as stated above)

Why not use the same DNS trick as you did for internal and external splitting and provide two DNS entries for the same machine.

• crm.hello.com

• r3.hello.com

And duplicate the entries internally to point to a local IP.

this results in: wgate external

• https r3.hello.com /scripts/wgate BRI0 yes no

• https crm.hello.com /scripts/wgate BCI0 yes no

and wgate internal:

• any r3.hello.com /scripts/wgate DRI0 yes no

• any crm.hello.com /scripts/wgate DCI0 yes no

And the according servername and scriptpath in the backend. (which also leads SLL internally)

I still do not see why you cannot use scriptpath, if you can split on hostname:port then why can't you do the same on scriptpath (don't they come in pairs?). May be there is a confusion about the instance names in the wgate configuration; it must be clear that they are only placeholders between the URL and the Instance in the wgate configuration (but kept inline with the Agate instances for readability)

e.g. wgate external

• https default /scripts/myr3 BRI0 yes no

• https default /scripts/mycrm BCI0 yes no

and wgate internal:

• any default /scripts/myr3 DRI0 yes no

• any default /scripts/mycrm DCI0 yes no

Regards,

Fekke

[Former Member]

Hello Ajay,

yes one certificate will do.

Can't you use the scriptpath to distinguish between different systems? (and run them all on 443)

e.g.

https default /scripts/drio DRI0 yes no

https default /scripts/dcio DCI0 yes no

https default /scripts/adm ADM yes no

and the users call the services like this:

• https\server\scripts\drio\webgui!

• https\server\scripts\dcio\webgui!

• https\server\scripts\adm\admin!

Regards,

Fekke