This documentation supports the 9.0 version of BMC Atrium Single Sign-On, which is in "End of Version Support." However, the documentation is available for your convenience. You will not be able to leave comments.

Click here to view the documentation for a supported version of Remedy Single Sign-On.

Creating a new key pair

The following topic provides information and instructions for creating a new key pair.

To create a new key pair

  1. On the BMC Atrium Single Sign-On Admin Console, click Edit Server Configuration. The Server Configuration Editor is displayed.
  2. On the Certificates tab, from the Certificate Store list, select the option for which you want to create a new Key Pair. 


    The New option is available only for KeyStore, SAMLv2 KeyStore, and Session KeyStore.

  3. Click New. The New Certificate Key Pair dialog box is displayed.

  4. Enter values for the following parameters:

    • Alias Name— When installing BMC Atrium Single Sign-On as a standalone, the alias name must be the FQDN of the host in which the certificate is to be installed. For example, When installing BMC Atrium Single Sign-On in an HA environment, you may enter any value in this field. For example, tomcat.
    • Validity Period—The number of days for which the certificate is valid. This value must be greater than 0.
    • SAN—SAN (Subject Alternative Names) is mandatory when the certificate has to be installed in an HA environment. Enter the FQDNs of all the nodes (for example,, sso-node2. in which the certificate has to be installed. In addition, you must also enter the FQDN of the load balancer ( (internal), (public)). When you enter the details, separate the different FQDNs using semi-colons.

  5. Click Generate.

    You are prompted to confirm whether you want to copy the same certificate to the TrustStore. Based on your confirmation, the key pair is created, and it appears in the list of TrustStore certificates as well.


    You must choose the option of copying the certificate while creating a new key pair and replicate it in the TrustStore. The certificate in the truststore helps you in establishing a trust relationship with the third party Identity Providers when using SAMLv2 authentication. To verify whether the certificate is imported into the TrustStore, see Checking the truststore for certificates.

  6. Stop and restart the BMC Atrium Single Sign-On server.

Was this page helpful? Yes No Submitting... Thank you


  1. Ivan Pirishanchin


    I have followed the steps outlined here for a HA environment. I created a new key-pair with alias="tomcat" and SAN=";;".

    Then I generated a CSR for that key-pair and sent it for signing at the CA. Once the CA returned a certificate, I imported it and restarted the nodes.

    The warning in the browsers did not disappear. The certificate "owner" field shows "CN=tomcat,OU=Atrium Core,O=BMC Software,L=Austin,ST=Texas,C=US" and the SAN field shows nothing (empty).

    What is the problem?

    Jul 31, 2015 05:34
    1. Kamalakannan Srinivasan

      Hi Ivan,

      Thank you for your comment. I will check with the concerned SME and get back to you.



      Jul 31, 2015 05:40
    1. Johann Groenewald

      Hi Ivan

      While Kamal is checking with our sounds like the CSR import into the ASSO cluster did not work as one would expect. Can you confirm the following

      1. You have configured Session Sharing in HA mode before attempting the CSR import?
      2. After you have imported the signed CSR, under the certificates tab within each node of the ASSO cluster where the Certificate Store = "KeyStore" ; was the certificate with alias 'tomcat' updated and is the certificate 'Type' attribute still reading as "KeyPair"? ... and can you see the signed CSR details on this 'tomcat' certificate?

      Regards, Johann


      Jul 31, 2015 06:13
      1. Ivan Pirishanchin

        Hi Johann,

        What is "Session Sharing"?

        The certificate was imported successfully as I can see the whole chain + the signed certificate in the keystore of both servers. But the Owner DN is invalid, because it is the dummy "tomcat" and the SAN field is empty since the import.

        Jul 31, 2015 06:23
        1. Johann Groenewald

          Hi Ivan

          Session sharing is all about ensuring that configuration changes made within a cluster are correctly replicated to all of the other nodes making up the cluster. Here is the URL for reference: Troubleshooting session sharing in HA mode


          Now to come back to your certificate and chain - from your reply I am almost sure now that your CSR import is the root cause of your problem i.e. it actually did not work properly as you would expect.

          You should have only one line item within the KeyStore where

          1. the Alias still reads as "tomcat"
          2. the Type still reads as "KeyPair"
          3. Owner should contain the new signed CSR data Owner
          4. Issuer should contain the details of the CA who signed the CSR
          5. Valid From should show timestamp of when the CA signed the CSR
          6. Valid Until should show a date in the future usually +two years
          7. SAN should contain your values from when you generated the CSR

          You do not need the rest of the key chain also inside this KeyStore. When import works correctly this signed certificate will be presented to your browser and it is within your browser that it will "walk the chain" up to a verified CA Root within the browser's (or browser's OS) trust store. Most known CAs will already have their Roots shipped with the OS and your company should have already uploaded any intermediates also into your OS PKI.


          Hope this helps - but I think you will have to log a ticket so that engineering can check in finer detail why your certificate import failed.

          Regards, Johann

          Jul 31, 2015 06:48
          1. Ivan Pirishanchin

            The import was successfull, the certificate generated by the CA is not good. There is no SAN extension in it.

            This is because the CSR does not contain any information about the SAN. Is it supposed to be like that or there's an issue with the CSR generation tool in HA mode?

            The changes are replicated between nodes, so I don't think I have to do anything with the Session Sharing.

            Jul 31, 2015 06:55
            1. Johann Groenewald

              Hi Ivan

              Here are the steps I have used recently at another customer (on Windows 2012 R2) can use these as a reference.


              [STEP 1] Generate a NEW public/private key-pair keystore.p12 file

              Before a new certificate signing request can be generated one must first create a brand new public and private key-pair on one of the new ASSO servers.

              The new key-pair will be stored inside the <ASSOinstallationDirectory>/tomcat/conf/keystore.p12 file.

              Start from fresh generating the certificate.

              Execute the commands from within the directory <ASSOinstallationDirectory>/tomcat/conf/

              Command: Make a backup of keystore.p12 file first! and then delete the original <ASSOinstallationDirectory>/tomcat/conf/keystore.p12 file

              Command: <ASSO_INSTALL_ROOT>\jre\bin\keytool.exe
              -alias tomcat
              -keyalg RSA
              -sigalg SHA1withRSA
              -keysize 2048
              -keystore keystore.p12
              -storepass internal4bmc
              -storetype pkcs12
              -dname "CN=, OU=xxx, O=xxx, L=xx, ST=xx, C=xx"
              -providername JsafeJCE

              Subject Alternate Names (or SANs) can be defined while generating a key-pair only within Java 7 and above. Alternatively the corporate certificate authority that will be signing this certificate can add the SAN’s to the certificate while signing – but make sure to tell them what the SAN values to use when you submit the CSR file.

              [STEP 2] Generate the new certificate signing request (CSR) file

              The new key-pair that was created in previous step can now be used to generate while at the same time digitally sign what will be known as a Certificate-Signing-Request or CSR.

              -v -certreq
              -alias tomcat
              -keystore keystore.p12
              -storepass internal4bmc
              -storetype PKCS12
              -dname "CN=, OU=xxx, O=xxx, L=xx, ST=xx, C=xx"
              -file asso.csr

              The Common Name (CN) of the certificate must match the FQDN of the ASSO Load Balancer. If the names do not match, the browser issues a warning telling you that the server is trying to impersonate another site. If this was a standalone installation i.e. no load balancer is involved, then the CN of the certificate must match the FQDN of the ASSO server.

              The result from the above command will be a CSR file named asso.csr

              [STEP 3] Submit the CSR file to your company's corporate certificate authority (CA)

              Send the generated csr file (asso.csr) to your corporate CA.

              Note: If the CSR file was generated (in Step 2) without using the “-ext san” switch then do not forget to request from the corporate CA to add the Subject Alternate Names (SANs) attribute to the certificate with FQDN of each ASSO server in the HA environment PLUS the FQDN of the ASSO Load Balancer.


              The CA should send you back ideally one file that contains the complete chain of certificates (Root and Intermediate) in PKCS#7 format (this format has a file extension of .p7b).

              Jul 31, 2015 07:15
              1. Ivan Pirishanchin

                Thanks a lot!

                I was doing all that through the GUI so far. I will try one more time and if it fails, I will go ahead and do it using CLI.


                Thanks again for your help!

                Jul 31, 2015 07:26
                1. Johann Groenewald

                  You're welcome Ivan. Give it another go and if you get stuck just let us know.

                  Regards, Johann

                  Jul 31, 2015 07:32
  2. Ivan Pirishanchin

    "When installing BMC Atrium Single Sign-On in an HA environment, you may enter any value in this field. For example, tomcat."

    I found that the above statement is not true with Setting anything else than "tomcat" in HA cluster will render the Atrium SSO console not accessible after restart of SSO services.

    Jul 31, 2015 07:53
    1. Johann Groenewald

      Hi Ivan

      This is also my understanding i.e. the alias should always read "tomcat".

      Kamalakannan Srinivasan can we confirm and update this recommendation pls?

      Regards, Johann

      Jul 31, 2015 08:02
  3. Carl Wilson


    Ivan is correct, the first "Alias" that is presented in the generation of the new key pair needs to reflect the Load Balancer / Server address.  

    When you generate the certificate, you are prompted for the alias of which to load the certificate into the keystore under - this is where you put "tomcat".  The label for Alias on the "New Certificate Key Pair" screen should not read "Alias" but should be "CN=" to be completely correct.

    This is for a HA configuration where you want to replace the certificate presented when accessing SSO via a Load Balancer.  You want to replace the OOB tomcat certificate created on install with the one you generate using this process. 



    Apr 06, 2016 10:50