Sometimes, after the SKLES appliance has been operational, you may have a need to change the Transmission Control Protocol/Internet Protocol (TCP/IP) address of the appliance's primary interface and/or the fully qualified domain name (FQDN) of the appliance. This appendix walks you through the process of how to do this.

If your SKLES appliance is already in production, you will have to coordinate this activity with the application(s) that request cryptographic web-services from the appliance, as well as the Domain Name Service (DNS) that provides name-address resolution within your network. If the appliance is not providing services to any application yet – either in production or development - you may perform this task anytime as it will not affect any applications. However, you may still need to coordinate with the DNS configuration as the application itself may be relying upon name services from DNS for its own network configuration.

Post-Production

To change the IP address after the appliance is in production, perform these tasks:

1. Login as the root user into the appliance – either on the console directly or using ssh;
2. Verify that applications have stopped making web-service requests to the appliance and that no batch jobs are currently running when you plan to make the change. You can verify this by monitoring the server.log file in the STRONGAUTH_HOME/glassfish/domains/domain1/logs directory by using 'tail -f server.log' in that directory. If there is no activity for a few minutes – indicated by the absence of new transaction log messages - this should indicate that no service request is being processed or any batch job is executing;
3. Temporarily block port 8181 of the appliance's firewall to ensure that no web-service request comes into the appliance while you're performing this task. You can do this by using a text editor on the appliance to comment the line with port 8181 in the /etc/sysconfig/iptables file, saving the file and restarting the iptables service (see the chapter on Disaster Recovery for details on how to do this);
4. Update your DNS master to reflect the new TCP/IP address of the appliance, and propagate it to your network. Verify that the new address is visible using dig on Linux or nslookup on Windows and UNIX-like operating systems;
5. If you are using static TCP/IP address – which is strongly recommended – make a copy of the /etc/sysconfig/network-scripts/ifcfg-eth0 file (in case you need to reverse your changes);
6. Edit the ifcfg-eth0 file with a text editor and modify the following variables with appropriate values corresponding to the new TCP/IP address; save the file after the changes:
   
        BROADCAST
        GATEWAY
        IPADDR
        NETMASK
        NETWORK
   
   
7. Restart network services using service network restart;
8. Verify that the changes are accurate using ifconfig eth0;
9. If the changes are accurate, test it by using another machine and try to SSH into the appliance using the FQDN; if you are able to connect, your changes were successful at the network layer. If you are unable to connect, retrace your steps and correct any errors; if you are still having trouble contact your network administrator for help;
10. If the SSH test to the appliance succeeds, test the appliance by decrypting the “well-known” token – usually 9999000000000001 – from a remote machine; do not test this from the appliance itself. If this succeeds, your IP address changes are successful; if it does not work, reboot the appliance. When the machine has rebooted, activate the TPM. If the Key Custodians can reach the appliance using the KCSetPIN Tool from their remote PCs, this implies that the IP address changes are successful.
11. Once this is successfull, you will have to open up port 8181. You can do this by using a text editor on the appliance to uncomment the line with port 8181 in the /etc/sysconfig/iptables file, saving the file and restarting the iptables service (see the chapter on Disaster Recovery for details on how to do this); When you are modifying the iptables, you will also have to modify the IP address range for mysql port 3306. Change it to reflect the new IP address for the replication.
    
    -A SKLES-Firewall -m state --state NEW -m tcp -p tcp -m iprange --src-range
    <New IP address range> --dport 3306 -j ACCEPT

To change the hostname of the appliance at any time, perform these tasks:

1. Login as the root user into the appliance – either on the console directly or using ssh;
2. Verify that applications have stopped making web-service requests to the appliance and that no batch jobs are currently running when you plan to make the change. You can verify this by monitoring the server.log file in the STRONGAUTH_HOME/glassfish/domains/domain1/logs directory by using 'tail -f server.log' in that directory. If there is no activity for a few minutes – indicated by the absence of new transaction log messages - this should indicate that no service request is being processed or any batch job is executing;
3. Temporarily block port 8181 of the appliance's firewall to ensure that no web-service request comes into the appliance while you're performing this task. You can do this by using a text editor on the appliance to comment the line with port 8181 in the /etc/sysconfig/iptables file, saving the file and restarting the iptables service (see the chapter on Disaster Recovery for details on how to do this);
4. Update your DNS master to reflect the new fully qualified domain name of the appliance, and propagate it to your network. Verify that the new name is visible using dig on Linux or nslookup on Windows and UNIX-like operating systems;
5. Make a copy of the /etc/sysconfig/network file (in case you need to reverse your changes);
6. Edit the network file with a text editor and modify the HOSTNAME variable with the appropriate value; save the file after the changes. If the /etc/sysconfig/network-scripts/ifcfg-eth0 file also has the HOSTNAME variable, modify it to the new value;
7. Using the hostname command on the command-line, change the FQDN of the appliance;
8. Restart network services using service network restart;
9. From a remote PC, ssh into the appliance using the new FQDN; if you can do so, then the changes are successful at the network layer. If you cannot SSH into the appliance, resolve the errors before continuing to the next step. Until you can communicate with the appliance over the SSH protocol using the new FQDN, it will be futile to continue;
10. Once connected to the appliance, make a copy of the /usr/local/strongauth/glassfish/domains/domain1/config/keystore.jks file in case you need to revert your changes;
11. To ensure that applications communicating with the SKLES can connect without errors to the SKLES, change the SSL certificate of the appliance after the hostname has been changed. Use the following command to generate a new self-signed SSL certificate with the new hostname in it; use the actual new fully qualified domain name (FQDN) of the appliance in place of the FQDN and the actual new hostname in place of the HOSTNAME variable:
    

    keytool -genkeypair -alias HOSTNAME -keystore /usr/local/strongauth/glassfish/domains/domain1/config/keystore.jks -storepass changeit -keypass changeit -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -validity 3652 -dname “CN=FQDN”

    
    If you changed the password of the keystore, make sure you use the new password in the command;
