Replace/Renew SKSO Certificate with a new TLS certificate

Strongkey's Sign-On (SSO) utilizes Transport Layer Security (TLS) to protect sensitive information on the network between a calling client Application and strongauth FIDO Server (SKFS).

By default, each newly installed SKSO generates a key-pair and self-signed digital certificate to use for establishing TLS connections. At most sites, this setup is sufficient for the Application to make secure connections to the SKFS.

StrongKey's self-signed certificate offers a distinct advantage over a TTPCA certificate by deterring breaches within the webservice. Unfamiliarity with self-signed certificates will confuse attackers with error messages, unlike a TTPCA certificate that is often trusted by them.

To use an alternative certificate for SKSO, import it through a Java KeyStore:

shell> cd /usr/local/strongauth/payara6/glassfish/domains/domain1/config
Or
use alias
shell> ascfg

Generate a new key-pair using the keytool command

shell> keytool -genkeypair -alias s1as -keystore newkeystore.p12 -storepass changeit -storetype pkcs12 -keypass changeit -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -validity 365

If using Subject Alternative Names, then append the below line of code to the end of the above command, replacing “blue.strongkey.com”, “red.strongkey.com”, etc. with specific FQDNs. If there are more or fewer SANs, then add or remove the DNS entries separated by commas as appropriate:
```
-ext "SAN=DNS:blue.strongkey.com,DNS:red.strongkey.com"
```

Create a CSR. Again, replace the DNS entries in the SAN section as appropriate. If using Subject Alternative Names, then simply remove the section of code beginning with “-ext”

shell> keytool -certreq -alias s1as -keyalg RSA -file certreq.csr -keystore newkeystore.p12 -ext SAN=dns:blue.strongkey.com,dns:red.strongkey.com
shell> keytool -printcertreq -file certreq.csr

After creating the certificate signing request, it can now be sent to an external CA to be signed.
After receiving the certificate chain from the external CA, import them into the PKCS12 keystore. In the following command, chain.pem represents the certificate chain file from the external CA.
```
keytool -import -keystore newkeystore.p12 -alias s1as -keypass changeit -storepass changeit -file chain.pem
```
If the CA certificate and the signed certificate are packaged separately, then import the CA certificate into the keystore first before importing the signed certificate. In the following commands, cacert.pem represents the CA certificate and signedcert.pem represents the signed certificate from the external CA.
```
keytool -import -keystore newkeystore.p12 -alias cacert -keypass changeit -storepass changeit -file cacert.pem
keytool -import -keystore newkeystore.p12 -alias s1as -keypass changeit -storepass changeit -file signedcert.pem
```

Now, use the new keystore (newkeystore.p12) to replace the certificate in Glassfish keystore by following the steps below.

On the target server, save a copy of the old Glassfish file in case something goes wrong.
```
cp keystore.p12 keystore.p12.<date>
```
replace the current PKCS12 keystore with the new one, ensuring that the new keystore is renamed to keystore.p12.
```
mv newkeystore.p12 keystore.p12
```
Restart Glassfish
```
sudo systemctl restart payara
```

Connect to the Payara server on the browser to check the certificate that it uses to connect and ensure it matches the certificate that was issued by External CA with all SAN’s if applicable.