Tag Archives: ssl

VMware – vSphere Replication 5.8 and Custom Certificates

Posted on by

I waffled on some time ago about using proper certificates in your vSphere 5.5 environment. You can read about some of how to do that here. Eric has a nice summary of the steps here. I got a call recently from the customer about a few things and they mentioned some issues with vSphere Replication 5.8. Turns out I’d forgotten about vSphere Replication when I’d gone through the certificate replacement process, as it was done as a PoC. The fix is simple: power off the appliance and power it on again. VMware has a KB for most every situation, including this one – VMware vSphere Replication appliance no longer able to communicate with the VMware vCenter Server after changing the vCenter certificates (2063955). It also helps that I’m a bit late to this particular party.

The next step should be to replace the certificates on your vSphere Replication infrastructure as well. I was going to put together a post on that too, but it’s probably simplest if you read the VMware KB – Configuring CA Signed Certificates for VMware vSphere Replication (2080395). Friedrich also has a great post on some of the basics – including the certificate replacement process – here.

VMware – vSphere 5.5 U2 – Resetting the SSO Password

Posted on by

In a previous post I talked about deploying custom SSL certs into a vCenter 5.5 environment. As I was working through the update steps, the Certificate Automation Tool kept bombing out when updating the Inventory Service certificate. Neither the client nor I really knew why this was happening, but I had a bit of a hunch that it something to do with SSO credentials. It turned out to be a lucky guess, as I reset the password a few times and the SSL cert tool started working.

If you find yourself in this situation, there’s a tool provided with vCenter to reset the SSO password. Here’s a link to the KB article.

c:\Program Files\VMware\Infrastructure\VMware\CIS\vmdird>vdcadmintool.exe

It’s a fairly straightforward process, but you need to be mindful to use a generated password that meets VMware’s requirements for SSO passwords and special characters. By that I mean that some special characters aren’t allowed, even though they’re in passwords generated by the tool. You can get details on that here. In short, these special characters are not supported in SSO passwords:

  • Non-ASCII characters
  • Ampersand (&)
  • Semicolon ( ; )
  • Double quotation mark ( ” )
  • Single quotation mark ( ‘ )
  • Circumflex ( ^ )
  • Backslash ( \ )
  • Percentage (%)

At times I wasn’t convinced that this list is comprehensive either.

emc252623 – USM – ‘Accept Always’ button is greyed out

Posted on by

There is a problem with USM where you’ll get the error message: “Java certificate store is not present on client workstation. Certificates cannot be permanently accepted. The Certificate from this system in not trusted. Click accept to continue.” As a result of this the “Accept Always” button for Certificate acceptance is greyed out. Only the “Accept for Session” button is available for selection. The cause, as EMC point out, is that the Java certificate store trusted.jssecerts file is missing on the workstation.

I had this problem with USM version V1.0.0.1.0490 so I upgraded to V1.0.5.1.0052, thinking that an upgrade would resolve the issue. No dice. So I used the second method discussed in emc252623 to accept the certificates to my machine. However, when I checked in C:\Documents and Settings\username\Application Data\Sun\Java\Deployment\security, I could not find the trusted.jssecerts file.

The reason for this was kind of silly, but made sense in the end. Our CX4-960 is called sandc10003 and sandc10004. However the SPs identify as A-IMAGE and B-IMAGE. This is some kind of FLARE 29 thing where, regardless of the number of times we rename the SPs, reboots cause it to reset to A-IMAGE and B-IMAGE. So the presented certs get confused.

What I had to do was login to the array, and accept the Java Security Warning.

The trusted.jssecerts file was then created on my workstation. Once this was present, I logged into USM, and was able to accept the certificates permanently. Hooray.