that command is the last one you would apply so yes, this would be the same password as your root appliance. If you created the original wildcard cert with a key password other than the root appliance pw, then you would need to export the cert chain and key into a new keystore with the same pw as your root appliance. In my case, our cert engineers created the wildcard cert bundle and key without generating the csr from the appliance so we had to recreate this on our side. For this you need to know what the original source password was when creating the key.
NOTE: this is only for vcd 10.3 and later...
- we had to ensure the cert bundle (ie, the cert, intermediates and root were all chained together correctly which they were from the CA authority).
-once i had the cert bundle crt file and the key, I could recreate what i needed for the cert renewal.
-first i had to create a new keystore with the correct alias names. The default alias names that came with the cert in my case was "1" and I needed to create two new ones with the names "http" and "consoleproxy". You can do that with these commands:
/opt/vmware/vcloud-director/jre/bin/keytool -importkeystore -srckeystore /opt/vmware/vcloud-director/data/transfer/certs/mycertchain.pfx -srcalias 1 -destkeystore http.p12 -deststoretype pkcs12 -destalias http -destkeypass 'rootappliancepw' -noprompt
/opt/vmware/vcloud-director/jre/bin/keytool -importkeystore -srckeystore /opt/vmware/vcloud-director/data/transfer/certs/mycertchain.pfx -srcalias 1 -destkeystore consoleproxy.p12 -deststoretype pkcs12 -destalias consoleproxy -destkeypass 'rootappliancepw' -noprompt
This will create the two keystores called http.p12 and consoleproxy.p12 and the respective aliases you need for the http and consoleproxy from the wildcard.
Once created you can verify the alias names by viewing the keystores:
/opt/vmware/vcloud-director/jre/bin/keytool -list -v -keystore http.p12
/opt/vmware/vcloud-director/jre/bin/keytool -list -v -keystore consoleproxy.p12
Now generate the new pem and key files using the passwords of the root appliance
openssl pkcs12 -in http.p12 -out user.http.pem -nokeys
openssl pkcs12 -in http.p12 -out user.http.key -nocerts
openssl pkcs12 -in consoleproxy.p12 -out user.consoleproxy.pem -nokeys
openssl pkcs12 -in consoleproxy.p12 -out user.consoleproxy.key -nocerts
At some point during that process it will ask you several times for the password. This is goin off memory so I'm not 100% but you want to enter the new password as the same pw of your root appliance and if it asks for the source pw then that's whatever pw was created on the p12.
-Now copy all four user.* files to the root of /data/transfer directory
-set permissions and ownership on those files
chmod 750 /opt/vmware/vcloud-director/data/transfer/user*
chown vcloud:vcloud /opt/vmware/vcloud-director/data/transfer/user*
-Now on each cell (primary or standby) you can run your two commands to update the certs. NOTE: single quotes are needed on password input if you have special characters
/opt/vmware/vcloud-director/bin/cell-management-tool certificates -j --cert /opt/vmware/vcloud-director/data/transfer/user.http.pem --key /opt/vmware/vcloud-director/data/transfer/user.http.key --key-password 'rootappliancepw'
/opt/vmware/vcloud-director/bin/cell-management-tool certificates -p --cert /opt/vmware/vcloud-director/data/transfer/user.consoleproxy.pem --key /opt/vmware/vcloud-director/data/transfer/user.consoleproxy.key --key-password 'rootappliancepw'
-restart the services on each cell and you should be good to go.
Clear as mud?
