Change self-signed certificate with custom certificate

Strongkey FIDO Server (SKFS) utilizes Transport Layer Security (TLS) to protect sensitive information on the network between a calling client Application and StrongKey FIDO Server (SKFS).

By default, each newly installed SKFS 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.

Our self-signed certificate is, actually, a little better than a Trusted-Third Party Certificate Authority (TTPCA) certificate because it provides a "speed bump" to anyone attempting to attack the webservice internally; if they're not familiar with how to deal with self-signed certificates, they'll be stumped with the error messages. A TTPCA certificate will almost always be trusted by the attacker's connection.

However, If you want to use a different certificate for SKFS, you need to import it using a Java KeyStore.

shell> cd /usr/local/strongauth/payara5/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 you are 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 your own FQDNs. If you have 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 you are not using Subject Alternative Names then you can 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.
When you receive 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 we will use this 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.jks keystore.jks.<date>
```
replace the current PKCS12 keystore with the new one, ensuring that the new keystore is renamed to keystore.p12.
```
mv newkeystore.p12 keystore.jks
```
Restart Glassfish
```
sudo service glassfishd restart
```

You can now 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.