000030477 - How to reset the Jetty certificate keystore back to default in RSA Security Analytics

Document created by RSA Customer Support Employee on Jun 14, 2016•Last modified by RSA Customer Support on Sep 26, 2019
Version 9Show Document
  • Comment • 0
  • View in full screen mode

Article Content

Article Number000030477
Applies ToRSA Product Set: Security Analytics
RSA Product/Service Type: Security Analytics UI, Security Analytics Server
RSA Version/Condition: 10.4.0.2 through 10.6.6.1
Platform: CentOS
O/S Version: EL6
IssueThis procedure may be used when the obfuscated password(s) used by the jetty-ssl.xml file when adding 3rd party certificates to the Jetty keystore has been lost.

This procedure may also be used if a Jetty keystore becomes corrupted for any reason.
CauseThere are 3 different credentials that a Java certificate keystore uses to unlock, establish and verify an SSL connection: trustStore, keyManager and keyStore credentials.  

In the SSL handshake, the trustStore credential is used by the "TrustManager". The "TrustManager" determines whether the remote connection should be trusted or not. 

The keyStore credential is used by the "KeyManager". The "KeyManager" decides exactly which credentials are to be sent for authentication during the SSL handshake.  

The keyStore password is the actual password that unlocks the keyStore itself.

These 3 passwords are represented in the /opt/rsa/jetty9/etc/jetty-ssl.xml as follows (noting the actual password hash is represented by the series of "X"s in the sample below)

<Set name="KeyStorePassword"><Property name="jetty.keystore.password" default="OBF:XXXXXXXXXXXXXXXXXXXXX"/></Set>

<Set name="KeyManagerPassword"><Property name="jetty.keymanager.password" default="OBF:XXXXXXXXXXXXXXXXXXXXX"/></Set>

<Set name="TrustStorePassword"><Property name="jetty.truststore.password" default="OBF:XXXXXXXXXXXXXXXXXXXXX"/></Set
ResolutionBefore beginning, if you do not have a backup copy of the default jetty-ssl.xml file from the Security Analytics server, download a default copy from the attachments section of this article. Then, sftp the default XML file to the /tmp directory of the Security Analytics server. Once you have a default copy of the XML file, ssh to the Security Analytics server as root and perform the following steps:
  1. Stop puppet:
    service puppet stop


    service puppetmaster stop

  2. Stop Jetty:
    stop jettysrv
     

  3. Move the carlos keystore to a backup file name:
    mv /opt/rsa/carlos/keystore /opt/rsa/carlos/keystore.bak.<todays date> 

  4. Move the jetty9 keystore to a backup file name:       
    mv /opt/rsa/jetty9/etc/keystore /opt/rsa/jetty9/etc/keystore.bak.<todays date>

  5. Move the current jetty-ssl.xml file to a backup file name:
    mv /opt/rsa/jetty9/etc/jetty-ssl.xml /opt/rsa/jetty9/etc/jetty-ssl.xml.bak.<todays date>

  6. Move the jetty-ssl.xml template controlled by puppet to a backup filename:        
    mv /etc/puppet/modules/saserver/files/jetty-ssl.xml /etc/puppet/modules/saserver/files/jetty-ssl.xml.bak.<todays date>

  7. Copy the default jetty-ssl.xml which is currently in /tmp both /etc/puppet/modules/saserver/files and /opt/rsa/jetty9/etc/jetty-ssl.xml 
    cp /tmp/jetty-ssl.xml /opt/rsa/jetty9/etc


    cp /tmp/jetty-ssl.xml /etc/puppet/modules/saserver/files

  8. Restart puppet
    service puppet start


    service puppetmaster start

  9. Restart jetty
    start jettysrv


     

  10. Allow jetty to fully restart (3-5 minutes), then run
    puppet agent -t 
     


    At this point, jetty's keystore will revert to the default keystore with no custom certificates or passwords. 

NotesIf you are on version 10.6.1 or later and another generated certificate has been applied then puppet will keep changing /opt/rsa/jetty9/etc/jetty-ssl.xml back to the previously generated certificate configuration. To prevent puppet from changing back to the previously configured certificate you need to modify the configuration in /etc/puppet/hieradata/common.yaml and set jetty_custom_certificate_enabled from true to false.

In case the first method does not work, another way to perform this is by setting /opt/rsa/jetty9/etc/jetty-ssl.xml to immutable so that the puppet cannot revert the certificate in the file:

chattr +i /opt/rsa/jetty9/etc/jetty-ssl.xml

But, if this is performed and when or if you need to modify the certificate to a custom certificate you should revert the immutable settings with:

chattr -i /opt/rsa/jetty9/etc/jetty-ssl.xml

Attachments

Outcomes