Securing the XML server

Secure an XML server that is remotely located from the client by setting up certificates and encrypting data. The XML server processes jobs submitted by a client to produce a formatted document in either PDF, RTF, HTML, or plain text.

About this task

Use TLS v1.2 to secure communication between the XML server and client by configuring the server certificate and encrypting data in motion.
Figure 1. XML Processing Architecture
This image contains a diagram that illustrates the preceding text.

Procedure

  1. Building a script with TLSKeystore.properties.
    The XML server uses the newly added TLSKeystore.properties file to build a script to specify the keystore and certificate properties that enable TLS communication between the XML server and client.
  2. The TLSKeystore.properties file properties are as follows:
    • keystore.filename - The name of the keystore file. The default is keystore.p12, but you can specify your own file name.
    • keystore.location - The location of the keystore file. keystore.location must be the full path to the keystore. For example, /Home/Server/KeystoreFolder/. The default is the current directory.
    • keystore.type - Specifies the type of keystore used. 'PKCS12' is the default and preferred, but you can also use 'JKS'.
    • keystore.alias - The alias that is used in keystore generation. The default is 'xmlserverks'.
    • keystore.password - The password for the keystore.
    • key.algorithm - Specifies the algorithm to be used to generate the keystore. The default is 'RSA'.
    • key.size - Key size in bits. The default is 2048.
    • key.validity - The number of days that the keystore is valid for. The default is 1825, which is 5 years, excluding leap years.
    If the certificate exists, modify the certificate.filename property to be the existing certificate's file name. This existing certificate must be located in the path that is specified in the keystore.location property, if specified. The existing certificate must be in Base64 encoded format. If certificate exists, the remaining properties are not needed:
    • certificate.filename - The name of the certificate to be used by the XML Server. The default is server.cer.
    • common.name - The default is 'XML Server'.
    • organisation.unit - The default is an empty string.
    • organisation - The default is an empty string.
    • locality - The default is an empty string.
    • state - The default is an empty string.
    • country - The default is an empty string.
  3. Generating a keystore:
    • You can specify your own keystore and certificate by changing the relevant properties in TLSKeystore.properties. The keystore and certificate location must be the same and must be specified in the keystore.location property.
    • If you do not have a pregenerated keystore, the XML Server build script generates one for use in TLS communication. When the XML Server is started, the build script calls the newly added targets that check whether a keystore exists. If it does not, the build script uses the Java™ keytool and the properties that are specified in TLSKeystore.properties to generate a new keystore and self-signed certificate.
    • The build scripts then attempt to add the certificate authority certificate to the truststore. That is, the public key certificate of newly generated self-signed certificate or CA certificate of the customer’s certificate to the truststore of JAVA_HOME. For example, $JAVA_HOME/lib/security/cacerts.
    • The targets that create a new keystore and certificate are also called during the server configuration stages of IBM® WebSphere® Application Server and Oracle WebLogic Server. For both WebSphere Application Server and WebLogic Server the configuration scripts call the build targets to generate a new keystore and certificate unless a different keystore is specified in TLSKeystore.properties. For WebSphere, the configuration scripts add your own or the newly generated keystore and certificate to the default truststore to allow communication between the XML server and client.
    Note: Troubleshooting tips:
    • Make sure that the certificate truststore of JAVA_HOME, for example: $JAVA_HOME/lib/security/cacerts has write permission.
    • If the XML Server fails to start due to corrupted generated default keystore keystore.p12, delete the keystore.p12 and server.cer files from the XML Server folder and restart the XML Server.
    • When using the JAVA_HOME default certificate truststore, for example: $JAVA_HOME/lib/security/cacerts, the XML Server assumes that the default password of the truststore is “changeit”. If the password is different from this, search for the string “changeit” in xmlserver.xml file and replace all the instances with the relevant password before restarting the XML Server.