OpenSSL Error when trying to validate vCF 3.8?

[jlewis90]

I'm working on standing up vCF nested in a lab, and followed William Lam's guide to prepping the environment, I'm pretty sure everything is configured properly. While trying to validate the configuration file before bring up, I'm getting a nice generic OpenSSL error on several of the sections (vSAN Disk availability, ESXi version, ESXi host readiness, Time Synchronization, and Network validation): "ESXi Host <HOST IP> unable to connect: Unknown OpenSSL error. This error is commonly encountered when another library is not cleaning up the OpenSSL error stack. If you are using cryptography with another library that uses OpenSSL try disabling it before reporting a bug. Otherwise please file an issue at https://github.com/pyca/cryptography/issues with information on how to reproduce this. ([_OpenSSLErrorWithText(code=2147897744L, lib=128, func=101, reason=400, reason_text='error:80065190:lib(128):osrandom_rand_bytes:getrandom() initialization failed.')])."

I've validated that the Cloud Builder VM can communicate with the hosts, NTP is functioning, and DNS is resolving.

Everything should be self-signed certs, and I'm not seeing anything out there, so I'm not sure where to start looking. Does anyone have any ideas on where to start?

Thanks in advance for your time

[heathbarj3]

We have a tool for building a nested VCF lab, it is call the VCF Lab Constructor, VLC.   I'm assuming you have not heard of it. This is an PowerShell script that was developed by VMware Staff for installing VCF nested.

The links to download the tool and instructions can be found here. We also have a slack channel for supporting the install.

Please begin your journey with VLC by filling out the following form

http://tiny.cc/getVLC

If you need help with the VLC, the VCF Technical Marketing team will be over on the this Slack channel to assist you with answering any questions when deploying VCF into a nested Environment.

http://tiny.cc/getVLCSlack

Hope this helps

-Heath 

VCF Technical Marketing.

[jlewis90]

Thanks Heath, I'll review the documents and see what I find.

[barnette08]

I actually get this same error from Cloud Builder during validation prior to bringup in a physical environment as well.  Was there ever a root cause identified for this?

[barnette08]

Any ideas why this is showing up in 3.8, 3.81, and now 3.9?  I can't seem to get past validation and just have to assume my configuration is correct and acknowledge the validations that were skipped because of this OpenSSL error.

[stephensmith121]

. Thanks for this information. It is useful. Do you know that you can play mario games by downloading mario paint super nintendo file. Here's the guide mario games for downloading .

[storageguy33]

Did anyone get a root cause to this? I am hitting this on a physical deployment and it seems to be one issue after another with this deployment process. I could try to just ignore and continue on (which I will eventually do if I can't get past this) but it doesn't really lend itself to a validated configuration so I'd like to understand why the issue since I can get to the host with the passwords supplied and all the pre-reqs have been validated.

Thanks

[barnette08]

I ended up talking to engineering about it and it’s been reported as a bug from another customer.  I was never able to get a root cause, but I can confirm that my environment was configured correctly and after acknowledging the warning the bringup process completed without errors.

[storageguy33]

Thank you for the quick reply barnette08​

I need to tweak NTP and then I will perform the same continuation like you mentioned It is good to know that in your case it continued on just fine. Seems to be a few known weird issues like blank SDDC licenses and others during this deployment process. Thanks for the fast reply and confirmation. Hopefully they will add this to the release notes soon.

[HerpaMoTeH · Accepted solution]

This is happening because the python service that is doing the environment validations has started "a bit too early" so to say. More information for this can be found in https://stackoverflow.com/questions/48843728/intermittent-getrandom-initialization-failed-using-scra... .

Since the service was started a bit too early then you can try to restart it by running `systemctl restart sosrest` in the cloud builder VM. By this time the OS should've had enough time to collect some data in order to start generating random numbers.

If this doesn't help then you can try to install `rng-tools` on the cloud builder and restart it. This should definitely fix the issue as then Photon OS would use different algorithm and data source for generating random numbers with `/dev/random`