Configuring SSL for the Web Application Server
HTTP Secure (HTTPS) is a communication channel used for secure communication over a computer network. In PTC Arbortext Content Delivery, HTTPS uses Secure Sockets Layer (SSL) to ensure all data passed between the PTC Arbortext Content Delivery web server and browsers remain private and integral. SSLs are cryptographic protocols designed to provide secure communication over insecure infrastructure. To support HTTPS in PTC Arbortext Content Delivery, 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 PTC Arbortext Content Delivery. 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 <HOME>/SW/SW/system/wildfly/standalone/configuration.
 |
• For PTC Arbortext Content Delivery, 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 <HOME>/SW/SW/System/WildFly/standalone/configuration.
b. For Offline system, open the standalone-full.xml located in the directory <HOME>/SW/SW/System/WildFly/standalone/configuration.
<security-realm name="SSLRealm>
<server-identities>
<ssl>
<keystore path="*.jks" relative-to="jboss.server.config.dir" keystore-password="<actual_password_value>" alias="<actual alias from certificate>"
key-password="<actual_password_value>"/>
</ssl>
</server-identities>
</security-realm>
<server-identities>
<ssl>
<keystore path="*.jks" relative-to="jboss.server.config.dir" keystore-password="<actual_password_value>" alias="<actual alias from certificate>"
key-password="<actual_password_value>"/>
</ssl>
</server-identities>
</security-realm>
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:
<HOME>/SW/SW/System/Java/bin/keytool.exe -exportcert -noprompt
-alias "<actual alias from certificate>"
-keypass "<actual_password_value>" -storepass "<actual_password_value>"
-file <HOME>/SW/SW/System/WildFly/standalone/configuration/cert.crt
-keystore <HOME>/SW/SW/System/WildFly/standalone/configuration/<certificate_name>.jks
-alias "<actual alias from certificate>"
-keypass "<actual_password_value>" -storepass "<actual_password_value>"
-file <HOME>/SW/SW/System/WildFly/standalone/configuration/cert.crt
-keystore <HOME>/SW/SW/System/WildFly/standalone/configuration/<certificate_name>.jks
5. Run the following command to import the CA certificate into the JRE certificate:
<HOME>/SW/SW/System/Java/bin/keytool.exe -import -noprompt
-alias "<actual alias from certificate>"
-keypass keypass "<actual_password_value"> -storepass keypass "<actual_password_value">
-file <HOME>/SW/SW/System/WildFly/standalone/configuration/cert.crt
-keystore <HOME>/SW/SW/System/Java/jre/lib/security/cacerts
-alias "<actual alias from certificate>"
-keypass keypass "<actual_password_value"> -storepass keypass "<actual_password_value">
-file <HOME>/SW/SW/System/WildFly/standalone/configuration/cert.crt
-keystore <HOME>/SW/SW/System/Java/jre/lib/security/cacerts
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 PTC Arbortext Content Delivery 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.
|
|
• Self signed SSL certificates can be used by Publisher and Viewers for internal HTTPS communications. The load balancer exposed to the external traffic should use a CA-signed certificate.
• 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.
If the web server is using self-signed certificates, perform the following steps for an offline system:
1. Copy the certificate of Viewer web server from <HOME>\SW\SW\System\WildFly\standalone\configuration\<Certificate_Name>.crt to the offline system at the same location.
2. On offline system, in a terminal navigate to <HOME>\SW\SW\.
3. Run the command importCertificate.bat/sh <Certificate_Name_without_.crt>
4. Restart the offline server.
For external CA signed certificate, no action is required.