Enterprise service FQDN response: Unable to get certificate from the URL:

[lmtan286]

I have two Connection Server  21.06 join domain lab.local with hostname:

 - conn01.lab.local

- conn02.lab.local

So, I use certificate *.lab.com for two connection server and change external url: conn01.lab.com, conn02.lab.com.

I deploy WS1 Access 21.08 with hostname ws1acc01.lab.com and WS1 Connection Server join domain lab.local with hostname: ws1conn01.lab.local

When I create new Virtual App Collection on WS1 show error Enterprise service ws1conn01.lab.local (EIS) response: Unable to get certificate from the URL: https://conn01.lab.local:443/SAML/metadata/sp.xml 

As error, WS1 connection server can't verify cert SSL from Connection Server because COnnection Server use cert *.lab.com, does not match with hostname conn01.lab.local of Horizon Connection server.

I think if Ws1 connection server use URL:  https://conn01.lab.com:443/SAML/metadata/sp.xml, its can connect to Connection Server.

How to change Ws1 connection server use https://conn01.lab.com:443/SAML/metadata/sp.xm replace https://conn01.lab.local:443/SAML/metadata/sp.xml 

Anyone have solution?

Thank you so much.

[vHojan]

I'm running into the exact same issue. Did you find any solution yet?

[Dizzion_Stewie]

I'm also seeing the same thing. Were you able to resolve?

[dvdende]

I'm also running into the same problem. What I have done so far to try and fix it.

Horizon connection servers:

vcon01.domain.local
vcon02.domain.local

I changed the vdm certificate from my domain.com to a newly create domain.local certificate which includes the following:

vcon01.domain.local
vcon02.domain.local
internalHorizonDomain.local
externalHorizonDomain.com

I placed my original externalHorizonDomain.com (say *.domain.com) on my KEMP loadbalancer instead of that it resolves at real server.
This way when someone comes through the loadbalancer it resolves using our external CA certificate and when you resolve the internal Horizon connection server name it also resolves correctly and is valid.

Seeing we keep our externalHorizonDomain.com address in both certificates we don't have to change anything in Horizon itself (HTTPS external URL).

Now I am not getting the "No subject alternative DNS name matching" anymore in C:\Program Files\Workspace ONE Access\Virtual App Service\logs\eis-service.log but this has now been changed to "Failed to get ssl certificate from https://vcon01.domain.local:443/SAML/metadata/sp.xml javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target".

It does not matter if I include the internal CA cerftificate or public CA certificates in the Workspace One Connector installer, whatever I try I'm still getting this error.

I even tried to include the Horizon Connection server viewsaml (signing and encryption) certificates but still no fix.

The only certificates I can think of are the SAML certificates from Workspace itself. Maybe we have to replace these for certificates with a valid CA?

For some reason I find this to be badly documented. Even the error does not state on which certificate it is giving the error. If we had that we could fix the issue. Now we are changing multiple certificates (connection server, loadbalancer, viewsaml, workspace one appliance and now maybe the SAML certificate from Workspace itself) and are just fiddling in the dark here.

Hope someone can shine a light to which certificate needs to be validated for this to work.

Thanks in advance

[kennyvz]

We had this issue and solved it by using keytool to manually import our Trusted Root certificate into C:\Program Files\Workspace ONE Access\Virtual App Service\conf\certs\cacerts. Once we restarted the VMware Virtual App Service app sync started working again. Not sure why installing the certificate with the Installer didn't succeed, but there was no evidence of our Trusted Root in cacerts until we manually imported it. Hope that helps someone.

[dvdende]

@kennyvz, did you import the local or public Trusted Root certificate?

[kennyvz]

Hi @dvdende, it was our main CA's Trusted Root public key. To confirm that's what we needed we browsed to the metadata URL:

https://<hostname>/SAML/metadata/sp.xml

and could confirm it was signed using our main CA, so that the certificate we manually imported and all was good.

Hope that helps.

[dvdende]

@kennyvz, finally got the chance to test this and it works!! Thanks for the help!

For people who have the same issue do this:

keytool -importcert -file locationCertFile -keystore "C:\Program Files\Workspace ONE Access\Virtual App Service\conf\certs\cacerts"

and when asked for the password use the value from the "C:\Program Files\Workspace ONE Access\Virtual App Service\conf\certs\cakeystore.pass" file

[kennyvz]

You're welcome @dvdende, great to hear it worked for you too 😀 Apologies for not making the process a little simpler by specifying the full keytool command and the location of the password, nice one for posting it now. All the best!

[TexasMan]

So I am having a weird issue where "C:\Program Files\Workspace ONE Access\Virtual App Service\conf\certs\cakeystore.pass" does not even exist.  Tried going through the install scripts to see what creates this but couldnt find anything

[dvdende]

@TexasMan, is it only the .pass file you are missing or is it also the cacerts file?

[TexasMan]

Both and actually didnt even have the certs folder

[TexasMan]

Support found a similar issue that you can't use certain symbols in the config file password.  The symbols that should not be used are @ & and $

[dvdende]

@TexasMan, what happends when you create the folder and .pass file yourself and then use the command from my previous post to create the cacerts file?

[JEHolo3]

Thanks - that fixed also my issue.

One extra related info :

I did first get the following error message while running the command :
keytool error: java.lang.Exception: Input not an X.509 certificate

This was fixed by opening the (Base64?) CRT-cert in Windows and select “Copy to file”
I there selected the “DER encoded binary X.509 (.CER)” format option.

This time did the command work.

I think this solution might as well work for PEM and CER files if they are  Base64 files.

[JohnTwilley]

Thanks everyone for providing better support then VMware Support Roller Coaster Ride these past few weeks.    We ran across this exact issue when trying to migrate from our 19.x connector.  VMware Support had us upload the cert by re-running the Installer. Their Installer method failed to fix the issue.  We always got those Sync failures. 

Using Keytool.exe and that "special password" got us up and running in a few minutes!   Now THAT is not in Carl's documentation!! (which is what VMware Support sent us to verify our setup!?!  Carl - Are you getting PAID for that?  LOL.

Thank You VMTN Community!

[dvdende]

You are most welcome, that's why we have a community 😄

[jn987]

Hi @dvdende , I am at a loss at this issue. The keytool command you shared, at "-file" for locationCertFile I need to fill in the certificate location/name, right?

As I have my own CA running, should I export the root certificate from the CA or something? I am really bad at this kind of stuff and have already tried multiple ways of importing certs but I keep getting the same error..

(this if for a lab environment by the way, for learning purposes, so if something breaks it's not a big issue)

[dvdende]

@jn987 , yes this is indeed the certificate file. But it's not your CA file it's a server certificate you want your server to be, e.g. server.contoso.com.