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.
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:
Semicolon ( ; )
Double quotation mark ( ” )
Single quotation mark ( ‘ )
Circumflex ( ^ )
Backslash ( \ )
At times I wasn’t convinced that this list is comprehensive either.
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 V22.214.171.124.0490 so I upgraded to V126.96.36.199.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.