Problem with self-signed certificates

[Aleksa2022]

Our organization uses self-signed certificates. I built with Horizon Client 8.2 and everything works fine - certificates are accepted and there are no problems. But as soon as I try to upgrade Horizon Client to versions 8.3+, the certificates stop working. A check showed that the system stubbornly does not want to trust self-signed certificates. My attempts to change configurations to make the system trust my certificates have failed. I have tried every option I could find on the internet. What can I change and how can I get the system to trust my self-signed certificates? Certificates added to trusted /ca-bundle/etc/ssl/certs/trusted In the current version, the build and rebuild, including updating system components, with the 8.2 client is successful.

[Doncuppjr]

They might have changed where they look for certs. Could be a configuration item. Check with vendor and report back.

Sent from Yahoo Mail for iPhone

On Monday, December 18, 2023, 10:26 PM, Alesandro @.***> wrote:

Our organization uses self-signed certificates. I built with Horizon Client 8.2 and everything works fine - certificates are accepted and there are no problems. But as soon as I try to upgrade Horizon Client to versions 8.3+, the certificates stop working. A check showed that the system stubbornly does not want to trust self-signed certificates. My attempts to change configurations to make the system trust my certificates have failed. I have tried every option I could find on the internet. What can I change and how can I get the system to trust my self-signed certificates? Certificates added to trusted /ca-bundle/etc/ssl/certs/trusted In the current version, the build and rebuild, including updating system components, with the 8.2 client is successful.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Aleksa2022]

I tried placing in different places and assigning different resolutions - 644, 700, 755. Nothing helped. In the Horizon Client logs: SetTunnelConnectionCertificateMode:669: tunnel connection certificate validation mode : 0. Server certificate validation for request 0x55912b2e9fd0 Read 7 certificates from the system store. You need to download the CRL from http://pki.domain/CertEnroll/uno.crl. Ignoring invalid cert due to insecure mode (Unable to verify certificate revocation status.) AuthInfoCallback:703: Authentication requested for type Windows_Password, peer certificate error code 4

I didn't see any other errors. What else can I do? I suspect that something may have broken when installing the client, but I can't find where and what broke.

[rohrbachger]

