Creation of a server certificate to use the SunJsseListener

Secured communication of an HTTP client using the HTTPS protocol requires the use of a certificate on the server side. For the certificate of a server to be considered valid by the client, the following prerequisites must be met.


  • The server certificate must be valid, i.e. the name of the server in the certificate must match the server name specified in the URL and the current date is within the scope of the certificate.

  • The server certificate must be certified as valid by a trusted side. These certificates concerning the server certificate are grouped into a so-called certificate chain.

  • The trusted certificate must also have a validity period that includes the current date.


Below is a description of how a certificate can be created and signed by a certification authority. The process for creating a certificate to be used by the HTTP server is divided into the following steps.


  • Creation of a certificate with server-specific information.

  • Generation of a CSR (Certificate Signing Request).

  • Send the CSR to a certification authority (CA).

  • Import the certificate returned by the certification authority into the server certificate.


The SunJsseListener uses the Java-specific keystore format for the administration of certificates. Keystores can be handled with the command-line-oriented program "keytool" that is available with every Java installation and should be directly accessible. If this is not the case, check where the file is and add the path to the native environment variable of the system.

Creating a certificate


The following call causes the program "keytool" to create a new server certificate. Note: Enter the installation directory of the Integration Server for <IS>.


keytool -genkey -alias MyServerCertificate -keyalg RSA -keysize 1024 -dname\CN=my.server.domain, OU=Development, O=Lobster GmbH,C=DE" -keystore /<IS>/etc/sslkeystore.dat -storepass keystorepasswd -keypass certicatepasswd -validity 365


It should be noted that the call must be made in one line, even though it appears to be in multiple lines here. The individual parameters have the following meaning.


Parameter

Description

-genkey

Instructs "keytool" to create a new certificate.

-alias

The name under which the certificate is stored in the keystore and under which the certificate can be retrieved in the future.

-keyalg

The algorithm to use for the encryption process underlying the certificate.

-keysize

The key size to use.

-dname

The X.500 Distinguished Name that describes the certificate. The Common Name (CN) must match the name of the server as used later in the URL. Specifying a different name may cause clients to issue warnings that the specified name does not match the real name.

-keystore

The file name of the keystore to use. If no file with this name exists, a new file will be created.

-storepass

The password for accessing the keystore. If a new keystore is created, the specified password will be used as the new password to be set.

-keypass

The password for accessing the private key of the certificate. This is used for signing and authentication of the server.

-validity

The validity period of the certificate in days.


If the call is successful, the program terminates without any further messages. Afterwards, the keystore file should be located at the specified location.

If individual parameters are omitted (e.g. "keyalg"), a default value might be used or a prompt (e.g. with "dname") may appear.

Attention: Standard virtual machine installations may be limited in key size, e.g. to comply to export restrictions of the USA. Therefore, in order to be able to use acceptable key sizes, it may be necessary to unlock the virtual machine for strong encryption. For more information, please refer to the documentation of the virtual machine.

Creating a CSR


If the server certificate is to be accepted as valid by a standard browser, it must be signed by an accepted certification authority. For this purpose, a so-called Certificate Signing Request (CSR) must be prepared and sent to the certification authority. This is done by the following call of the program "keytool". Note: Enter the installation directory of the Integration Server for "<IS>".


keytool -certreq -alias MyServerCertificate -file MyServerCertificate.csr -keystore /<IS>/etc/sslkeystore.dat -storepass keystorepasswd -keypass certificatepasswd


In principle, the parameters here have the same meaning as described above. The newly added parameters have the following meaning.

Parameter

Description

-certreq

Instructs "keytool" to create a Certificate Signing Request (CSR).

-file

The file name under which the CSR file is to be saved.


If the CSR was created successfully, the program terminates without a message. You should find a corresponding file in the specified location. The contents of the file will be something like the following.


----- BEGIN NEW CERTIFICATE REQUEST -----
MIICXjCCAhwCAQAwWjELMAkGA1UEBhMCREUxGDAWBgNVBAoTD0VCRCBJbnRlZ3JhdGlvbjEUMBIG
A1UECxMLRGV2ZWxvcG1lbnQxGzAZBgNVBAMTEkludGVncmF0aW9uIFNlcnZlcjCCAbcwggEsBgcq
hkjOOAQBMIIBHwKBgQD9f1OBHXUSKVLfSpwu7OTn9hG3UjzvRADDHj + AtlEmaUVdQCJR +1 k9jVj6
v8X1ujD2y5tVbNeBO4AdNG / yZmC3a5lQpaSfn + gEexAiwk +7 qdf+ t8Yb + DtX58aophUPBPuD9tPF
HsMCNVQTWhaRMvZ1864rYdcq7 / IiAxmd0UgBxwIVAJdgUI8VIwvMspK5gqLrhAvwWBz1AoGBAPfh
oIXWmz3ey7yrXDa4V7l5lK +7+ jrqgvlXTAs9B4JnUVlXjrrUWU / mcQcQgYC0SRZxI + hMKBYTt88J
MozIpuE8FnqLVHyNKOCjrh4rs6Z1kW6jfwv6ITVi8ftiegEkO8yk8b6oUZCJqIPf4VrlnwaSi2Ze
gHtVJWQBTDv + z0kqA4GEAAKBgFN5vm5j0MItfhazooi9Vfck6wbtytScYKHkGFxUBVlhTCW6PUl3
nd2alJn5 / ZP8YmlCY + TwPXh2H +h+ IpMkYJ865DZ9QOehl8WWvKN /dq /7 sTm0h3VRMXhV + kaiHEOa
XTTtGWatbXpsvioiYHB8h +670 m7of4XhI9Ozvr1fKcKxoAAwCwYHKoZIzjgEAwUAAy8AMCwCFFIG
DBzzfekvCSEeqXDacUVz25XsAhR6 +0+ wi/ wEjac2RcOEYiQZ + NWPfA ==
-----END NEW CERTIFICATE REQUEST -----


This file can then be sent to the desired certification authority for the signing.

Importing the CA signature


If the certificate was signed by the certification authority and returned as a file (e.g. with the name "CASign.x500"), it must be integrated into the keystore. This is done by the following call. Note: Enter the installation directory of the Integration Server for <IS>.


keytool -import -alias MyServerCertificate -file CASign.x500 -keystore /<IS>/etc/sslkeystore.dat -storepass keystorepasswd -keypass certificatepasswd


If the certificate was successfully imported, the program usually terminates without an error message. Depending on the Java version, there might be a success message.

Subsequently, the server should be accessible via HTTPS without the browser issuing warnings or error messages regarding validity or lack of trustworthiness.

It should be noted that CA signatures are usually time-limited and must be renewed after this time, so that browsers do not generate expired certificate notifications.

Depending on the Java version, the root certificate used to create the CA signature must exist in the global (that is, Java-wide) or local ("sslkeystore.dat" in the example above) keystore. If this is not the case, more or less meaningful error messages, like the following, may appear.


keytool error: java.lang.Exception: Failed to establish chain from reply


In such a case, the root CA certificate must be manually reinstalled. This is done in the same way as when importing the CA signature; a suitable alias (previously not used by the Integration Server) must be selected. Here is a sample call with the demo certificate of "trustcenter.de".


keytool -import -alias trustcenterca0 -keystore testkeystore.dat -storepass keystorepasswd -file pr_TC_TrustCenter_Class_0_CA_2013.der