Configuring SSL for the Web Application Server
HTTP Secure (HTTPS) is a communication channel used for secure communication over a computer network. In Servigistics InService, HTTPS uses Secure Sockets Layer (SSL) to ensure all data passed between the Servigistics InService web server and browsers remain private and integral. SSLs are cryptographic protocols designed to provide secure communication over insecure infrastructure. To support HTTPS in Servigistics InService, you must configure SSL certificates that are validated by a third-party that is a trusted certificate authority, for the application. By default, the application uses port 8443 to communicate over SSL.
Supporting HTTPS by Using Third-Party Certificates (Trusted Certificate Authority)
A third-party certificate is validated by a trusted certifying authority. Ensure that the certificate validated by the third-party has the .keystore or .jks file extension.
In the following procedure, the third-party certificate is referred to as *.jks. The procedure applies to all the setup configuration types. Ensure that the secure port and Core host name is updated correctly in the configurator entities for Publisher and Viewers.
Follow these steps to use the *.jks certificate in Servigistics InService. In case of monolithic, split, and cluster configuration, you must follow the same steps on individual entities. That is, in case of split and cluster configurations, perform these steps on Publisher and each of the respective Viewer entities.
1. Stop all the coreServer, coreCMIserver, and JBoss services that are running.
2. Save the *.jks certificate in the location <INS_HOME>/InS_SW/SW/system/wildfly/standalone/configuration.
|
|
• For Servigistics InService, you must have an HTTPS certificate with the .jks extension.
• The password must be known.
• The certificates must have an alias. For example, jboss. The alias is set in the certificate during certificate generation.
|
3. Update the details related to the security-realm element for Web and Offline systems, as applicable.
a. For Web system, open the standalone-full-<database-name>.xml file located in the directory <INS_HOME>/InS_SW/SW/System/WildFly/standalone/configuration.
b. For Offline system, open the standalone-full.xml located in the directory <INS_HOME>/InS_SW/SW/System/WildFly/standalone/configuration.
Where:
◦ Keystore path: Name of your certificate.
◦ Keystore password: Certificate password.
◦ Alias: Actual alias from the certificate.
◦ Key password: Certificate password.
|
|
For Offline systems, modify the standalone-full.xml instead of standalone-full-<database-name>.xml.
|
4. Run the following command to export the *.jks certificate, the JAVA keystore certificate to a CA certificate:
5. Run the following command to import the CA certificate into the JRE certificate:
6. In case of split and cluster environments, import the newly created certificates for Publishers and Viewers by performing the following steps:
a. Copy the certificate from the sw/System/WildFly/standalone/configuration folder from one machine to another to the same location. Copy Publisher certificate to Viewer and Viewer certificate to Publisher.
b. Run the importCertificate.bat file and pass the parameter as Certificate Name. The SW folder contains the .sh or .bat files. For example, importCertificate.bat <FullCertificateName.crt>.
|
|
If you are using wildcard certificates, then you can skip this step for the cross-import of certificates.
|
7. Restart the coreServer, coreCMIserver, and JBoss services.
You can access the Servigistics InService web application by using SSL. For example, try the URL: https://localhost:8443.
Supporting HTTPS by Using Self-Signed Certificates
A self-signed certificate is an identity certificate that is signed by the same entity whose identity it certifies, rather than by a trusted certificate authority. The application automatically creates self-sign certificates when you install the application.
To support HTTPS, you must add certificates to the system.
|
|
• PTC recommends using only the SSL certificates from a third party that is a trusted certificate authority. Use of self-signed certificate must be restricted for the test system only. It is not recommended using the self-signed certificate for any production environment even behind the firewall.
• For the monolithic configuration, the application automatically creates certificates when you install the application.
• These steps are for creating and importing only the self-signed certificates.
|
1. Copy the certificate from sw/System/WildFly/standalone/configuration folder from one machine to other machine to the same location. Copy Publisher certificate to Viewer and Viewer certificate to Publisher.
2. Run the importCertificate.bat file and pass the parameter as machineName from where you copied the certificate. There are following .sh or .bat files in the SW folder.
For example, on the Publisher machine, go to the SW folder and run the following command:
◦ For Windows:
importCertificate.bat <v1.FullName>
◦ For Linux:
./importCertificate.sh <v1.FullName>
◦ On Viewer 1: For Windows
importCertificate.bat <Publisher.FullName>
For Linux
./importCertificate.sh <Publisher.FullName>
| • Import the certificate of Web server on an Offline system. In case of Offline SSL configuration, run the importCertificate.bat <primary_server_Full_host_Name> command. • Full name implies full domain name such as <host_name>.ptcnet.ptc.com. |
For Cluster Environment
For Split Environment
Troubleshooting
If some of the steps are incorrectly performed, and you want to import certificates again, perform the following steps:
1. Delete or rename the sw\System\Java\JRE\lib\security\cacerts file.
2. Delete inskeystore and all the certificates.
3. Run createkeyStore on all the machine with parameter as machine name.
4. Copy certificates as required.
5. Use importKeyStore to import other certificates on every machine.
