I'm having trouble installing a renewed SSL Cert into our appserver.
I've run the relevant openssl commands on relevant privates keys (p12 files), CSRs and CA-signed Certs, but the private key that I believed was used during the creation of the CSR doesn't seem to match that of the public key of the CSR or CA-signed Cert.
I tried a test: create another CSR, and expect its public key's modulus to match that of the private key in the key...p12 file with which the current config, "NodeDefaultKeyStore", is configured. However, the modulus of that new CSR doesn't seem to match that of that p12 file:
llefever@LLeFever-PC MINGW64 /.../XXXX.com
$ openssl req -modulus -noout -in TEST-based-on-key-041020-clean.csr 2>/dev/null | openssl md5
(stdin)=
bcd385c1b93884eab92750c08b74db07llefever@LLeFever-PC MINGW64 /.../XXXX.com
$ openssl rsa -modulus -noout -in key-041020-clean.p12 2>/dev/null | openssl md5
(stdin)=
d41d8cd98f00b204e9800998ecf8427eSo, does WebSphere create a new key-pair for every CSR?
Generally, I believe we've been taking an unconventional approach -- in particular, not using WebSphere's admin-console screens properly and instead doing some things manually at the cmdln, in some cases with a JKS file, rather than with a p12 file.
That might be causing some confusion now, as we try to renew the Certificate. The first CSR I created, I created in the context of a different SSLConfig, one that, it turns out, is not active as the INBOUND config. So, that's apparently, fundamentally, why that one didn't work.
In any case, I'm not clear about how to import the new Cert (or Cert-chain) into WebSphere, in particular as regards ensuring the private key, CSR and renewed Cert all have the same modulus.
I'm thinking we might best create a whole new SSLConfig and generate a CSR from it, and then follow the usual steps from there, in terms of use of the admin console's features for "receiving" a CA-signed Cert into a given keystore. But, if we could avoid generating another CSR, that would be good, to save time.
Any advice would be much appreciated.
------------------------------
Larry LeFever
------------------------------