BMC Remedy Single Sign On Service Provider (SP) certificate shipped with the product, which is used to sign SAML request, will be expired on April 21st 2016.
If you are using out of the box certificate to sign SAML requests in BMC Remedy Single Sign On, the request will fail due to the expiry of certificate.
In this blog, I will be covering the steps to update the BMC Remedy Single Sign On (RSSO) SP certificate so that it has a new expiry date, which will prevent from failure of SAML authentication.
If this certificate has already been replaced with a newer one with a valid future expiry date, you don't have to follow the steps mentioned in this blog.
First of all, how to find the Certificate expiry date of relying party (RSSO) for SAML authentication?
- An easy way to find the certificate expiry is by logging to ADFS tool and checking the RSSO service provider relying party properties.
- In the Signature tab, you should see the certificate expiry date.
Likewise, for other IdP tools that you are using with RSSO, you will have to contact your IdP administrator to check the RSSO relying party certificate expiry date.
What steps are necessary to update BMC Remedy Single Sign On (RSSO) SP Certificate?
(A) The below instructions are written for Windows OS. All paths mentioned below are for Windows OS. Please use relative paths if you're using Linux or Solaris OS.
(B) The file name for the java keystore should be cot.jks. The alias for java keystore (cot.jks) should be test2. The password for the cot.jks keystore is 'changeit' Please do not change the password.
(C) Please make sure to set the Path environment to jdk or jre bin folder or else you may get error like ‘unknown internal or external command’. In Windows this means that you'll need to edit the System Environment properties and find the global variable PATH to update it.
Steps to update the certificate:
1. Update java keystore named cot.jks
Perform the following steps on the machine installed with RSSO server by being in <tomcat>\rsso\WEB-INF\classes folder:
a. Take a backup of existing cot.jks from <tomcat>\rsso\WEB-INF\classes folder
b. Delete alias ‘test2’ from existing cot.jks using keytool command line:
keytool -delete -alias test2 -keystore cot.jks
Note: The password for the cot.jks is "changeit". Please don't change the password
c. Create a new keypair with alias ‘test2’ in existing cot.jks
keytool -keystore cot.jks -genkey -alias test2 -keyalg RSA -sigalg SHA256withRSA -keysize 2048 -validity 730
Note: In the above example, we used 730 days as validity, which is equivalent to 2 years validity. You can use the validity days at your discretion
d. Export ‘test2’ certificate in PEM format
keytool -export -keystore cot.jks -alias test2 -file test2.pem –rfc
e. Take a backup of the updated cot.jks
If you have other RSSO server instances in same cluster, replace cot.jks in <tomcat>\rsso\ rsso\WEB-INF\classes folder with the updated cot.jks in step 1.e
2. Update signing certificate in RSSO Admin console
a. Login RSSO Admin console
b. Go to ‘General->Advanced’ tab
c. Open the file test2.pem which is created in step 1.d in text editor, remove the first line:
and the last line:
Also remove the newline delimiters (\r\n), and then copy the contents.
E.g. If you use Notepad++, you can open ‘replace’ dialog, select ‘Extended’ search mode, find ‘\r\n’ and click ‘Replace All’ button.
d. Paste the copied content in step 2.c to the ‘Signing Certificate’ field, replace existing content in the text area
e. Click ‘Save’ button to save the change
f. Wait for 15 seconds, view the realm using SAML, click ‘View Metadata’ button in ‘Authentication’ tab. Verify the SP metadata is updated with the new signing certificate.
3. Update SP metadata at IdP side
- Export the SP metadata in step 2.f and save it in a local file
- Send the exported SP metadata and the new signing certificate in step 1.d to IdP team for updating.
If the IdP is ADFS, the customer can add the new signing certificate as below:
a. Open ‘Properties’ dialog of the relying party for RSSO
b. Go to ‘Signature’ tab
c. Click ‘Add’ button, select the new signing certificate file and click ‘OK’
Notes for rolling upgrades (Cluster / High Availability environment)
Should you have a requirement for zero-down time in a cluster environment (assuming ADFS is the IdP) for the signing certificate update, then you can take actions with following sequence:
1. Take one RSSO server instance down first, perform step 1 on it
2. Perform step 2
3. Perform step 3 (remember NOT to delete the old signing certificate)
4. Make the RSSO server instance up again
5. Take the second RSSO server instance down, update its cot.jks with the one already updated on first RSSO server instance in step 1.e, then make it up again
6. Repeat step 5 on all other RSSO server instances
7. After the keystore cot.jks is updated on all RSSO server instances, you can remove the old signing certificate on the RSSO relying party at ADFS side.