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. SSH to the SAKA and log in as strongauth.
2. Copy the keystore.jks 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/payara41/glassfish/domains/domain1/config

4. Rename the old keystore.jks file.

   shell> mv keystore.jks keystore.jks.org

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

   shell> mv /usr/local/strongauth/keystore.jks .

6. Import the new certificate into the glassfish truststore.

   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 Glassfish application server (supply the strongauth user's password when prompted). This step starts the downtime on this SAKA.

   shell> sudo /sbin/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.