And you can always use iptables to redirect from 580n to 590n ..

On 2/3/2013 11:42 PM, Cliff Pratt wrote:

There's a lot of conflicting information on this topic on the Internet. Most current VNC servers seem to listen on port 590n. I've seen it claimed that a) port 580n is not used and can be blocked, b) 580n is used for the Java VNC client, c) 580n is used for browser requests for VNC (probably via the Java VNC client, I'd guess).

I don't know when the change occurred and it may be that it happened when RH changed from one VNC brand to another.

Cheers,

Cliff _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 02/03/2013 04:53 PM, John R Pierce wrote:

On 2/3/2013 1:42 PM, Cliff Pratt wrote:

...

There's a lot of conflicting information on this topic on the Internet. Most current VNC servers seem to listen on port 590n. I've seen it claimed that a) port 580n is not used and can be blocked, b) 580n is used for the Java VNC client, c) 580n is used for browser requests for VNC (probably via the Java VNC client, I'd guess).

I don't know when the change occurred and it may be that it happened when RH changed from one VNC brand to another.

traditional Windows VNC always used 590x for client->server connections. 580x was used for 'browser' requests to serve up a java VNC client that would then use 590x, and some VNC's also use 580x for file transfers. there's also port 550x used by some configurations for a 'callback' sort of connection.

For years of using the vncserver on Centos and Fedora, a 'netstat -a|grep 5802' showed something was listening on that port and my vnc client both the old one and the current tiger one would connect to port 5802. It has been this way for quite a ways back and sometime in the last two years when I was not looking, so to speak, the server now comes up on 5902...

I have no plans to force it back to 580n, I can work with what it is. Just curious as to when and why.

I know about 550n, as I have used that on headless system installs with specialized boot CDs where I changed the necessary files (I have the notes around somewhere on doing this) so the CD would boot, then I could connect with VNC and do the install.

On Mon, Feb 4, 2013 at 5:02 AM, Harold Pritchett harold@uga.edu wrote:

I know that the upstream provider often provides services added to new releases as updates to the current release. My question is how can I get multiple secure web sites on a single IP address and port? Has the upstream provider added this function to the current server?

I've found this rather straightforward to do, as long as all sites are covered by the same certificate. Remember that the encrypted tunnel is negotiated and activated prior to the request being sent - so when the certificate and keys are being managed, the vhost is as yet unknown. Having all sites covered by one certificate makes that problem go away :-)

So my advice is to use a wildcard domain covering *.mycompany.com - but remember that mycompany.com does not match *.mycompany.com, so you'll need a redirect to www.mycompany.com....

BR Bent

PS Just realised that we did this on nginx not apache, but I really don't expect that to be a problem.

On 4 February 2013 14:20, Harold Pritchett harold@uga.edu wrote:

On 2/3/2013 11:47 PM, Bent Terp wrote:

...

So my advice is to use a wildcard domain covering *.mycompany.com - but

remember that mycompany.com does not match *.mycompany.com, so you'll need a redirect to

...

www.mycompany.com.... BR Bent PS Just realised that we did this on nginx

not apache, but I really don't expect that to be a problem. I should have mentioned that wild cards are not an option. I need to support multiple names with absolutely nothing in common. It's sorta like

www.mynethost.com www.gotch.net www.somewhere.else.org

you get the idea.

If you can use a single cert for these (ie owned by the same entity) you could in principle use SubjectAltNames in a single cert to cover these and use that same cert on each site - no wildcard is then required...

If you need to use different certs (ownership reasons and so on) then SNI will work on a single IP - but just be aware of the limitations (all the WinXP clients for example) ... especially if these are public sites.

2013/2/4 Eero Volotinen eero.volotinen@iki.fi:

2013/2/4 Harold Pritchett harold@uga.edu:

...

According to this post which is over 3 years old (http://tinyurl.com/69gr4ol), the apache httpd server now supports multiple ssl sites on the same server. This became effective with release 2.2.12. It also requires OpenSSL 0.9.8f or later.

Serving multiple ssl certificates requires SNI on server and also client support.

http://www.rackspace.com/knowledge_center/article/serving-secure-sites-with-...

this works on Centos 6 without messing up openssl libraries :)

-- Eero

Am 04.02.2013 um 05:02 schrieb Harold Pritchett harold@uga.edu:

According to this post which is over 3 years old (http://tinyurl.com/69gr4ol), the apache httpd server now supports multiple ssl sites on the same server. This became effective with release 2.2.12. It also requires OpenSSL 0.9.8f or later.

if you have multiple ips configured then this works out of the box in el5.

if you need sni support (one ip for multiple ssl sites) then el6 should provide the necessary support (openssl etc.).

-- LF