12. Using the following command, rename the certificate that had the s1as alias to another name; use the current date in place of DDMMYY:
    

    keytool -changealias -alias s1as -destalias s1as.original.DDMMYY
    -keystore /usr/local/strongauth/domains/domain1/config/keystore.jks
    -storepass changeit

13. Now rename the new certificate you created in step #11 to the s1as alias; Glassfish uses this certificate to establish its SSL port:
    

    keytool -changealias -alias HOSTNAME -destalias s1as -keystore /usr/local/strongauth/domains/domain1/config/keystore.jks -storepass changeit

14. Verify that the s1as certificate contains the new FQDN:

    keytool -list -v -alias s1as -storepass changeit -keystore /usr/local/strongauth/domains/domain1/config/keystore.jks

    You should see output similar to the following
    

    Alias name: s1as
    Creation date: Jan 15, 2012
    Entry type: PrivateKeyEntry
    Certificate chain length: 1
    Certificate[1]:
    Owner: CN=atlas.strongauth.com, OU=StrongKey Lite Encryption System, O=StrongAuth Inc
    Issuer: CN=atlas.strongauth.com, OU=StrongKey Lite Encryption System, O=StrongAuth Inc
    Serial number: 4f1352da
    Valid from: Sun Jan 15 14:27:38 PST 2012 until: Fri Jan 14 14:27:38 PST 2022
    Certificate fingerprints:
         MD5: 04:7A:E2:1E:ED:63:F6:E6:F9:C8:FC:CA:1D:49:08:D5
         SHA1: 68:8B:8F:53:75:74:0C:BD:47:52:38:EE:19:85:C6:3C:6C:24:2F:F2
         Signature algorithm name: SHA256withRSA
         Version: 3

15. If the correct FQDN shows up in the output, export the certificate to a file so it can be imported on all machines that will communicate with the appliance; this includes the PCs of the Key Custodians, the administrator using DACTool and every application that will request cryptographic web-services from the appliance; substitute the actual hostname of the appliance in place of the HOSTNAME variable in this command:

    keytool -exportcert -alias s1as -file /usr/local/strongauth/HOSTNAME.der --keystore /usr/locao/strongauth/domains/domain1/config/keystore.jks -storepass changeit

16. Restart Glassfish;
17. Reopen port 8181 on the appliance to ensure that applications can communicate with the web-services on the appliance;
18. Using sftp, copy the HOSTNAME.der certificate to all the machines that will communicate with the appliance;
19. Import the new certificate into the JVM of the PCs of the Key Custodians using the instructions from Chapter 3 of the Reference document – section titled “Adding the SKLES Certificate to the JVM”;
20. Using the KC SetPIN Tool, activate the TPM on the appliance making sure that you use the new FQDN in the URL; if you are able to set the pin successfully, the new FQDN changes are successful. If you are unable to connect to the appliance, verify that you do not see any “PKIX Validation” errors in the terminal from which you started the SetPIN Tool (as shown below):

    Exception in thread "main" javax.xml.ws.WebServiceException: Failed to access the WSDL at:
    https://demo.strongauth.com:8181/strongkeyliteWAR/EncryptionService?wsdl. It failed with: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.
     at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:151)
     at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:133)
     at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:254)
     at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:217) 
     at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:165)
     at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:93)
     at javax.xml.ws.Service.<init>(Service.java:56)
     at com.strongauth.strongkeylite.web.EncryptionService.<init>(EncryptionService.java:79)
     at strongkyeliteClient.Main.main(Main.java:109)

    Correct the errors and try it again.

If you continue to have difficulty in connecting to the appliance, contact StrongAuth for support.