I remember you wrote about such an issue a while ago. We are using actual view client but we are using an official wild card certificate, working fine. I`m not sure if it an issue with thinstation or a general view issue with self signed certificates. Maybe you can test with the official ubuntu 22.04 and your self signed certificate. If that also does not work and you have official vmware license and support you can open a ticket there, maybe you get then a hint. Vmware support is not bad. I would think it also does not work with ubuntu and your self signed certificate, but this is just a guess. I guess your are not dealing with UAG and access over the internet, probably just internal?

[Aleksa2022]

Yes, I've written about this problem. We tried installing the client on Debian - everything installed and works fine. I can't understand what's going wrong with Thinstation - why there is such an issue with certificates. I've noticed many times that after installing vmview once and getting a certificate problem, if you install the same version "over the top" again, the certificate problem goes away. I did different things - I created my own cert package, which I included in the build config. I included the certificate in the ca-bundle. I can't get a stable version that would work with any client. Here, for example, is a fragment of log from the last build with vmview 8.7: vmware-view 10425| CdkAuthenticationTask_AuthenticateForTask: Got authentication method 'windows-password'. vmware-view 10425| Login as current user is not enabled. vmware-view 10425| Need to download CRL from http://pki.domain.loc/CertEnroll/uno(13).crl. vmware-view 10425| OnAuthenticationLoad:2406: Auth Type is (Windows_Password) vmware-view 10425| AuthInfoCallback:787: Authentication is requested for type Windows_Password, peer certificate error code 4 vmware-view 10425| OnConnected:3121: Server 'https://vdi.domain.loc:443/' connected. vmware-view 10425| OnConnected:3128: The effective url is https://vdi.domain.loc:443/. vmware-view 10425| OnConnected:3135: The guid of server is a706b0ff-15fc-435c-a8e3-11476c7b778a. vmware-view 10425| OnConnected:3148: Hide server info is false vmware-view 10425| ShouldCreateBrokerCacheDir:4852: Broker protocol major version: 15. vmware-view 10425| ShouldCreateBrokerCacheDir:4853: Client default protocol major version: 15. vmware-view 10425| TryToCreateBrokerCacheDir:4820: Create the cache dir for the broker 'vdi.domain.loc'. vmware-view 10425| CreateBrokerCacheDir:4895: Failed to create the cache dir for broker 'vdi.domain.loc'. vmware-view 10425| HandoffToWorkspaceOne:1663: (561763AED810) The server is not in Workspace ONE mode. vmware-view 10425| TaskCombiner: CdkGetConfigurationTask(DONE) removed, group task num:0, total task num:0. vmware-view 10425| TaskCombiner: SetResult for CdkGetConfigurationTask(DONE). vmware-view 10425| OnAuthenticationRequired:2261: Auth Type is (Windows_Password)

I've tried inserting certificates in different places, the error still appears. I even removed other certificates, leaving only my own - we have a closed infrastructure and it is not supposed to use connections with external certificate checks. If I build with parameter 3 certificate validation, then connections work, but certificates are not validated and https is not installed. If you build with parameter 2, https is not installed and connections do not work. I tried different versions: 8.3 - 8.8.1. Some earlier builds worked and certificates were fine, but those versions had problems on our thin clients - not everything was supported. Now a lot of thin clients have been updated, but again I'm stuck with certificates... I can't find what's in the way. The certificates themselves are in the assembly, in the /etc/pki/tls directory.... And the trusted ones are in /etc/pki/tls/certs/trusted. I suppose there is a simple solution, but I can't find it - I'm walking around in circles, poking my nose like a newborn kitten.

[Doncuppjr]

The clue is in the build.log. It wants a newer version of openssl. That's why it won't read your certs. On Thursday, December 28, 2023 at 02:51:59 AM MST, Alesandro @.***> wrote:

Yes, I've written about this problem. We tried installing the client on Debian - everything installed and works fine. I can't understand what's going wrong with Thinstation - why there is such an issue with certificates. I've noticed many times that after installing vmview once and getting a certificate problem, if you install the same version "over the top" again, the certificate problem goes away. I did different things - I created my own cert package, which I included in the build config. I included the certificate in the ca-bundle. I can't get a stable version that would work with any client. Here, for example, is a fragment of log from the last build with vmview 8.7: vmware-view 10425| CdkAuthenticationTask_AuthenticateForTask: Got authentication method 'windows-password'. vmware-view 10425| Login as current user is not enabled. vmware-view 10425| Need to download CRL from http://pki.domain.loc/CertEnroll/uno(13).crl. vmware-view 10425| OnAuthenticationLoad:2406: Auth Type is (Windows_Password) vmware-view 10425| AuthInfoCallback:787: Authentication is requested for type Windows_Password, peer certificate error code 4 vmware-view 10425| OnConnected:3121: Server 'https://vdi.domain.loc:443/' connected. vmware-view 10425| OnConnected:3128: The effective url is https://vdi.domain.loc:443/. vmware-view 10425| OnConnected:3135: The guid of server is a706b0ff-15fc-435c-a8e3-11476c7b778a. vmware-view 10425| OnConnected:3148: Hide server info is false vmware-view 10425| ShouldCreateBrokerCacheDir:4852: Broker protocol major version: 15. vmware-view 10425| ShouldCreateBrokerCacheDir:4853: Client default protocol major version: 15. vmware-view 10425| TryToCreateBrokerCacheDir:4820: Create the cache dir for the broker 'vdi.domain.loc'. vmware-view 10425| CreateBrokerCacheDir:4895: Failed to create the cache dir for broker 'vdi.domain.loc'. vmware-view 10425| HandoffToWorkspaceOne:1663: (561763AED810) The server is not in Workspace ONE mode. vmware-view 10425| TaskCombiner: CdkGetConfigurationTask(DONE) removed, group task num:0, total task num:0. vmware-view 10425| TaskCombiner: SetResult for CdkGetConfigurationTask(DONE). vmware-view 10425| OnAuthenticationRequired:2261: Auth Type is (Windows_Password)

I've tried inserting certificates in different places, the error still appears. I even removed other certificates, leaving only my own - we have a closed infrastructure and it is not supposed to use connections with external certificate checks. If I build with parameter 3 certificate validation, then connections work, but certificates are not validated and https is not installed. If you build with parameter 2, https is not installed and connections do not work. I tried different versions: 8.3 - 8.8.1. Some earlier builds worked and certificates were fine, but those versions had problems on our thin clients - not everything was supported. Now a lot of thin clients have been updated, but again I'm stuck with certificates... I can't find what's in the way. The certificates themselves are in the assembly, in the /etc/pki/tls directory.... And the trusted ones are in /etc/pki/tls/certs/trusted. I suppose there is a simple solution, but I can't find it - I'm walking around in circles, poking my nose like a newborn kitten.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[Doncuppjr]

It appears to actually ship with the new libs it wants, but can't find them. This could be fixed with LD_LIBRARY_PATH or by rpathing the files. LD_LIBRARY_PATH is a lazy option. On Thursday, December 28, 2023 at 06:47:55 AM MST, Don Cupp @.***> wrote:

The clue is in the build.log. It wants a newer version of openssl. That's why it won't read your certs. On Thursday, December 28, 2023 at 02:51:59 AM MST, Alesandro @.***> wrote:

Yes, I've written about this problem. We tried installing the client on Debian - everything installed and works fine. I can't understand what's going wrong with Thinstation - why there is such an issue with certificates. I've noticed many times that after installing vmview once and getting a certificate problem, if you install the same version "over the top" again, the certificate problem goes away. I did different things - I created my own cert package, which I included in the build config. I included the certificate in the ca-bundle. I can't get a stable version that would work with any client. Here, for example, is a fragment of log from the last build with vmview 8.7: vmware-view 10425| CdkAuthenticationTask_AuthenticateForTask: Got authentication method 'windows-password'. vmware-view 10425| Login as current user is not enabled. vmware-view 10425| Need to download CRL from http://pki.domain.loc/CertEnroll/uno(13).crl. vmware-view 10425| OnAuthenticationLoad:2406: Auth Type is (Windows_Password) vmware-view 10425| AuthInfoCallback:787: Authentication is requested for type Windows_Password, peer certificate error code 4 vmware-view 10425| OnConnected:3121: Server 'https://vdi.domain.loc:443/' connected. vmware-view 10425| OnConnected:3128: The effective url is https://vdi.domain.loc:443/. vmware-view 10425| OnConnected:3135: The guid of server is a706b0ff-15fc-435c-a8e3-11476c7b778a. vmware-view 10425| OnConnected:3148: Hide server info is false vmware-view 10425| ShouldCreateBrokerCacheDir:4852: Broker protocol major version: 15. vmware-view 10425| ShouldCreateBrokerCacheDir:4853: Client default protocol major version: 15. vmware-view 10425| TryToCreateBrokerCacheDir:4820: Create the cache dir for the broker 'vdi.domain.loc'. vmware-view 10425| CreateBrokerCacheDir:4895: Failed to create the cache dir for broker 'vdi.domain.loc'. vmware-view 10425| HandoffToWorkspaceOne:1663: (561763AED810) The server is not in Workspace ONE mode. vmware-view 10425| TaskCombiner: CdkGetConfigurationTask(DONE) removed, group task num:0, total task num:0. vmware-view 10425| TaskCombiner: SetResult for CdkGetConfigurationTask(DONE). vmware-view 10425| OnAuthenticationRequired:2261: Auth Type is (Windows_Password)

I've tried inserting certificates in different places, the error still appears. I even removed other certificates, leaving only my own - we have a closed infrastructure and it is not supposed to use connections with external certificate checks. If I build with parameter 3 certificate validation, then connections work, but certificates are not validated and https is not installed. If you build with parameter 2, https is not installed and connections do not work. I tried different versions: 8.3 - 8.8.1. Some earlier builds worked and certificates were fine, but those versions had problems on our thin clients - not everything was supported. Now a lot of thin clients have been updated, but again I'm stuck with certificates... I can't find what's in the way. The certificates themselves are in the assembly, in the /etc/pki/tls directory.... And the trusted ones are in /etc/pki/tls/certs/trusted. I suppose there is a simple solution, but I can't find it - I'm walking around in circles, poking my nose like a newborn kitten.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[Doncuppjr]

try the latest commit and see if that works. On Thursday, December 28, 2023 at 07:09:37 AM MST, Don Cupp @.***> wrote:

It appears to actually ship with the new libs it wants, but can't find them. This could be fixed with LD_LIBRARY_PATH or by rpathing the files. LD_LIBRARY_PATH is a lazy option. On Thursday, December 28, 2023 at 06:47:55 AM MST, Don Cupp @.***> wrote:

The clue is in the build.log. It wants a newer version of openssl. That's why it won't read your certs. On Thursday, December 28, 2023 at 02:51:59 AM MST, Alesandro @.***> wrote:

Yes, I've written about this problem. We tried installing the client on Debian - everything installed and works fine. I can't understand what's going wrong with Thinstation - why there is such an issue with certificates. I've noticed many times that after installing vmview once and getting a certificate problem, if you install the same version "over the top" again, the certificate problem goes away. I did different things - I created my own cert package, which I included in the build config. I included the certificate in the ca-bundle. I can't get a stable version that would work with any client. Here, for example, is a fragment of log from the last build with vmview 8.7: vmware-view 10425| CdkAuthenticationTask_AuthenticateForTask: Got authentication method 'windows-password'. vmware-view 10425| Login as current user is not enabled. vmware-view 10425| Need to download CRL from http://pki.domain.loc/CertEnroll/uno(13).crl. vmware-view 10425| OnAuthenticationLoad:2406: Auth Type is (Windows_Password) vmware-view 10425| AuthInfoCallback:787: Authentication is requested for type Windows_Password, peer certificate error code 4 vmware-view 10425| OnConnected:3121: Server 'https://vdi.domain.loc:443/' connected. vmware-view 10425| OnConnected:3128: The effective url is https://vdi.domain.loc:443/. vmware-view 10425| OnConnected:3135: The guid of server is a706b0ff-15fc-435c-a8e3-11476c7b778a. vmware-view 10425| OnConnected:3148: Hide server info is false vmware-view 10425| ShouldCreateBrokerCacheDir:4852: Broker protocol major version: 15. vmware-view 10425| ShouldCreateBrokerCacheDir:4853: Client default protocol major version: 15. vmware-view 10425| TryToCreateBrokerCacheDir:4820: Create the cache dir for the broker 'vdi.domain.loc'. vmware-view 10425| CreateBrokerCacheDir:4895: Failed to create the cache dir for broker 'vdi.domain.loc'. vmware-view 10425| HandoffToWorkspaceOne:1663: (561763AED810) The server is not in Workspace ONE mode. vmware-view 10425| TaskCombiner: CdkGetConfigurationTask(DONE) removed, group task num:0, total task num:0. vmware-view 10425| TaskCombiner: SetResult for CdkGetConfigurationTask(DONE). vmware-view 10425| OnAuthenticationRequired:2261: Auth Type is (Windows_Password)

I've tried inserting certificates in different places, the error still appears. I even removed other certificates, leaving only my own - we have a closed infrastructure and it is not supposed to use connections with external certificate checks. If I build with parameter 3 certificate validation, then connections work, but certificates are not validated and https is not installed. If you build with parameter 2, https is not installed and connections do not work. I tried different versions: 8.3 - 8.8.1. Some earlier builds worked and certificates were fine, but those versions had problems on our thin clients - not everything was supported. Now a lot of thin clients have been updated, but again I'm stuck with certificates... I can't find what's in the way. The certificates themselves are in the assembly, in the /etc/pki/tls directory.... And the trusted ones are in /etc/pki/tls/certs/trusted. I suppose there is a simple solution, but I can't find it - I'm walking around in circles, poking my nose like a newborn kitten.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[Aleksa2022]

try the latest commit and see if that works.

Thanks for the tip. I'll definitely give it a try. I also already had a hunch that the problem had something to do with openssl and was planning to upgrade it. I plan to try to upgrade to 1.1.1w first, then to 3.2+.

[Aleksa2022]

Changed the installation script on a working system where the 8.2 client was already up and running. After changing the script, installed client 8.7. The package installed faster - before it could freeze for a long time and not install at all. Now it is installed, but certificates do not work. Here is the log (vmware-horizon-client):

vmware-view 10424| Log for pid=10424 version=8.7.0-20616018 vmware-view 10424| Could not open module directory /usr/lib/vmware/view/pkcs11: Error opening directory “/usr/lib/vmware/view/pkcs11”: No such file or directory vmware-view 10424| view.sslCipherString shouldn't be an empty string, using the default value: "!aNULL:kECDH+AESGCM:ECDH+AESGCM:RSA+AESGCM:kECDH+AES:ECDH+AES:RSA+AES" vmware-view 10424| Init:112: Client is initializing... vmware-view 10424| Init:169: gtkmm is already initialized. vmware-view 10424| InitLocalization:132: Skip localization initialization due to no valid localized message domain or path set. vmware-view 10424| Init:186: Disable RDP due to rdp client unavailable. vmware-view 10424| Init:214: View client is running in non-FIPS mode. vmware-view 10424| CdkUtil_SetIpProtocolUsage: setting dual as the addressing mode. vmware-view 10424| CdkUtil_SetIpProtocolUsage: forcing to IPv4-Only mode as ipv6 stack is unavailable. vmware-view 10424| Built using OpenSSL 1.0.2zf-fips 21 Jun 2022 vmware-view 10424| Using libcurl/7.84.0 OpenSSL/1.0.2zf-fips zlib/1.2.12 vmware-view 10424| SSL settings from Client: TLSv1Disabled = 1, TLSv1_1Disabled = 0, TLSv1_2Disabled = 0, Cipher String = !aNULL:kECDH+AESGCM:ECDH+AESGCM:RSA+AESGCM:kECDH+AES:ECDH+AES:RSA+AES, Signature Algorithms = , Support Groups = vmware-view 10424| CdkKillSwitch_SetBENITServerConnectionMode: BENIT server connection mode setting: vmware-view 10424| CdkKillSwitch_SetBENITServerConnectionCounts: BENIT server connection mode counts: TCP 1, UDP 0 vmware-view 10424| Failed to open file “/etc/vmware/udpProxy/config”: No such file or directory vmware-view 10424| UDPProxy_Initialize: UDP proxy listening on local port 41089... vmware-view 10424| CdkConnection_SetLoopbackPort: loopback port: 41089. vmware-view 10424| access fail vmware-view 10424| Desktop env: 0, idle delay: 0 vmware-view 10424| Using glib version 2.66.2 vmware-view 10424| Using gtk+ version 3.24.29 vmware-view 10424| Using window manager IceWM 1.6.2 (linux-gnu/x86_64) vmware-view 10424| g_object_get: assertion 'G_IS_OBJECT (object)' failed vmware-view 10424| cdk_broker_view_clear: assertion 'CDK_IS_BROKER_VIEW(view)' failed vmware-view 10424| cdk_broker_view_add_item: assertion 'CDK_IS_BROKER_VIEW(view)' failed vmware-view 10424| g_object_set: assertion 'G_IS_OBJECT (object)' failed vmware-view 10424| cdk_broker_view_add_item: assertion 'CDK_IS_BROKER_VIEW(view)' failed vmware-view 10424| g_object_set: assertion 'G_IS_OBJECT (object)' failed vmware-view 10424| display server protocol: tty vmware-view 10424| Disconnect:1813: Disconnecting server https://vdi.domain:443/ vmware-view 10424| HandoffToWorkspaceOne:1616: (55B6110D7C10) The server is not in Workspace ONE mode. vmware-view 10424| CdkConnection_SetHostnameType: Connection hostname type: Unknown (0) vmware-view 10424| Icon cache root dir will be: /home/mon/.vmware/icon/. vmware-view 10424| CdkFs_CopyDirectoryInfo: directory /home/mon/.vmware/icon/ is empty. vmware-view 10424| CdkConnection_SetHostnameType: Connection hostname type: Unknown (0) vmware-view 10424| CdkConnection_SetUrlAndQueries: Connection url: https://vdi.domain:443/. vmware-view 10424| CdkConnection_SetHostnameType: Connection hostname type: Unknown (0) vmware-view 10424| CdkConnection_SetHostnameType: Connection hostname type: Name (1) vmware-view 10424| CdkConnection_SetEffectiveUrl: Connection protocol: https, host: vdi.domain, hostname type: Name, port: 443, path: /, secure: true. vmware-view 10424| CdkConnection_SetEffectiveUrl: Synthetic url: vdi.domain:443, interface: (null), scope: -1. vmware-view 10424| SetVerificationMode:85: SSL security mode: 3. vmware-view 10424| Built using OpenSSL 1.0.2zf-fips 21 Jun 2022 vmware-view 10424| Using libcurl/7.84.0 OpenSSL/1.0.2zf-fips zlib/1.2.12 vmware-view 10424| SetTunnelConnectionCertificateMode:669: tunnel connection certificate checking mode : 0. vmware-view 10424| TaskCombiner: CdkGetConfigurationTask(TODO) added, group task num:1, total task num:1. vmware-view 10424| TaskCombiner: CdkSetLocaleTask(TODO) added, group task num:2, total task num:2. vmware-view 10424| TaskCombiner: Group Tasks(2):CdkGetConfigurationTask(TODO),CdkSetLocaleTask(TODO), vmware-view 10424| CdkConnection_SetProxy: Proxy: (null), type: 0. vmware-view 10424| CdkConnection_CheckPeerReachabilityImpl: peer reachability check returns 1 with error 0. vmware-view 10424| udpProxyLib: socket 101 transition to state SYN_SENT, reason FECSocketDoConnect refCount 4

vmware-view 10424| CdkConnection_SetReachability: reachability: 1. vmware-view 10424| CdkConnection_SetUserMode: Connection user mode: Mixed-mode. vmware-view 10424| CdkConnection_SetPreferredAddress: Preferred server address: 10.200.5.45. vmware-view 10424| CdkConnection_SetAddressType: Connection address type: IPv4 (2) vmware-view 10424| udpProxyLib: socket 101 transition to state CLOSED, reason FECSocketDoClose refCount 6

vmware-view 10424| udpProxyLib: FECSocketDestroy: Destroying listen socket 101

vmware-view 10424| TaskCombiner: CreateRequest for CdkSetLocaleTask(REDY). vmware-view 10424| CdkUtil_SetLocalAddress: local ip address 10.200.33.90 is being picked. vmware-view 10424| Send request successful: 0x55b61116a840 vmware-view 10424| Verify server's certificate for Request 0x55b611188cb0 vmware-view 10424| Find rpc request 0x55b611188cb0 from list vmware-view 10424| Read 7 certificates from system store. vmware-view 10424| Need to download CRL from http://pki.domain/CertEnroll/uno(13).crl. vmware-view 10424| Ignoring invalid cert due to insecure mode (Unable to verify certificate revocation status.) vmware-view 10424| CdkRpc_HandleResponsesAsync: Handle Response with rpc request id: 1. vmware-view 10424| Got a response to request 1. vmware-view 10424| TaskCombiner: ParseResult for CdkSetLocaleTask(PEND). vmware-view 10424| TaskCombiner: CdkSetLocaleTask(DONE) removed, group task num:1, total task num:1. vmware-view 10424| TaskCombiner: SetResult for CdkSetLocaleTask(DONE). vmware-view 10424| CdkCryptoTask_GenerateCryptoKeys:604 Data protection context initialized successfully. vmware-view 10424| CdkCryptoTask_ParseKeyParametersNode:723 Key materials from server are all valid and final keys are generated. vmware-view 10424| Got Client Conf param name: enableCredentialCleanupForHTMLAccess vmware-view 10424| Got Client Conf param value: false vmware-view 10424| Got Client Conf param name: clientHideServerInformation vmware-view 10424| Got Client Conf param value: false vmware-view 10424| Got Client Conf param name: clientHideDomainList vmware-view 10424| Got Client Conf param value: false vmware-view 10424| Got Client Conf param name: alwaysSendRdsLicense vmware-view 10424| Got Client Conf param value: true vmware-view 10424| Got Client Conf param name: sendRdsLicense vmware-view 10424| Got Client Conf param value: true vmware-view 10424| Got Client Conf param name: smartCardHintPrompt vmware-view 10424| Got Client Conf param value: false vmware-view 10424| CdkAuthenticationTask_AuthenticateForTask: Got authentication method 'windows-password'. vmware-view 10424| Login as current user is not enabled. vmware-view 10424| Need to download CRL from http://pki.domain/CertEnroll/uno(13).crl. vmware-view 10424| OnAuthenticationLoad:2359: Auth Type is (Windows_Password) vmware-view 10424| AuthInfoCallback:703: Authentication is requested for type Windows_Password, peer certificate error code 4 vmware-view 10424| OnConnected:3060: Server 'https://vdi.domain:443/' connected. vmware-view 10424| OnConnected:3067: The effective url is https://vdi.domain:443/. vmware-view 10424| OnConnected:3074: The guid of server is a706b0ff-15fc-435c-a8e3-11476c7b778a. vmware-view 10424| OnConnected:3087: Hide server info is false vmware-view 10424| ShouldCreateBrokerCacheDir:4655: Broker protocol major version: 15. vmware-view 10424| ShouldCreateBrokerCacheDir:4656: Client default protocol major version: 15. vmware-view 10424| TryToCreateBrokerCacheDir:4623: Create the cache dir for the broker 'vdi.domain'. vmware-view 10424| CreateBrokerCacheDir:4698: Failed to create the cache dir for broker 'vdi.domain'. vmware-view 10424| HandoffToWorkspaceOne:1616: (55B6110D7C10) The server is not in Workspace ONE mode. vmware-view 10424| TaskCombiner: CdkGetConfigurationTask(DONE) removed, group task num:0, total task num:0. vmware-view 10424| TaskCombiner: SetResult for CdkGetConfigurationTask(DONE). vmware-view 10424| OnAuthenticationRequired:2214: Auth Type is (Windows_Password)

I have plans to upgrade openssl in the near future - I haven't done that yet. I hope it will help...

[Thinstation]

In the vmview folder of packages, try making this folder after install lib/vmware/view/pkcs11 If that doesn’t work, try linking that folder the one under /etc

Are you using fastboot?

On Thu, Jan 4, 2024 at 2:21 AM Alesandro @.***> wrote:

Changed the installation script on a working system where the 8.2 client was already up and running. After changing the script, installed client 8.7. The package installed faster - before it could freeze for a long time and not install at all. Now it is installed, but certificates do not work. Here is the log (vmware-horizon-client):

vmware-view 10424| Log for pid=10424 version=8.7.0-20616018 vmware-view 10424| Could not open module directory /usr/lib/vmware/view/pkcs11: Error opening directory “/usr/lib/vmware/view/pkcs11”: No such file or directory vmware-view 10424| view.sslCipherString shouldn't be an empty string, using the default value: "!aNULL:kECDH+AESGCM:ECDH+AESGCM:RSA+AESGCM:kECDH+AES:ECDH+AES:RSA+AES" vmware-view 10424| Init:112: Client is initializing... vmware-view 10424| Init:169: gtkmm is already initialized. vmware-view 10424| InitLocalization:132: Skip localization initialization due to no valid localized message domain or path set. vmware-view 10424| Init:186: Disable RDP due to rdp client unavailable. vmware-view 10424| Init:214: View client is running in non-FIPS mode. vmware-view 10424| CdkUtil_SetIpProtocolUsage: setting dual as the addressing mode. vmware-view 10424| CdkUtil_SetIpProtocolUsage: forcing to IPv4-Only mode as ipv6 stack is unavailable. vmware-view 10424| Built using OpenSSL 1.0.2zf-fips 21 Jun 2022 vmware-view 10424| Using libcurl/7.84.0 OpenSSL/1.0.2zf-fips zlib/1.2.12 vmware-view 10424| SSL settings from Client: TLSv1Disabled = 1, TLSv1_1Disabled = 0, TLSv1_2Disabled = 0, Cipher String = !aNULL:kECDH+AESGCM:ECDH+AESGCM:RSA+AESGCM:kECDH+AES:ECDH+AES:RSA+AES, Signature Algorithms = , Support Groups = vmware-view 10424| CdkKillSwitch_SetBENITServerConnectionMode: BENIT server connection mode setting: vmware-view 10424| CdkKillSwitch_SetBENITServerConnectionCounts: BENIT server connection mode counts: TCP 1, UDP 0 vmware-view 10424| Failed to open file “/etc/vmware/udpProxy/config”: No such file or directory vmware-view 10424| UDPProxy_Initialize: UDP proxy listening on local port 41089... vmware-view 10424| CdkConnection_SetLoopbackPort: loopback port: 41089. vmware-view 10424| access fail vmware-view 10424| Desktop env: 0, idle delay: 0 vmware-view 10424| Using glib version 2.66.2 vmware-view 10424| Using gtk+ version 3.24.29 vmware-view 10424| Using window manager IceWM 1.6.2 (linux-gnu/x86_64) vmware-view 10424| g_object_get: assertion 'G_IS_OBJECT (object)' failed vmware-view 10424| cdk_broker_view_clear: assertion 'CDK_IS_BROKER_VIEW(view)' failed vmware-view 10424| cdk_broker_view_add_item: assertion 'CDK_IS_BROKER_VIEW(view)' failed vmware-view 10424| g_object_set: assertion 'G_IS_OBJECT (object)' failed vmware-view 10424| cdk_broker_view_add_item: assertion 'CDK_IS_BROKER_VIEW(view)' failed vmware-view 10424| g_object_set: assertion 'G_IS_OBJECT (object)' failed vmware-view 10424| display server protocol: tty vmware-view 10424| Disconnect:1813: Disconnecting server https://vdi.domain:443/ vmware-view 10424| HandoffToWorkspaceOne:1616: (55B6110D7C10) The server is not in Workspace ONE mode. vmware-view 10424| CdkConnection_SetHostnameType: Connection hostname type: Unknown (0) vmware-view 10424| Icon cache root dir will be: /home/mon/.vmware/icon/. vmware-view 10424| CdkFs_CopyDirectoryInfo: directory /home/mon/.vmware/icon/ is empty. vmware-view 10424| CdkConnection_SetHostnameType: Connection hostname type: Unknown (0) vmware-view 10424| CdkConnection_SetUrlAndQueries: Connection url: https://vdi.domain:443/. vmware-view 10424| CdkConnection_SetHostnameType: Connection hostname type: Unknown (0) vmware-view 10424| CdkConnection_SetHostnameType: Connection hostname type: Name (1) vmware-view 10424| CdkConnection_SetEffectiveUrl: Connection protocol: https, host: vdi.domain, hostname type: Name, port: 443, path: /, secure: true. vmware-view 10424| CdkConnection_SetEffectiveUrl: Synthetic url: vdi.domain:443, interface: (null), scope: -1. vmware-view 10424| SetVerificationMode:85: SSL security mode: 3. vmware-view 10424| Built using OpenSSL 1.0.2zf-fips 21 Jun 2022 vmware-view 10424| Using libcurl/7.84.0 OpenSSL/1.0.2zf-fips zlib/1.2.12 vmware-view 10424| SetTunnelConnectionCertificateMode:669: tunnel connection certificate checking mode : 0. vmware-view 10424| TaskCombiner: CdkGetConfigurationTask(TODO) added, group task num:1, total task num:1. vmware-view 10424| TaskCombiner: CdkSetLocaleTask(TODO) added, group task num:2, total task num:2. vmware-view 10424| TaskCombiner: Group Tasks(2):CdkGetConfigurationTask(TODO),CdkSetLocaleTask(TODO), vmware-view 10424| CdkConnection_SetProxy: Proxy: (null), type: 0. vmware-view 10424| CdkConnection_CheckPeerReachabilityImpl: peer reachability check returns 1 with error 0. vmware-view 10424| udpProxyLib: socket 101 transition to state SYN_SENT, reason FECSocketDoConnect refCount 4

vmware-view 10424| CdkConnection_SetReachability: reachability: 1. vmware-view 10424| CdkConnection_SetUserMode: Connection user mode: Mixed-mode. vmware-view 10424| CdkConnection_SetPreferredAddress: Preferred server address: 10.200.5.45. vmware-view 10424| CdkConnection_SetAddressType: Connection address type: IPv4 (2) vmware-view 10424| udpProxyLib: socket 101 transition to state CLOSED, reason FECSocketDoClose refCount 6

vmware-view 10424| udpProxyLib: FECSocketDestroy: Destroying listen socket 101

vmware-view 10424| TaskCombiner: CreateRequest for CdkSetLocaleTask(REDY). vmware-view 10424| CdkUtil_SetLocalAddress: local ip address 10.200.33.90 is being picked. vmware-view 10424| Send request successful: 0x55b61116a840 vmware-view 10424| Verify server's certificate for Request 0x55b611188cb0 vmware-view 10424| Find rpc request 0x55b611188cb0 from list vmware-view 10424| Read 7 certificates from system store. vmware-view 10424| Need to download CRL from http://pki.domain/CertEnroll/uno(13).crl. vmware-view 10424| Ignoring invalid cert due to insecure mode (Unable to verify certificate revocation status.) vmware-view 10424| CdkRpc_HandleResponsesAsync: Handle Response with rpc request id: 1. vmware-view 10424| Got a response to request 1. vmware-view 10424| TaskCombiner: ParseResult for CdkSetLocaleTask(PEND). vmware-view 10424| TaskCombiner: CdkSetLocaleTask(DONE) removed, group task num:1, total task num:1. vmware-view 10424| TaskCombiner: SetResult for CdkSetLocaleTask(DONE). vmware-view 10424| CdkCryptoTask_GenerateCryptoKeys:604 Data protection context initialized successfully. vmware-view 10424| CdkCryptoTask_ParseKeyParametersNode:723 Key materials from server are all valid and final keys are generated. vmware-view 10424| Got Client Conf param name: enableCredentialCleanupForHTMLAccess vmware-view 10424| Got Client Conf param value: false vmware-view 10424| Got Client Conf param name: clientHideServerInformation vmware-view 10424| Got Client Conf param value: false vmware-view 10424| Got Client Conf param name: clientHideDomainList vmware-view 10424| Got Client Conf param value: false vmware-view 10424| Got Client Conf param name: alwaysSendRdsLicense vmware-view 10424| Got Client Conf param value: true vmware-view 10424| Got Client Conf param name: sendRdsLicense vmware-view 10424| Got Client Conf param value: true vmware-view 10424| Got Client Conf param name: smartCardHintPrompt vmware-view 10424| Got Client Conf param value: false vmware-view 10424| CdkAuthenticationTask_AuthenticateForTask: Got authentication method 'windows-password'. vmware-view 10424| Login as current user is not enabled. vmware-view 10424| Need to download CRL from http://pki.domain/CertEnroll/uno(13).crl. vmware-view 10424| OnAuthenticationLoad:2359: Auth Type is (Windows_Password) vmware-view 10424| AuthInfoCallback:703: Authentication is requested for type Windows_Password, peer certificate error code 4 vmware-view 10424| OnConnected:3060: Server 'https://vdi.domain:443/' connected. vmware-view 10424| OnConnected:3067: The effective url is https://vdi.domain:443/. vmware-view 10424| OnConnected:3074: The guid of server is a706b0ff-15fc-435c-a8e3-11476c7b778a. vmware-view 10424| OnConnected:3087: Hide server info is false vmware-view 10424| ShouldCreateBrokerCacheDir:4655: Broker protocol major version: 15. vmware-view 10424| ShouldCreateBrokerCacheDir:4656: Client default protocol major version: 15. vmware-view 10424| TryToCreateBrokerCacheDir:4623: Create the cache dir for the broker 'vdi.domain'. vmware-view 10424| CreateBrokerCacheDir:4698: Failed to create the cache dir for broker 'vdi.domain'. vmware-view 10424| HandoffToWorkspaceOne:1616: (55B6110D7C10) The server is not in Workspace ONE mode. vmware-view 10424| TaskCombiner: CdkGetConfigurationTask(DONE) removed, group task num:0, total task num:0. vmware-view 10424| TaskCombiner: SetResult for CdkGetConfigurationTask(DONE). vmware-view 10424| OnAuthenticationRequired:2214: Auth Type is (Windows_Password)

I have plans to upgrade openssl in the near future - I haven't done that yet. I hope it will help...

— Reply to this email directly, view it on GitHub https://github.com/Thinstation/thinstation/issues/798#issuecomment-1876762542, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVW47RSNS6UKBSKXCBCAO3YMZX73AVCNFSM6AAAAABA2S55L6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZWG43DENJUGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Aleksa2022]

Made a folder in lib/vmware/view/pkcs11, made a link to the /etc/pkcs11 folder - nothing helped. Even tried copying the /usr/lib/pksc11 folder to lib/vmware/view/pkcs11 - no help either. I didn't look at logs - just looked at the fact: it works or not and if not, changed something and started rebuild.

Yes, I am using fastboot.

[Aleksa2022]

Something went wrong with OpenSSL, too. I tried to upgrade to 1.1.1w - the build ended with an error. I tried to rebuild the package that is already in TS (1.1.1l) - the same error. =======> ERROR: Building '/ts/ports/core/openssl/openssl#1.1.1l-1.pkg.tar.xz' failed.

Removed the installation of patches - errors on individual patches - did not help. Somehow: Hunk #3 FAILED at 128. 1 out of 5 hunks FAILED -- saving rejects to file crypto/evp/digest.c.rej

For the sake of experiment, tried to put 3.2.0 - also an error when building. In general, it is preferable to switch to 3.2.0, since the branch 1.1.1 is no longer supported.

In general, there's an ambush here too, which requires thinking over the option of moving to github: https://github.com/openssl/openssl

[Aleksa2022]

I updated vmview (8.12), glibc (2.35), gcc (12.2). As before, vmview 8.2 saw certificates normally, 8.12 does not want to see them. In vmview 2 build mode, it frowns on certificates, but it connects to pools. I thought the problem was only in openssl - I tried to update to 3.1.5, 3.2.1 - the builds crashed. For example, after building and updating openssl port 3.0.13: libssl.so.1.1.1: cannot open shared object file: No such file or directory Failed to load module: /usr/lib/gio/modules/libgioopenssl.so Updated to 1.1.1w - the problem with certificates did not go away. The version request shows: OpenSSL 1.1.1.1l FIPS 24 Aug 2021 (Library: OpenSSL 1.1.1w 11 Sep 2023) Downloaded a new chain from CA, converted it, placed it in the same places as before - didn't help again. I placed it as specified in /ts/build/packages/base/etc/thinstation.env, gave the same file name. It didn't help either. What else can I do to make the certificates work properly?

[Doncuppjr]

I'll try and take a look this weekend. Once you start recompiling packages, it can be a rabbit hole. One package leads to another and so on..... On Friday, February 9, 2024 at 04:58:53 AM MST, Alesandro @.***> wrote:

I updated vmview (8.12), glibc (2.35), gcc (12.2). As before, vmview 8.2 saw certificates normally, 8.12 does not want to see them. In vmview 2 build mode, it frowns on certificates, but it connects to pools. I thought the problem was only in openssl - I tried to update to 3.1.5, 3.2.1 - the builds crashed. For example, after building and updating openssl port 3.0.13: libssl.so.1.1.1: cannot open shared object file: No such file or directory Failed to load module: /usr/lib/gio/modules/libgioopenssl.so Updated to 1.1.1w - the problem with certificates did not go away. The version request shows: OpenSSL 1.1.1.1l FIPS 24 Aug 2021 (Library: OpenSSL 1.1.1w 11 Sep 2023) Downloaded a new chain from CA, converted it, placed it in the same places as before - didn't help again. I placed it as specified in /ts/build/packages/base/etc/thinstation.env, gave the same file name. It didn't help either. What else can I do to make the certificates work properly?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[rohrbachger]

Aleksa2022, your are fighting already a long time with this issue. I tested to get the openssl 3.0.13 working, and yes it seems to work. But as Don wrote, we running in other issues..... I ignored all other issues, but VMware-Horizon-Client-2312-8.12.0-23149323.x64.bundle worked fine with our wildcard certificate. So I would have the hope, that your self signed certificate will work too.

I changed the port for openssl, Iḿ really not the expert for this. I removed all patches for the old version. Give this a try, I guess you are familiar with pkgmk. If not let me know. I will try to fix the other issues with the new openssl.

Attached the two files you need to place in .../ts/ports/core/openssl

Good luck, if the test is successful we can work at the other issues.

I made some improvements today....

In the fork rohrbachger you will find more actual files and the compiled package. Iḿ not using a developer machine, just a ubuntu desktop. clone the rep. you need to run setupchroot, it won`t work to just add the openssl 3.0.13. This make sure all packages will have he right new libs. Still I think thee are open issues with the new version, you test will maybe show.

