Configuring HTTPS for HTTP Server and Windchill
To complete these instructions, Windchill Services must be installed because it delivers the site.xconf file which is needed to complete an HTTPS configuration.
Out-of-the-box Windchill is configured for HTTP; however, Windchill is prepared to support HTTPS with the idea that minimal steps are required for you to implement HTTPS. The instructions provided in this section only support HTTPS with HTTP Server (the default Web server packaged with Windchill). Instructions for HTTPS for other Web servers must be obtained from the product vendor.
To enable Windchill to support HTTPS for other Web servers, you would:
• Use the xconfmanager to set the wt.server.codebase property (in wt.properties) to use HTTPS. This is the same instruction performed for HTTP Server.
• Restart the Web server, servlet engine and Windchill to effect the changes.
Configurations for HTTPS require the use of a commercial certificate of authority. Third-party vendors distribute certificates of authority. There are several configuration methods that can be implemented using certificates of authority. The instructions provided here should require a minimum of effort to implement HTTPS for your installation.
1. Obtain a certificate of authority.
The first step is to obtain a certificate of authority. Third-party vendors provide certificates. Windchill requires that the certificate be trusted by Java. If you elect to use a certificate that is not trusted by Java, then you must configure Java to trust this certificate. Certificates provided by Verisign and Thawte, for example, are Java trusted certificates of authority.
If the Web server certificate of authority is not trusted by Java, then the certificate of authority must be added to the jssescacerts keystore. Before executing the following command, the default JDK cacerts file must be copied to the filename jssecacerts. The cacerts file is located in <JRE>/lib/security directory.
keytool -import -alias <some alias name>
-file <path to certificateAuthority.cert> -storetype jks-keystore /<JRE>/lib/security/jssecacerts
This must be configured for the JRE that is used by the servlet engine, the Windchill server, and any other Java application that would access the Web server.
To list the default certificate of authority trusted by your JRE, execute:
keytool -list -v -keystore /<JRE>/lib/security/cacerts
Additional information about Java security can be found at:
http://java.sun.com/products/jsse
2. Configure HTTP Server to recognize the certificate of authority.
The certificate file and the private key are added to HTTP Server. By default, two files have been provided as a reference specifically for the purpose of security access configurations.
For PTC HTTP Server
a. Install the certificate file (server.crt) into the <Apache>/conf/ directory.
b. Install the private key (server.key) into the <Apache>/conf/ directory.
3. On PTC HTTP Server 2.4 the following command in HTTPSERVER_HOME enables SSL:
ant -DHTTPS_ENABLED=true -f config.xml reconfigure
4. Configure Windchill for HTTPS by changing the URL to HTTPS.
Using the xconfmanager change the following two properties to the appropriate values:
a. wt.webserver.port=<port used for HTTPS>. The protocol default port is 443.
b. wt.webserver.protocol=https
5. Restart HTTP Server.
The HTTPS HTTP Server start commands are the same for SSL or non-SSL servers:
PTC HTTP Server 2.4
Windows
<httpserver_home>\bin\httpd.exe
UNIX
<httpserver_home>/bin/apachectl
6. Restart Embedded Servlet Engine.
7. Restart Windchill.
Other Windchill products such as the workgroup managers may also support HTTPS and would require additional configurations to convert to HTTPS. See the workgroup manager documentation for those instructions.
Additional information about HTTPS can be found at:
|
|
PTC does not recommend TLS 1.1 (or earlier) configurations. You can use TLS 1.2 in Windchill configurations
|
Solaris 10 with SSL
When trying to access Windchill over HTTPS you may receive a “not found” error if your system is not up-to-date with the latest operating systems and patches. This is due to an issue with Solaris interface binding and the Apache host configuration. The OS incorrectly translates the default broadcast channel (255.255.255.255) into binary form so Apache doesn't find a correct matching virtual host in the <apache_home>/conf/extra/httpd-ssl.conf file, resulting in an error. There are two available workarounds for this:
1. Edit <apache_home>/conf/extra/httpd-ssl.conf and change the <VirtualHost_default_:port> to be whatever your IP address is on that machine. For example, change it to: <VirtualHost 132.253.10.34:443>. This will cause Apache to listen for the SSL requests on that particular IP. If you wish to listen on more than one interface, you would need to copy the whole <VirtualHost> tag section and change the IP to a second IP you wish to listen on.
or
2. Edit appropriate network files. Edit /etc/nsswitch.conf and add dns to the hosts section. For example, the hosts line might look like this: "hosts: dns nis files". Once that is done, you need to disable the name-service-cache daemon. With root access type, "svcadm disable system/name-service-cache:default", this will disable the service. Apache will now work with the _default v-host. To re-enable the daemon when you have finished testing you can type, "svcadm enable system/name-service-cache:default"
