a while back I followed these instructions
Secure Communications - CA Release Automation - 6.4 - CA Technologies Documentation
to enable https for the RoC in our company.
Now we need to change the certificate, for that they did send me a keystore and the password. Keystore has the file-ending "p12"
My question is now, how do I install this new certificate?
you should be able to do this using java's keytool:
keytool -importkeystore -destkeystore <%your .jks keystore%> -deststorepass <%your .jks keystore password%> -srckeystore <%your .p12 keystore%> -srcstoretype PKCS12 -srcstorepass <%your .p12 keystore password%>
nice seeing your name popping up again
So this command will be used to import the new p12 keystore into the current existing one, right? Which also means no other chances should be required afterwards?
Should I restart the nolio service after the import?
Yes, it will import the p12 keystore into the existing keystore as long as you point it there. As for whether any changes are necessary... I think that depends on whether there was an alias associated with the certificates when the .p12 certificate was created. You should be able to check this with command: openssl pkcs12 -info -in <your p12 filename>
My understanding is that the Bag Attributes -> friendlyName will be the name that is used as the alias when bringing into JKS. If there is no friendlyName then I was able to specify one in the destination keystore using:
keytool -importkeystore -destkeystore <my keystore filename> -deststorepass <destpass> -srckeystore <my p12 filename> -srcstoretype PKCS12 -srcstorepass <srcstore password> -srcalias 1 -destalias <my dest alias>
The thing that I'm not clear on is whether or not you will get an error if you try importing something that it already has an alias for. If it updates the alias with the new data, great. No additional changes except a Nolio Server service should be necessary.
If you need to change the alias then at a minimum you'll need to update your conf/server.xml.
The above is true specifically for updating the certs on the management server and updating the certificate used by the ROC. If you setup certificates between your NAC and NES then you may very well have to update the truststore on your NES. And if you had used the same certificate to secure ASAP with its own certificate then you may need to recreate the custom-truststore.jar and sign it with the new/updated certificate.
first of all, yes, we're only updating the certificate on the management server, as we only used an company internal one for securing the UI.
second, same aliases will be used, as they didn't change. I didn't really get now, if this is an issue or not or is it simply something you guys didn't try out yet?
I think we should be fine:
keytool-Key and Certificate Management Tool
"If the destination alias already exists in the destination keystore, the user is prompted to either overwrite the entry, or to create a new entry under a different alias name."
Or did you mean the same content of an alias, as the new keystore might have chosen a different one then I did when creating it?
hm...well, we'll definitely test it out tomorrow in our DEV environment
I wasn't sure, hadn't tested, what would happen if the new .p12 has the same alias and whether or not it might prevent you from importing the new .p12 if the alias was the same. But based on that quote it sounds like you would just need to overwrite it - though you probably will want to use the openssl info command to verify that a name/alias is associated with the certificates and/or run: keytool -list -v -keystore <your keystore filename>
after you finish the commands to make sure that the data in there is what you would expect with regards to aliases and such since the server.xml is very specific on what it is going to use.
I now tested the import commands simply on my machine without already setting it up on our management server.
what happens is the following:
the p12 certificate has a different alias, so after the import I now have 2 entries in my jks.
This would mean, that I can run the import without any issues but have to adjust the keyAlias in the server.xml, correct?
I hope there aren't any restrictions on the alias on your site, cause it is a pretty long one: lp-7b451c58-e094-4348-a84c-8a8083124171
Ok, sorry, things changed again a bit.
Turns out that the service doesn't provide everything required in the p12 file they send me, so I can't directly use the import but a script from a colleague that also includes some required root certificates into the jks.
This script basically creates a new jks file from the p12 one.
If I leave the alias, password and jks filename the same, do I need to do anything else other than replacing (overwriting) the current jks file I'm using and restarting the nolio server service?
If all of those things are the same then you should be able to rename the old, copy the new one to the conf folder, and simply restart the nolio server service. But this does assume that you weren't using https between your NAC and NES (can verify in agent management) and using the custom certs for ASAP.
yes, we're only using a custom certificate for the RoC, anything else either uses the internal CA ones or we're simply not using the secure line.
Thanks for your help