ectest.c.txt Pkgfile.txt

[Aleksa2022]

Rohrbachger, that's how it worked for me, too. :-) Anyway, tried 3 options:

1. Rebuilt 3.0.13 again with the attached configs - nothing good came out. I got the same as before.
2. I downloaded your git and built with my own configs - I got errors.
3. To exclude various baseless attacks on my own configs, I decided to build with almost completely clean ones - I only changed the default ones a bit - disabled links for downloading updates and some packages (vbox, etc.) to keep them out of the way. There were some other bugs, but the openssl problem didn't change in any way - it sits there, native, as if it were installed. After building from almost clean git, the image didn't work - it said that xfwm4 package is not installed. I enabled it and got the error "/lib is not a mountpoint" at boot. In general, you still need to dig into your git.... Something is definitely missing or something else is wrong. In my build only certificates don't work (I remind you that everything worked with vmview 8.2, but when installing any version newer than that, certificates are no longer accepted). I've already tried everything I can think of. Checked the chain with openssl - validation passes. If you export your own SSL_CERT and SSL_DIR variables on the downloaded image and specify the location of certificates directly, they are picked up. If you don't specify them directly, they are not seen for some reason. I am attaching the protocol of unpacking and building the image with your Git for your review. By the way, the errors that appear at the end of the build, except for openssl, I've had before after updating some of the system packages - I didn't search much then - I got an error, rolled back and tried again. 2024-02-12_1_build_rohrbachger.zip

