vCenter 6.7 Joining enhanced linked mode after cert replacement fails (Failed to validate sso.(log_info() takes 1 positional argument but 2 were given))

[buggyx]

I just deployed a new vCenter 6.7 server with embedded PSC. I'm planning on adding four other additional sites using enhanced linked mode. I'm also using a hybrid certificate replacement approach in order get rid of the certificate warnings. By that I mean I'm replacing the machine SSL certs with my internal enterprise CA and utilizing VMCA for the solution users certificates.  Here is what I have done:

1. Created a custom template on our internal CA for vSphere purposes.

2. Followed the process to replace the machine certificate on my first vCenter/PSC (vcenter-site1.domain.com)

3. Imported the Root and Intermediate Certs to complete the trust chain (We both have a root and issuing CA)

4. Verified that I am no longer getting invalid certificate warnings and that the site now shows green.

5. Integrated vCenter/PSC with AD and added groups to allow domain login.

With that, everything works as expected.

Now I'm trying to deploy another site (vcenter-site2.domain.com). I'm on stage 2, step 3 which is the SSO configuration. I'm asked to provide the existing PSC FQDN, the single sign-on domain, and password. When I hit next, I see the validation of the connection and it correctly identifies the that the vCenter server has an embedded PSC. I am then presented with the following error

I presume this has something to do with the certificate replacement but I'm not sure where to look next. I came across a KB 2121701 ,but I checked and the thumbprints match so everything looks OK so I'm not sure if that KB applies. The only thing that struck me as odd was the following output when running echo | openssl s_client -connect localhost:443

Certificate chain

0 s:/C=CA/ST=CA/L=SanJose/O=Company/OU=VMware Engineering/CN=vcenter-site1.com

   i:/DC=com/DC=company/CN=Company Issuing Certification Authority

1 s:/DC=com/DC=company/CN=Company Issuing Certification Authority

   i:/DC=com/DC=company/CN=Company Root Certification Authority

2 s:/DC=com/DC=company/CN=Company Root Certification Authority

   i:/DC=com/DC=company/CN=Company Root Certification Authority

That could be a red herring but I thought I would include it.

Does anyone have any idea what this error could mean?

[VSprague]

I'm having this same issue, have you found a solution yet?

[GilGuti]

Any update on this? We are also experiencing the same issue.

[GilGuti]

[dstamen]

Have you tried this with the latest update 6.7a?

[buggyx]

I opened a case with VMware. Its a known issue but they have not tried 6.7a to see if it fixes it. I'll be trying this shortly and will update.

Basically, update your current (first vCenter) to 6.7a and then try joining linked mode again using the updated iso.

[buggyx]

I tried the recommendation from VMware support which was to upgrade to 6.7a and then try again. I got the same error as before.

[GilGuti]

It does not work in 6.7a either.

[c0367813]

Try this:

Remove extra quotes on line 82 and 83 of /opt/vmware/share/htdocs/vami/backend/sso-cli.py

                     vami.log_info("Ignoring non-IP/DNS subjectAltName "
                                 "extension: '%s'", ext_str)

[NBoy66]

After proposed changes it gives other error:

Call to retrieve external node's type has failed. Check if connectivity and session are still present.

[RalphSchmidt]

same Problem here ...

[RalphSchmidt]

ok, after analyzing the code in sso_cli.py, I saw how the function vami.log_info() should be called

instead of removing the extra quotes on thte two lines 82 and 83, replace both lines by following line:

vami.log_info("Ignoring non-IP/DNS subjectAltName extension: %s" % (ext_str))

after doing so, I got a clear error message, complaining about a wrong hostname in the PSC certificate,

so i punched in the IP address of the PSC and voila, the joining process went on ...

[buggyx]

Looks like RalphShmidt has a workaround as well although I have not verified that method myself.

I was able to solve it in a slightly different way. Basically, remove the comma and replace it with % in that script.

1. SSH to the appliance and start the shell

2. Navigate to  /opt/vmware/share/htdocs/vami/backend and make a backup copy of sso-cli.py

3. Edit "sso-cli.py" and look for the following lines:

                    vami.log_info("Ignoring non-IP/DNS subjectAltName "

                                "extension: '%s'", ext_str)

4. Change to:

                    vami.log_info("Ignoring non-IP/DNS subjectAltName "

                                "extension: '%s'"%ext_str)

5. Save the file

6. Now try the operation again. It should now run through successfully

I should mention that if you have multiple vCenter servers you are setting up in enhanced linked mode, then you will need to do this on each consecutive vCenter server. You could just reference back to the "fixed" server, but will then have to fix the replication order afterward.

[RalphSchmidt]

buggyx,

thank you for your direction to the source of the problem.

I'm (sure, we all are) really thankful for your findings, but please analyze the code and find at least two other calls to the function vami.log_info().

You will find, that every other call except the erratic one is using a parameter set formed in one single line as follows:

vami.log_info("some text %s" % (<variable1>))

or

vami.log_info("some text %s:%s" % (<variable1>, <variable2>))

And yes, I definitely agree to your last vote to correct this on every involved vCSA, thank you for that intput.

Ralph

[rmac1813]

thanks buggyx, the extra % worked for me, on build VMware-VCSA-all-6.7.0-8217866

[NBoy66]

For me worked too! with build VMware-VCSA-all-6.7.0-8217866. One notice: even you used case letters in cert, and it shows it in vcsa, internal cert for psc is lower case(!) an it's case sensitive! So you should specify hostname of first VCSA (target sso) in lower case!

[Truckstop]

What file (if any) needs to be modified in Windows vCenter Server?  Or are windows users destined to see this failure until they decide to use the appliance?