CWPKI0672E: Alias "" is not a personal certificate in key store "CellDefaultKeyStore".

If you see: -

CWPKI0672E: Alias "" is not a personal certificate in key store "CellDefaultKeyStore".

when running a Jython script such as: -

cellID=AdminControl.getCell()
configAlias="WAS_to_WMQ"
cipher="SSL_RSA_WITH_AES_128_CBC_SHA256"

AdminTask.createSSLConfig('[-alias '+configAlias+' -type JSSE -scopeName (cell):'+cellID+' -keyStoreName CellDefaultKeyStore -keyStoreScopeName (cell):'+cellID+' -trustStoreName CellDefaultTrustStore -trustStoreScopeName (cell):'+cellID+' -serverKeyAlias -clientKeyAlias -jsseProvider IBMJSSE2 -sslProtocol TLSv1.2 -clientAuthentication false -clientAuthenticationSupported false -securityLevel HIGH -enabledCiphers '+cipher+' ]')

which returned: -

WASX7015E: Exception running command: "AdminTask.createSSLConfig('[-alias '+configAlias+' -type JSSE -scopeName (cell):'+cellID+' -keyStoreName CellDefaultKeyStore -keyStoreScopeName (cell):'+cellID+' -trustStoreName CellDefaultTrustStore -trustStoreScopeName (cell):'+cellID+' -serverKeyAlias -clientKeyAlias -jsseProvider IBMJSSE2 -sslProtocol TLSv1.2 -clientAuthentication false -clientAuthenticationSupported false -securityLevel HIGH -enabledCiphers '+cipher+' ]')"; exception information:
com.ibm.websphere.management.cmdframework.CommandValidationException: CWPKI0672E: Alias "" is not a personal certificate in key store "CellDefaultKeyStore".

consider stopping/restarting the wsadmin shell in order to create a nice clean new shell.

**UPDATE**

Or simply avoid trying to specify null aliases - instead of the above, use this: -

AdminTask.createSSLConfig('[-alias '+configAlias+' -type JSSE -scopeName (cell):'+cellID+' -keyStoreName CellDefaultKeyStore -keyStoreScopeName (cell):'+cellID+' -trustStoreName CellDefaultTrustStore -trustStoreScopeName (cell):'+cellID+'  -jsseProvider IBMJSSE2 -sslProtocol TLSv1.2 -clientAuthentication false -clientAuthenticationSupported false -securityLevel HIGH -enabledCiphers '+cipher+' ]')

thus avoiding the use of -serverKeyAlias and -clientKeyAlias altogether ( the objective is to ensure that both are NULL in order to avoid WAS > MQ connectivity problems over TLS ).

**UPDATE**

This old, but good, IBM document: -

PK86031: ADMINTASK.MODIFYSSLCONFIG UNABLE TO MODIFY NEWLY ADDED CERT DATA IN WORKSPACE TEMP, ERROR CWPKI0672E

led me to this solution, which is nice :-)

The text makes it more clear: -

...

Certificates added using AdminTask can not be modified with AdminTask.modifySSLConfig unless an AdminConfig.save() is performed before the modifySSLConfig.

Example error : CWPKI0672E: Alias "test_alias" is not a personal certificate in key store "CellDefaultKeyStore".

The modifySSLConfig command should read the key.p12 file from the workspace temp  - if there is any - and not just from the config repository.

The problem with executing the save operation is as follows:

For stable automation it is important that one script is executed as a unit.

If one command fails in this script, the whole commands in this script could be "rolled back". This is perfectly possible with the design of wsadmin. You execute your wsadmin commands and they do the changes only in your workspace temp. If one of your commands fail and you exit wsadmin, none of your previously executed commands will get saved.  Only at the end of your procedure you call the save operation and all changes get saved together.

However, if I have to do a save operation between these commands the first changes are already commited to the config repository although it is not assured that the next commands will succeed.

This could end in an inconsistent configuration state.

...

Whilst it's not 100% the same as my situation, I had had the wsadmin "shell" open for some time, and had also been deleting stuff from within the Integrated Solutions Console, meaning that the temporary configuration repository within the shel was likely to be out-of-sync with the cell configuration.

Bottom line, restarting the wsadmin client did the trick :-)