So, I have to use wildcard cert from external CA in my vCloud.
1) I have done wildcard certificate from godaddy and use it in my corp web portal.
2) I read the http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=102225... So I can use wildcard certificate?
3) If I can use it - what I wil have to do? The right path to export existing PFX with root/intermediate and import it into JCEKS keystore (comands, export options, etc)?
I hope for your help. Thx.
This isn't my area of expertise, but as it's been a few days and you haven't gotten an answer, I just want to make sure you've seen this KB: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1026309
This is just an educated guess, but to use a wildcard certificate, I believe you could start with step #3 of "Creating and importing signed SSL certificates".
One thing to add...the vCloud director console feature users VMware Remote Console Plug-in and that does not support the use of wildcard certs yet. I learned that the hardway after weeks of troubleshooting and VMware support calls.
Does VMRC plugin still not work with wildcard certificates? I am having problems with the console in my newly installed vCloud Director setup, but I don't know if this is the cause.
The console window opens, but then it just shows "Connecting..." forever.
IIRC, the issue with wildcard certs is that they don't work properly on ESX 4 and earlier. This issue is resolved in ESX 5 so if you're using ESX 5 in your vCloud environment, it should work.
You would need to take a look at the logs mentioned in http://blogs.vmware.com/vcloud/2011/02/index.html to see why the connection is failing.
Also, if your cell is behind a NAT or if you have multiple cells behind a load balancer, you'd need to set the vCloud public addresses properly.
Good to know. Someone told me it was an ESX issue and no remote consoles would work with wildcard certs prior to ESX 5, but I couldn't find anything referencing this. I did find the PR that stated it was an issue with vCD 1.0 and resolved in vCD 1.5. I'll try to get a KB published for this if one doesn't exist. Thanks for the info.
Thanks for your reply.
My problem is that the console just shows "connecting..." and it is never connected.
I checked the things on the page you linked to.
Netstat shows OK. I can telnet to port 443 on the vCenter from the vCD machine, but not 902 or 903. Actually, I cannot even telnet to 902 or 903 locally on the vCenter machine.
I checked the client log files, but I cannot see anything that points in any certain direction. There are a number of errors regarding missing ini files, but I think they could be ignored?
I have attached the log files. What I did to create these logs was to start the VM and open the console. I can start and stop the VM with the buttons in the console window, but the console is never connected.
We are using vCenter 5 with ESX 4.1 hosts, so it could be the cert. I also tried creating a self-signed cert for the console proxy (according to the installation guide), and then reconfigure vCD, but the result was the same.
It looks like the SSL part is OK:
An SSL error usually looks like this:
2012-05-12T06:36:51.023-07:00| mks_vmrc| vmClientCore::VMControl::Connect: hostname "cloud.vmware.local"
2012-05-12T06:36:51.023-07:00| mks_vmrc| Setting proxy environment variable: VMWARE_HTTPSPROXY=
2012-05-12T06:36:51.028-07:00| mks_vmrc| cui::vmrc::VMCnx::Connect: Connect to MOID "vm-291" on "cloud.vmware.local"
2012-05-12T06:36:51.029-07:00| mks_vmrc| Resolving IP address for hostname cloud.vmware.local
2012-05-12T06:36:51.031-07:00| mks_vmrc| Resolved to 192.168.1.150
2012-05-12T06:36:51.067-07:00| mks_vmrc| cui::CertificateCheck::CheckCert - SSL verification failure for "cloud.vmware.local" due to a host thumbprint mismatch.
2012-05-12T06:36:51.067-07:00| mks_vmrc| cui::vmrc::MessageMgr: "SSL verification failure for "cloud.vmware.local" due to a host thumbprint mismatch.
2012-05-12T06:36:51.067-07:00| mks_vmrc| "
2012-05-12T06:36:51.068-07:00| mks_vmrc| cui::vmrc::VMCnx::OnConnectAborted: Connect cancelled for MOID "vm-291" on "cloud.vmware.local"
2012-05-12T06:36:51.068-07:00| mks_vmrc| cui::vmrc::VMCnxMgr::EmitConnectionStateSignal: Emitting "disconnected" signal (requested) for MOID "vm-291" on "cloud.vmware.local" - reason 'An error occured that affected the security of the connection'
But maybe it's something else with the cert... not sure. For now I'd focus on the connectivity. 902/903 are on the hosts, not vCenter. Your cells need to be able to talk to your hosts over 903 for the remote console in 4.1 (in 5.x it's over 902) unless you're proxying over 902. With vCloud, your client talks to the cells over 443 for the console proxy. Can you provide the IP of your client, vCloud web interface and the ESX hosts? Is cloud-console.domain.tld / 188.8.131.52 something you typed in to hide your domain name / IP or is this what you're using in a lab? Are you able to telnet to cloud-console.domain.tld over 443 from your client?
I just thought it would be useful to say that you can use openssl to connect to websites to validate certificates. It can be really useful to help you isiloate any issues with the SSL handshake:
openssl s_client -connect wetsite.url.com:443
Yes, I removed the "real" IPs and domain names. I am able to telnet from my vCloud Director machine to the ESX hosts on port 902 (and 903). I am also able to connect to the console IP of the vCD machine on port 443 from the client (as indicated by the log).
I also disabled the firewalls on both the vCD machine and the ESX host, and opened the firewall completely between the networks, but that made no difference.
I also used openssl to verify the cert, and everything looks good as far as I can see.
Maybe I should create a support request with this.
Regarding Wildcard SSL certificates, I've always found this blog very handy.
Despite the title, it should work for 5.x as well.
Do you have a proxy? If so, try disabling it from Internet Options and see if the problem persists. You've probably already tried this, but if not, may try a different browser.
Based on those logs, it doesn't immediately look to me like an SSL issue. Did you find it worked prior to installing the certs and that was the only change you made before it stopped working?