Manager certificates without MD5withRSA as signing algorithm

Document created by jcruz on Feb 4, 2015Last modified by jcruz on Feb 4, 2015
Version 4Show Document
  • View in full screen mode

Unfortunately, when you follow the procedure written on the ESM/Express Admin Guide for replacing the self-signed certificate that comes out-of-the-box with another one (possibly signed by your internal CA), the procedure states that you must use the keytoolgui to generate a new key pair. The problem with this is that keytoolgui doesn't let you choose some security parameters for the key pair to generate. Namely, one thing that makes me sick is the fact that if you generate a key via keytoolgui, the signing alghorithm will be MD5withRSA, by default (creepy, since we are in 2015!!).

 

 

So I put some effort in trying to generate a key pair with a decent signing algorithm (SHA256withRSA) and I just wanted to share this procedure with you, since I didn't find anything like this here at Protect724 or at the Knowledge Base.

 

 

First of all, I must say that although I was able to do this without problems and nothing wrong happened to the Manager, or event receiving stuff, you should follow this at your own risk! Anyway, if you follow this strictly, some steps will be to backup the original keys and certificates, so if anything goes wrong it should be easy to replace the original files.

 

 

This was tested in an ArcSight Express 4th gen (6.1.0.1389.0)

 

 

So, without further ado, let's get this thing safer! No more MD5!

 

 

1. Log in via SSH to the Manager as arcsight user.

 

2. Instead of using the keytoolgui as stated in the admin guide, we will use the keytool that comes in the Manager JRE. Execute the command below to generate a new keystore that will contain a new key pair. You can customize the command as you like, except the parameter alias that really must be "mykey", and storetype which must be "JKS".

 

This will create a new keystore file, named keystore.request. The command will prompt you for a password to protect the keystore and some key pair information. You must enter the same password as the keystore which is being used at the moment (which is, by default, "password" - lol).

 

 

It will prompt you for a password to protect the key pair inside the keystore, too. It must be the same password as the keystore so, just hit Enter.

 

/opt/arcsight/manager/jre/bin/keytool -genkeypair -v -alias mykey -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -validity 730 -storetype JKS -keystore keystore.request

 

Enter keystore password:

Re-enter new password:

