Forum Discussion
veato
Nimbostratus
NimbostratusHorizon View "This Page is Not Secure"
I have a connection to my VDI desktops via F5 (build using the iApp) and it essentially works i.e. I can get a virtual desktop although with a slight issue.
To start with I enter the URL e.g. ht...
Amresh008Nimbostratus
NimbostratusMy understanding is that the ssl certificate that you have used for the VIP configuration for https, is not trusted by the OS on your desktop. It's a common behavior. When we try to access the GUI of the cisco tools, we get similar error. It's not browser specific but OS specific. There's no getting away, unless you get the SSL certificates configured from a renowned Certificate Authority, like Verisign, etc.
Hey Amy003
That would be the case if the user had told me that the main namespace was providing the certificate error.
---- Previous Comment ---
To start with I enter the URL e.g. https://myvdi.mydomain.com
Then after authenticating on the connection server and making my choice of desktop, the URL in the address bar changes to an IP in the range of the private LAN for the virtual desktops e.g.
https://10.180.0.80:22443/d/DE841123-FE72-4C6D-A9F3-2E6B7072D7E1/certAccept.html?numPages=3
This results in a typical "this site is not secure" page in IE which I have to manually press on "go on to the webpage."
----- Comment Ended ----
If this were the case we would see the error at myvdi.mydomain.com when the user tried accessing the site. The user also mentions they were able to authenticate and get to the desktop selection by this point the certificate being used to authenticate to the brokers is good meaning the LTM certificate is good.
Because the user is using HTML5 with Direct connect you can see the IP address 10.180.0.80:22443 which is a sign of the client directly connecting to the VDI desktop via the Blast protocol within HTML5. When using APM or a tunneled session you would never see the IP address of a VDI you would only see the tunneled fqdn address.
The blast protocol when installed on the VDI uses a untrusted self-signed certificate and this expected behavior of the blast protocol when using HTML5. The only way to stop this would be to replace that cert with a trusted certificate on each vdi desktop through scripting which would be difficult if using something like linked/instant clones as it would require a service restart as well which could trigger the recycle process.
Hope this explains why we are going down the path we are :)