Cannot verify the identity of the server

[christhepocketg]

Hi,

Have a similar problem to one previously described on a customer site where  following the upgrade to View 5, we now get the cannot verify the  identity of the server message.

I can disable SSL via the "require SSL for client  connections and view administrator" restart the connection service and  the logon from the View client progresses without having to make changes  to allow SSL and ignore the state of the certificate.

HOWEVER I now get "The View connection server failed. A secure connection to the server '(NULL)' cannot be established"

I  will (once the users are off) try changing the external URL settings so  they no longer mention SSL explicitly., but I think this will break  access for the current clients

Currently the recommend approach is to correct the  client using Group Policy, however the clients that have this problem  are HP thin clients and do not log on to the domain, they just pitch up  on the LAN, get given an IP address and try to establish a session to  the connection server.

So my choices as I see it are to a) reconfigure the  thin clients so that they make SSL connections, but ignore the state of  the certificate, or

b) get a proper certificate for this internal server, and then  hope the clients believe it is legitimate without any further  intervention.

Now all of this only applies to View  Client 5.0, but we want to deploy this to get the 3d client support and  to get the best out of local mode.

Any ideas Community ?

thanks

Chris Millhouse

[christhepocketg]

so further clarification, as my last post is a little rambly

With a 4.6 client you put in the server name with the SSL box already checked and it connects - hurrah

Upgrade to 5.0 and the same scenario gives you the warning - boo

How to fix ?

1) Stay on 4.6 - great, but we want all the good 5.0 stuff !

2) Turn off the SSL requirements on the server - great, but I need to change the settings on all the existing 4.6 clients to not use SSL

3) Use Group Policies to configure the 5.0 clients to stop being so fussy about certificates - great but the clients are not on the domain

4) Visit the 5.0 clients to configure the options - great, but that means meeting people :smileycry:

5) Accept the exisiting Self Certified Certificate on the clients - more manual interaction with the client computers

5) Install a real SSL cert on the Connection server for 'internal' users - great but will exisiting 4.6 & 5.0 clients moan and need the certificate 'installing' manually.

Option 5 seems the most likely to work, but before we invest in a certificate, my boss wants to know if it will fix it, without us having to go visit all the client devices !

ta

Chris

[michelle79]

Hey Chris,

If they only access the view server internally then you could use an internal CA to generate the signed certificate which wouldn't cost anything... but yeah that means all the clients would need to have the trusted root CA certificate already in their cert store. There must be something like this for the current environment to use SSL though so hopefully it's doable.

Cheers,

Michelle

[christhepocketg]

Well, I have come across this

http://www.instantssl.com/ssl-certificate-products/ssl/ssl-certificate-intranetssl.html

which looks like it will tick most my boxes.

It looks like a 'proper' SSL cert

Its Key chain should already exist

Its free well cheap

My only question is what happens first time in, once the cert is installed. Does the user have to accept the certificate, or does it only moan when it is a 'bad' certificate ?

cheers

Chris

[michelle79]

It should work fine so long as the certificate is issued by a trusted certificate authority which means they will already be installed in the user's certificate store. The only thing you have to be careful with is the DNS name used to connect to the view server. If for example 1 uses the IP address, another uses the FQDN and another only uses the local name then they will be warned as the hostname on the certificate may not match. If you have this scenario you can get around this with a Subject Alternative Name certificate but they may cost more $ if you don't have an internal CA.

You should be able to get a trial certificate from them... they can set the expiry date to a month away or something like that.

[christhepocketg]

So we have gone for it - bought an Intranet SSL Cert for the connection server, and a regular SSL cer for the security server.

Once we have those installed I will report back.

I understand the caveat, with the address of the Internal server, currently users use a mix of servername.domain.local and servername to connect, but going forward they will need to use the FQDN.

For external connections they should always use externalservername.domain.com, so all should be good there !!

I understand the requirements for the certificate, but the change in behaviour between 4.6 and 5.0 has been a PITA, particularly as the internal clients are connecting from Thin Clients with no domain access, and consequently no use of GPO available. It would of been MUCH worse if we had been in production with this!

cheers

C