Once the new certificate has been installed on all appropriate applications and client devices, the keystore can be installed on the SAKA. In order for the new certificate to be utilized, the Glassfish Application Server on the Appliance must be restarted which implies a short downtime on the Appliance.

Sites may continue processing on secondary SAKA nodes during this downtime if they are capable of changing their applications to those SAKA. Otherwise, a 15-30 minute downtime window will be necessary for each SAKA as it is restarted and Key Custodian PINs are set.

On the Primary SAKA

1. Log in as "strongauth" user.
2. Copy the keystore.jks or keystore.p12 and crt file to the /usr/local/strongauth directory on the SAKA utilizing your preferred method (i.e. SCP, SFTP, etc).
3. Change directory to the glassfish configuration directory.

   shell> cd /usr/local/strongauth/<payara-version>/glassfish/domains/domain1/config

4. Rename the old keystore file.

   For Payara6, use the following command:
   shell> mv keystore.p12 keystore.p12.org
   
   For Payara5, use the following command:
   shell> mv keystore.jks keystore.jks.org
   

5. Move the new keystore to take the place of the old keystore.

   For Payara6, use the following command:
   shell> mv /usr/local/strongauth/keystore.p12 .
   
   For Payara5, use the following command:
   shell> mv /usr/local/strongauth/keystore.jks .
   

6. Import the new certificate into the Payara truststore:

   For Payara6, use the following command:
   shell> keytool -import -keystore cacerts.p12 -storepass changeit -alias saka.domain.name -file /usr/local/strongauth/saka.domain.name.crt
   
   For Payara5, use the following command:
   shell> keytool -import -keystore cacerts.jks -storepass changeit -alias saka.domain.name -file /usr/local/strongauth/saka.domain.name.crt
   

   If the alias 'saka.domain.name' already exists in the truststore, it is safe to choose any other alias that does not already exist in the truststore.
7. Import the new certificate into the java truststore.

   shell> keytool -import -keystore /usr/local/strongauth/certs/cacerts -storepass changeit -alias saka.domain.name -file /usr/local/strongauth/saka.domain.name.crt

   If the alias 'saka.domain.name' already exists in the truststore, it is safe to choose any other alias that does not already exist in the truststore.
8. Restart the Payara application server (supply the strongauth user's password when prompted). This step starts the downtime on this SAKA.

   For Payara6, use the following command:
   shell> sudo systemctl restart payara
   
   For Payara5, use the following command:
   shell> sudo service glassfishd restart
   

9. Have all Key Custodians Set PINs against this SAKA. The Key Custodians must have the new certificate already installed in the JDK truststore of their client device to make a successful connection to the SAKA. Ensure the certificate is installed in the correct JDK in case the Key Custodian has more than one JDK/JRE installed. If a Key Custodian fails to connect with a SunCertPathBuilder Exception this means the certificate was not imported into the correct JDK keystore.
   
   Example:

   sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

10. Once all Key Custodians have successfully set their PIN, the SAKA can start accepting requests from the calling application, either directly or through a Load Balancer. If the application is unable to make a connection to the SAKA and the problem cannot be resolved, rollback is possible by moving the old keystore.jks, now named keystore.jks.org back to keystore.jks. Restart Glassfish and set PINs again.
11. If the calling Application can connect to the SAKA and there are no errors, then this SAKA has been successfully installed with the new certificate.
    
    Repeat steps 2-1 through 2-10 on all other SAKA nodes in your cluster.