Using CA signed SAML Request certificates

Owned by Joachim Maksim
Last updated: Feb 09, 2023 by Steinar Line
3 min read

This guide will take you through the steps of using your own CA signed certificates instead of the selv-signed certificates created by K-SSO when signing SAML Requests sent to your Identity Provider. The guide uses the tool openssl which is found on Linux and OsX. Also, it uses keytool found in Java runtime which is installed with the Atlassian products.

We use in the example confluence-test as the certificate, key and file name. This name you can alter to what you want.

  1. First, create a certificate signing request. The command below will simultaneously generate a new RSA-encrypted private key:
    openssl req -new -nodes -out confluence-test.csr -newkey rsa:2048 -keyout confluence-test.key -subj '/CN=confluence-test.example.com/C=NO/ST=State/L=City/O=Company'

  2. Send the confluence-test.csr file to a certificate authority (CA), and acquire a signed certificate confluence-cert.crt.

  3. The CA will typically do something like this to sign the certificate:
    openssl x509 -req -in confluence-test.csr -CA EXAMPLE-CA.crt -CAkey EXAMPLE-CA.key -CAcreateserial -out confluence-test.crt -days 730 -sha256

  4. To view the crt file you get in return form your certificate authnority you may run this command
    openssl x509 -noout -text -in confluence-test.crt
    At this time you have three files with extensions .csr, .key and .crt. The .key and .crt files will be used in the next steps.

  5. Find the location of your Java keytool command typically located in <JAVA_HOME_DIR>/bin/keytool.

  6. Import the certificate into a Java Keystore (.jks) with this command:
    keytool -importcert -file confluence-test.crt -keystore confluence-test.jks -storepass changeit -alias mycert -trustcacerts

  7. Convert the certificate file to a .pem file to use in next step:
    openssl x509 -in confluence-test.crt -out confluence-test.pem -outform PEM

  8. Now create a .p12 file using the existing .pem file and the key:
    openssl pkcs12 -export -in confluence-test.pem -inkey confluence-test.key -out confluence-test.p12
    You will be asked to enter a password, which will be used in the next step. Set password to changeit
    The .p12 after this step contains both the certificate and key.

  9. Update the Java keystore file from step 6. by adding the previously generated .p12 file. Here, the source- and destination-password is set to changeit. You must use the password you set on the .p12 certificate file in the previous step. The destkeystore value can be anything you like:
    keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore confluence-test.jks -srckeystore confluence-test.p12 -srcstoretype PKCS12 -srcstorepass changeit -alias 1

  10. Change the private key alias in the Java keystore.
    keytool -changealias -alias 1 -destalias mykey -storepass changeit -keystore confluence-test.jk

  11. Then you can see inside the keystore file. Verify that both aliases mycert and mykey are present with command:
    keytool -list -storepass changeit -keystore confluence-test.jks

  12. Move the jks keystore file into the signing keys directory of your Atlassian product. The signing keys directory can be found with kerberos in the saml directory, <ATLASSIAN_PRODUCT_HOME_DIR>/kerberos/saml/keys.

  13. Last, you need to start using this new key. Do that by finding the key listed in the SAML Key Management page in Kantega SSO (see below) and press the Promote button on it. This should make the key the one that is used to sign outgoing SAML requests.

  14. You will also have to update the trust to this new key in your identity provider(s). To do this either refresh the metadata inside your IdP’s SAML configuration or use the Download button for the Current active keyand then install the certificate in your IdP’s SAML configuration.

 

  • If the new the jks keystore is not loaded correctly during Promote, the behavior of the SAML Key Management page is to create a new self-signed key. This indicates that the preparations of the above steps were not successful. Do verify all steps carefully and if you cannot figure out what is wrong contact us at support and we will help you out. Do also contact us if you have problems installing the newly created certificate into your IdP’s SAML configuration.