Validating LDD server certificates

1. From LMC, click the Device Groups tab.

2. From the Device Groups section, select a device group.

3. From the Tasks section, select eSF Configuration.

4. From the main section, select advancedprompt(AdvancedPrompting Bundle).

5. From the eSF Application Settings section, select Verify certificate.

6. From the Verification Mode menu, select either of the following, and then browse to the .PEM certificate file:

   • Chain—For CA-signed certificates. Make sure that the CA root certificate is installed in the truststore of the AP bundle. The eSF framework checks whether the CA has signed the server certificate.

   • Peer—For self-signed certificates. Peer checking does a one-to-one check of the certificate file. Make sure that the self-signed certificate is installed in the truststore of the AP bundle.

   Notes:

   • The certificate file may be a CA root certificate or a peer certificate.
   • If a certificate file is not specified, then the device trust store is used to get the root certificate.

7. Click Save Settings.

The settings and the AP bundle are deployed to the printer during policy update.

Understanding CheckHosts

The eSF framework automatically sets the CheckHosts setting with the host name from the URL. If there are multiple entries in the certificate in subject alternate name (SAN), then you may use CheckHosts to specify the other entries. Make sure that the certificate has the correct host name in SAN. Otherwise, the authentication verification fails.

The eSF framework checks only the host name using the server access with fully qualified domain names (FQDN). If LDD is installed as host only, then the AP Bundle uses the host name in the URL to access the Tomcat server. Make sure that the server certificate has the correct host name in SAN.

For example, if the LDD Tomcat server host name is LDDServer.LPM.TEST, then the common name and the SAN entry in the certificate must be LDDServer.LPM.TEST.

Adding certificates to the server KeyStore

Certificates can be added to the KeyStore (server.ks) file using a keytool utility that is included in Java Development Kit (JDK). LDD has a self-signed certificate added to the server KeyStore (server.ks) in the tomcat/conf folder.

Notes:

• The default KeyStore password for the server.ks file is password.
• The default Tomcat password in the server.xml file is changeit.

Setting up a KeyStore file with signed certificates

When OpenSSL is used to generate private keys and certificates, it is stored as separate files in the PEM encoding. However, the files cannot be converted into Java KeyStore format directly. Do the following:

1. Convert the files to a single file in PKCS#12 format that has a private or public key.

   Notes:

   • You may use the openssl pkcs12 command to merge private keys and certificates into a PKCS#12 file.
   • The system also supports multiple certificates for print encryption. These certificates are kept in the printcryption.ks file. For example: C:\Program Files\Lexmark\Solutions\apps\wf-ldss\WEB-INF\classes\.
   Note: You may use the openssl pkcs12 command to merge private keys and certificates into a PKCS#12 file.

   Sample PKCS#12 format conversion

   openssl pkcs12 -export -in servercert.pem -inkey serverkey.pem -out servercert.p12 -name tomcat -CAfile cacert.pem -caname root

   Where:

   • servercert.pem is the server certificate file.

   • serverkey.pem is the server private key file.

   • cacert.pem is the CA certificate file.

2. Using the keytool utility included in the JDK, convert the PKCS#12 file to Java KeyStore (JKS) format.

   Sample JKS format conversion

   keytool -importkeystore -deststorepass password -destkeypass password -destkeystore server.keystore -srckeystore servercert.p12 -srcstoretype PKCS12 -srcstorepass password     -alias tomcat

   Where server.keystore is the JKS format KeyStore file that must be copied into the tomcat/conf folder.