#1 2009-03-13 08:06:07

**_RobZ_**

Connect Pro and IP addresses

Hello everybody.

Connect Pro 7 + SP2 running on a Windows 2003 R2 server box.

After successfully securing the Meeting Server with SSL (ie, switching from port 1935 to 443 using a TRIAL certificate) I was wondering if it's possible to secure both the meeting server and the application server running on the very same HW box.

I mean, while performing the above mentioned settings, the App Server was configured to bind to port #80 whereas the Meeting Server got stuck to port #443; I've read some posts and docs which do indicate the use of different IP addresses for every secured (#443) services, even if they're running on the very same HW box.

This KB article seems to indicate the way to go

http://kb.adobe.com/selfservice/viewCon … &sliceId=2

but before trying I'd like to know your opinions/views about that.

A software I'm most familiar with (Sun's SSGD) does offer the ability to BIND over a single port (eg, #443) using a kind of reverse proxy which is able to tell the HTTP traffic vs the AIP (similar to RTMP) one and route it towards the appropriate server (which is bound on different ports to the localhost interface).

It seems Connect Pro 7 is able to do the same but the documentation is not very clear on that subject.

Thanks,
Rob

**_RobZ_**

Re: Connect Pro and IP addresses

Well, situation has changed a bit.

After following the advices given the Install Guide (as to secure BOTH the Meeting AND the application server - each bound to the very same IP address) I found out a rather strange issue (assuming you can call it issue :-)

I was able to connect to the CP7 server using a couple of *external* boxes (a WinXP and a Linux one) successfully over port 443; one acted as a meeting presenter and the other as an attendee.

By *external* I mean machines which are not the same box into which I installed the Connect Pro Server; as an example, if the CP7 server is a Win2003/192.168.0.1 box, I connected from a WinXP/192.168.0.2 and a Linux/192.168.0.3.

I was NOT able to get to the meeting room from the CP7 server itself: I mean, if I log into the Win2003 server which hosts the CP7 server, I'm able to (securely) connect to https://<server> to get access to the admin console but when it comes to starting a meeting, I'm not able to get to the room (I only got a small, white window in which you should usually see the meeting room depicted).

As an example, when I try to join as an attendee, the main browser window contains:

The meeting was opened in the Adobe (R)
Acrobat (R) Connect (TM) Add-in.

Open a new meeting room window
Check our troubleshooting page for further assistance.

As soon as the above get depicted, a smaller one (labelled "Adobe Acrobat Connect Pro") kicks in but then it stops there.

The same goes when I try to open the meeting as a presenter.

I've checked with netstat and it does not seem to be a connection issue (no SYN_SENT detected).

The strange thing (at least, for me) it's that everything seems to work fine if the very same Connect server is not used by an attendee/presenter.

Am I missing something or what?

Thanks again,
Rob

**_connectguy_**

Re: Connect Pro and IP addresses

Hi Robz,

The correct setup for securing Adobe Connect is to use two IP addreses and two fully qualified domain names. 

Each IP is bound within the adaptor.xml. 
One IP is the meeting Server, and the other is the WebApp. 

FMS is used to secure both.  Hence the KB you mentioned will not work. 

Your best bet is to follow this doc:

http://help.adobe.com/en_US/Connect/6.0 … on/ssl.pdf

There might be a new one for Connect 7 but the setup is identical.

Cheers,
Brad

**_RobZ_**

Re: Connect Pro and IP addresses

Hi Brad.

Thanks again for your help.

OK, having 2 IP addresses sounds reasonable now; however, it's strange that it seems to work even if both the Meeting Server and the App Server are bound to the same IP.

Cheers,
Rob

**_connectguy_**

Re: Connect Pro and IP addresses

Hi Robz,

There are actually several different methods that will work, but I gave you the offically supported method. 
Using  the doc I referenced, but using only 1 IP, will result in a certificate mismatch error.  You will be able to continue but you will get the error. 

Cheers,
Brad