What is your first and last name?

  [Unknown]:  <insert the common name (which should be the machine's hostname)>

What is the name of your organizational unit?

  [Unknown]:

What is the name of your organization?

  [Unknown]:

What is the name of your City or Locality?

  [Unknown]:

What is the name of your State or Province?

  [Unknown]:

What is the two-letter country code for this unit?

  [Unknown]:

Is ************** correct?

  [no]:  yes

 

 

Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 730 days

        for: ***************

Enter key password for <mykey>

        (RETURN if same as keystore password):

[Storing keystore.request]

 

 

 

3. Now we need to generate a Certificate Signing Request to sent to our internal CA. It will sign it and return to us a certificate signed by its private key. Just execute the following command. It will prompt you the keystore password you defined in the previous step:

 

/opt/arcsight/manager/jre/bin/keytool -certreq -v -alias mykey -file request.csr -sigalg SHA256withRSA -keystore keystore.request

Enter keystore password:

Certification request stored in file <request.csr>

Submit this to your CA

 

 

4. Just to make sure the request was correctly created, we can issue the following command. If the output says "verify OK", it should be fine:


openssl req -in request.csr -noout -verify

verify OK

 

 

5. When we receive the CA reply containing our certificate signed by them, probably they send their public key too (if not, request it). It will be needed in order to verify the signature of our certificate. For this to work, the cacerts file needs to have the CA public key. There are two ways to do this: You can import the CA public key to the existing cacerts or you can create a new one. I will demonstrate the second option, because the cacerts that comes by default have dozens of public keys of commercial CA's that I don't want to trust. Execute the command below and it will create a file named cacerts in the current directory. Just replace "ca.crt" with the filename containing your CA's public key and, if you'd like, the alias "rootca" (it can be anything). The command will prompt you for a password to protect this cacerts. It must be the same as the cacerts being used at the moment. By default it's "changeit" (lol).

 

/opt/arcsight/manager/jre/bin/keytool -import -file ca.crt -alias rootca -keystore cacerts

Enter keystore password:

Re-enter new password:

 

 

(.....certificate information.....)

 

 

Trust this certificate? [no]:  yes

Certificate was added to keystore

 

 

6. Now we will import our signed certificate to the keystore created in step 2. This import have a prerequisite: The CA public key that signed our certificate must be in the system cacerts, because there will be some verification in place when we import the certificate to the keystore created in step 2. To achieve this, the cacerts we created in the previous step must be in a specific place, and the system must know where is that cacerts. For the system to know the location, we need to set temporarily the environment variable JAVA_HOME and point it to the manager JRE.

 

Issue the following command:

(Before this, you may want to save the previous content of this environment variable, if any)


export JAVA_HOME="/opt/arcsight/manager/jre/bin/"

 

Now the system knows that the cacerts must be in $JAVA_HOME/../lib/security. We need to put our new cacerts there.

 

Backup the cacerts being used right know (just in case...)

 

cp $JAVA_HOME/../lib/security/cacerts $JAVA_HOME/../lib/security/cacerts.bak

 

And replace this cacerts with the one you created in step 5.

 

cp /path/to/cacerts_created_in_step_5/cacerts $JAVA_HOME/../lib/security/cacerts

 

Now we have everything set up to import the certificate in the keystore we created in step 2: The system knows where is the cacerts file (because we set the $JAVA_HOME) and that cacerts have our CA's public key. In the following command, just replace "ca_reply.pem" with the filename containing the CA's reply with your certificate signed by them. The command will prompt you the password of the keystore defined in step 2.

 

/opt/arcsight/manager/jre/bin/keytool -import -file ca_reply.pem -alias mykey -keystore keystore.request -trustcacerts

Enter keystore password:

Certificate reply was installed in keystore

 

 

7. Finally, we just need to place the keystore we've created in the right place.

 

Backup the current one (just in case):

cp /opt/arcsight/manager/config/jetty/keystore /opt/arcsight/manager/config/jetty/keystore.bak

 

And replace the keystore:

 

cp /path/to/keystore.request /opt/arcsight/manager/config/jetty/keystore

 

8. Additionally, I wanted this certificate to be presented in the ArcSight Web. In order to do this:

 

Backup the current Web keystore:

 

cp /opt/arcsight/web/config/jetty/webkeystore /opt/arcsight/web/config/jetty/webkeystore.bak

 

 

Backup the current Web cacerts:

 

cp /opt/arcsight/web/jre/lib/security/cacerts /opt/arcsight/web/jre/lib/security/cacerts.bak

 

 

And replace the webkeystore and cacerts of the ArcSight Web with the ones we created in this process

 

cp /path/to/keystore.request /opt/arcsight/web/config/jetty/webkeystore

 

cp /path/to/cacerts_created_in_step_5/cacerts /opt/arcsight/web/jre/lib/security/cacerts

 

 

Now you just need to restart all arcsight services and everything should be fine! Just open https://manager_hostname:8443 and https://manager_hostname:9443 and see if the certificate presented to you it's the same you've imported (and signed by the internal CA).

 

EDIT: Probably you will need to replace the cacerts of all connectors sending to this manager with the one you've created in this procedure. I could not validate this because I tried this on a fresh new Express appliance which is replacing our current hardware, so there were no connectors sending to this box.

 

 

If anything goes wrong, just replace the *bak's file and restart everything again. Everything should be back to normal.

 

 

Just for the record, following is a brief of the files changed in this process:

/opt/arcsight/manager/jre/lib/security/cacerts was replaced with the cacerts created in step 5. If anything goes wrong, you should have a backup of the previous cacerts (cacerts.bak, created in step 6)

/opt/arcsight/manager/config/jetty/keystore was replaced with the keystore.request created in step 2. If anything goes wrong, you should have a backup of the previous keystore (keystore.bak, created in step 7)

/opt/arcsight/web/jre/lib/security/cacerts was replaced with the cacerts created in step 5. If anything goes wrong, you should have a backup of the previous cacerts (cacerts.bak, created in step 8)

/opt/arcsight/web/config/jetty/webkeystore was replaced with the keystore.request created in step 2. If anything goes wrong, you should have a backup of the previous webkeystore (webkeystore.bak, created in step 8)

 

 

And that's it! No more MD5!

 

Kind Regards,

João Cruz

Attachments

    Outcomes