[rohrbachger]

Well, I`not really a git expert...

Can you test this: git clone --depth 1 https://github.com/Thinstation/thinstation.git rename the thinstation folder if you want. copy from my git only the files from /ts/ports/core/openssl, do not use the files I attached from the comment before.

run setup-chroot after that the first time.

I copy my build.conf, build.url at the right places.

This works for me, if you in the chroot with openssl version 3.0.13 is shown. Also if I run the build and boot the iso, I can see the version 3.0.13.

As Don wrote, Vmware delivers the openssl libs. That`s why it is working with our wildcard certificate. Probably with a local certificate check the TS standard openssl plays a role. With the version 3 there are a lots of changes, TLS changed HMAC changed. That´s probably why cour certificate check fails.

[Aleksa2022]

Yeah, that's where one of the problems lies. The official vmware documentation says that the client, during installation, downloads and installs the appropriate version of openssl. I have not found what this "appropriate version" is. I'll try your file to try it out. I also built 3.0.13 (I finished it) - there were problems with versions 3.1 and 3.2. I can't understand why openssl checks the certificate manually and everything is fine - testing is successful, but something doesn't see this chain in the right folders (folders and certificates are in the image, they are where they are expected to be). I can't figure out what else is missing. As for deploying from git, I've gotten the same trick when I update system components (e.g. coreutils and a few others - I can't remember them all at once) and minimize chroot (setup-chroot -c) and then try to deploy again. Some components were updated in the following way: first I built them all sequentially (pkgmk -d), then I updated them sequentially in the right order (pkgmk -u). In some cases this is crucial, otherwise the system or some components will break. By the way, now I tried to minimize TS - it crashed and did not minimize.

[rohrbachger]

You know, that under /lib/vmware/ some ssl libs are? On a quick check, seems to be different than the in TS /lib. Makes sense, during view setup they cant`t be downloaded from Internet in our case, but probably they are in the install package.

[Doncuppjr]

You could probably have both versions of openssl in the build environment. Maybe that will fix it. On Monday, February 12, 2024 at 04:41:14 AM MST, Alesandro @.***> wrote:

Yeah, that's where one of the problems lies. The official vmware documentation says that the client, during installation, downloads and installs the appropriate version of openssl. I have not found what this "appropriate version" is. I'll try your file to try it out. I also built 3.0.13 (I finished it) - there were problems with versions 3.1 and 3.2. I can't understand why openssl checks the certificate manually and everything is fine - testing is successful, but something doesn't see this chain in the right folders (folders and certificates are in the image, they are where they are expected to be). I can't figure out what else is missing. As for deploying from git, I've gotten the same trick when I update system components (e.g. coreutils and a few others - I can't remember them all at once) and minimize chroot (setup-chroot -c) and then try to deploy again. Some components were updated in the following way: first I built them all sequentially (pkgmk -d), then I updated them sequentially in the right order (pkgmk -u). In some cases this is crucial, otherwise the system or some components will break. By the way, now I tried to minimize TS - it crashed and did not minimize.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[Aleksa2022]

This is an interesting picture... I downloaded a fresh git, I suppose I might have gotten some error over time. In git I put only our configs for TS, with which everything was built normally before. I made a new certificate chain a bit earlier - I unloaded it from the certificate authority and converted it with openssl to the required format. The certificate chain has been tested on different machines with openssl - it passes validation. Previously, the file with the chain was called cert.pem and placed in /ts/build/packages/ca-bundle/etc/ssl Now the same file is again in the same place (I also put the chain with which previous builds with 8.2 worked). I created a /trusted folder in the /certs directory and put the chain there. I put the chain just in /certs - to other certificates. No result. When building with vmview in mode 2 (warn about invalid certificates, but allow connection), an interesting picture appears:

Disconnect:1434: Disconnecting server https://vdi.server.local:443/ HandoffToWorkspaceOne:1230: (55FFB84F2810) The server is not in Workspace ONE mode. CdkConnection_SetHostnameType: Connection hostname type: Unknown (0) Icon cache root dir will be: /home/mon/.vmware/icon/. CdkFs_CopyDirectoryInfo: directory /home/mon/.vmware/icon/ is empty. CdkConnection_SetHostnameType: Connection hostname type: Unknown (0) CdkConnection_SetUrlAndQueries: Connection url: https://vdi.server.local:443/. CdkConnection_SetHostnameType: Connection hostname type: Unknown (0) CdkConnection_SetHostnameType: Connection hostname type: Name (1) CdkConnection_SetEffectiveUrl: Connection protocol: https, host: vdi.server.local, hostname type: Name, port: 443, path: /, secure: true. CdkConnection_SetEffectiveUrl: Synthetic url: vdi.server.local:443, interface: (null), scope: -1. SetVerificationMode:89: SSL security mode: 2. SetTunnelConnectionCertificateMode:756: tunnel connection certificate checking mode : 0. CancelLaunch:436: (55FFB81303D0) Has no pending launching. TaskCombiner: CdkGetConfigurationTask(TODO) added, group task num:1, total task num:1. TaskCombiner: CdkSetLocaleTask(TODO) added, group task num:2, total task num:2. TaskCombiner: Group Tasks(2):CdkGetConfigurationTask(TODO),CdkSetLocaleTask(TODO), CdkConnection_SetProxy: Proxy: (null), type: 0. CdkConnection_SetPreferredAddress: Preferred server address: 10.200.5.43. CdkConnection_SetAddressType: Connection address type: IPv4 (2) TaskCombiner: CreateRequest for CdkSetLocaleTask(REDY). CdkUtil_SetLocalAddress: local ip address 10.200.33.90 is being picked. Send request successful: 0x55ffb8529830 Verify server's certificate for Request 0x55ffb852b1e0 Find rpc request 0x55ffb852b1e0 from list Read 165 certificates from system store. Potentially rejecting cert: The certificate authority is invalid or incorrect. (1) CdkRpc_HandleResponsesAsync: Handle Response with rpc request id: 1. Got a response to request 1. TaskCombiner: CdkGetConfigurationTask(FAIL) removed, group task num:1, total task num:1. ErrorCallback:950: The task 'CdkSetLocaleTask' failed with error: The certificate authority is invalid or incorrect. (domain=2267, code=1). OnError:70: Handling error 'The certificate authority is invalid or incorrect.' (domain=2267(CDK_SSL_ERROR), code=1) from task CdkSetLocaleTask. gtk_image_set_from_icon_name: assertion 'GTK_IS_IMAGE (image)' failed

Connection to pools doesn't work, although it should - it says that the certificate is invalid and offers to reconnect.

At the same time, when building in mode 3, the system shows that the certificates are incorrect, but the connections to the pools are established and everything works. Tried different placements but all to no avail. Since we are only interested in our certificates, I set the SSL_CERT_FILE environment variable to locate the cert.pem file - that didn't help either. I should note that the cert.pem file, for the sake of trying it out, I just put it in the folder with the rest of the certificates before building. Changed both variables like this: SSL_CERT_FILE=/etc/ssl/cert.pem SSL_DIR=/etc/ssl/ I changed both variables so that only our chain was there - also to no avail.

[Aleksa2022]

I, after downloading git, did not update openssl - only put vmview. I had previously installed vmview without smartcard support, but when it didn't work this time, I put it in to try it out. VMware wrote that they changed something in the installation scripts, plus something could be changed in the components - I decided to check if something missing would be installed and activated. It didn't help either. The system, after booting, can access our CA to load the necessary data - CRL, etc. Checking the certificate by specifying the modified environment variable SSL_CERT_FILE is successful. I haven't managed to find what else is in the way or doesn't work like that yet. So far I believe that it's a matter of some settings - unlikely in openssl components in vmview. But it's not certain...

[Aleksa2022]

I won the certificates! For those who encounter such a problem, I will describe what helped: I had a broker address in my config: vdi.server.local (buildtime). When I checked the certificate through this address with openssl, the check would sometimes stall for a few seconds - maybe that was one part of the problem. I set the address to: vdi,server.local:443 - so the validation started working faster. All the certificate chains - both the last and the previous one - I just put them in ca-bundle.crt. All the system variables that I had changed earlier were reset. I set the permissions on ca-bundle.crt and ca-certificates.crt as they were (they got messed up when merged with my files): root, 755. For some reason, sometimes the necessary variables were not picked up normally, so I created the files /vmview/etc/vmware/config and /vmview/etc/skel/.vmware/view-preferences In these files I listed the parameters I needed.

Now another problem has appeared: it doesn't work at all or works very badly on old hardware. Maybe it's the new kernel, or maybe it's just the old hardware. But this is another story...

[rohrbachger]

Congratulation,hat was a hard job. We are using old Optiplex 790 and Lenovo 710 with dual screen for office worker, they are still okay. Below i3 event if it is a old one, we sorted out.

[Aleksa2022]

Thank you! :-) We're mostly fine on machines older than 2012-2013, except for occasional issues with NVidia graphics cards. Ideally 2016+ - everything is fine with them in general. On machines older than that, problems. In vmware make constant changes in Blast and some processor instructions used by them are missing in older processors, so either vmview on such machines does not work at all, or slows down terribly and.... doesn't work either :-) I recently built a working image with vmview 8.12 on one such old geezer and it started to hesitate at the stage of loading the remote pool desktop. It hung like that for about 20 minutes until it got bored and I turned it off. Errors related to old processors were recorded in the logs: Disconnect : (55D0B92B4790) failed to setup the protocol connection

[Aleksa2022]

Donald, I also want to report some other oddities that may be able to be fixed in the future. I had a working build with vmview 8.2, I decided to just reinstall vmview to remove unnecessary components - smartcard support etc. After reinstalling, my certificates stopped working again :-)))) I didn't bother with it much, I decided to do a /setup-chroot -c rollup and deploy again - I was curious to see how the ports I had updated, which were already quite a few, would recover. The rollback was successful and everything deployed back without any errors, but.... certificates could not be seen again :-)))))) This is despite the fact that in buildtime SSLVERIFYMODE=2, and in the logs of the loaded client SSLVERIFYMODE=3. In my configs SSLVERIFYMODE=2 was set everywhere. In the end I solved it by specifying parameters in view-preference - then everything picked up normally. I just initially thought to do without it. It seems that SSLVERIFYMODE=3 is set by default somewhere, but then it is not picked up normally from buildtime. I haven't found how to fix it, but I haven't looked for it yet