Let’s Encrypt Infor e-Commerce

Today I setup SSL/TLS for Infor e-Commerce using Let’s Encrypt, the new free, automated, and open Certificate Authority (CA).


Infor e-Commerce (f.k.a. Movex e-Sales) is a J2EE application running on IBM HTTP Server (IHS) and IBM WebSphere Application Server (WAS), where IHS is on the DMZ and has a certificate on port 443, and where WAS is on the local network and has a certificate on port 9043. That’s two certificates.

Step 1. Backup

Backup the following IHS and WAS files in case you need to restore them:

│   ├───conf
│   │       httpd.conf
│   │
│   └───Plugins
│       └───config
│           └───webserver1
│                   plugin-cfg.xml
│                   plugin-key.crl
│                   plugin-key.kdb
│                   plugin-key.rdb
│                   plugin-key.sth
                │   └───cells
                │       └───Node01Cell
                │           │   security.xml
                │           │
                │           └───nodes
                │               ├───AppNode01
                │               │       key.p12
                │               │       trust.p12
                │               │
                │               └───WebNode01
                │                   └───servers
                │                       └───webserver1
                │                               httpd.conf
                │                               plugin-cfg.xml
                │                               plugin-key.crl
                │                               plugin-key.kdb
                │                               plugin-key.rdb
                │                               plugin-key.sth
                │                               server.xml

Step 2. Setup IHS on DMZ

Setup IHS on the DMZ (DNS, firewall, etc.) to serve requests on the Internet:

Step 3. Key database

Let’s verify the key database.

The public/private keys, certificate signing requests (CSR), intermediate certificates, and signed certificates are managed in the IBM key database file format (KDB). Apparently, that format does not allow importing private keys that are created externally (e.g. with OpenSSL or EFF’s Certbot), so we must create them internally using either the IBM Key Management tool (iKeyman), the WAS admin console, or the gsk7cmd command. I will use iKeyman.
  1. Find the latest version of iKeyman (there are several versions of iKeyman throughout IHS and WAS); use version 8.0.399 or later for the most recent cryptographic properties (e.g. SHA256):
  2. Open the default plugin key database:

    The default password is WebAS. You can recover a lost password by calculating the stash (plugin-key.sth) XOR 245, or you can create a new key database from scratch.
  3. Ensure the Signer Certificates contains the same signer certificates as the WAS default trust store (e.g. datapower and root); compare by fingerprints. They should already be there; otherwise, extract them from the WAS admin console, and add them to the key database. That will allow IHS to trust WAS over SSL:

Step 4. Generate key pair + CSR

Let’s generate a public/private key pair and CSR.

  1. In iKeyman, delete the default personal certificate:
  2. Create a new key pair and CSR with the FQDN and cryptographic properties of your choice, leave the email address blank or certbot will throw an error, and save to some temporary file (e.g. certreq.arm):
  3. The result is a new public/private key pair in the key database (plugin-key.kdb) and a new CSR in PKCS#10 format (certreq.arm):

Step 5. Submit CSR to Let’s Encrypt

Let’s submit the CSR to Let’s Encrypt and get a signed certificate in return.

In the ACME protocol, the Let’s Encrypt servers will issue a set of challenges, and our web server must respond correctly to prove ownership of the domain. Normally, it is all automated, but there is no certbot plugin for IHS, so I will use the manual plugin. And because I have not yet tried an ACME client for Windows, I will use certbot on my Linux virtual machine.
  1. Execute certbot with the CSR as input:
    certbot certonly --manual --csr ~/certreq.arm
  2. Enter your email address, accept the Terms of Service, enter the domain name, and select Yes to log your IP address. It will present a challenge (a signed nonce):
  3. Create the specified file with the specified content at the specified path:
  4. Test the URL over the Internet (the Let’s Encrypt servers will request it):
  5. Back in certbot, press ENTER to complete the domain validation:
  6. The result is a signed certificate, intermediate chain, and full chain:

Step 5bis. Submit CSR to another CA

If you prefer, you can skip Let’s Encrypt, and submit the CSR to another CA of your choice (Verisign, Thawte, GoDaddy, Comodo, etc.).

Step 6. Add the certificate

Let’s receive the signed certificate into the key database.

  1. In iKeyman > Personal Certificates, receive the certificate 0000_cert.pem:
  2. Extract the Let’s Encrypt root certificate from one of the chains (e.g. with OpenSSL), or download it directly from IdenTrust at DST Root CA X3, and save it to a temporary file somewhere (e.g. dst_root.pem).
  3. In Signer Certificates, add the intermediate certificate 0000_chain.pem (Let’s Encrypt Authority X3), and the root certificate dst_root.pem (DST Root CA X3):
  4. Copy the key database files to WAS:

Step 7. SSL in IHS

Let’s enable SSL in IHS.

  1. Open the IHS configuration file in a text editor (e.g. Notepad):
  2. Add the following directives:
    ServerName example.com
    LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
    KeyFile C:\IBM\HTTPServer\Plugins\config\webserver1\plugin-key.kdb
    SSLStashFile C:\IBM\HTTPServer\Plugins\config\webserver1\plugin-key.sth
    Listen *:443
    <VirtualHost *:443>
    SSLProtocolDisable SSLv2 SSLv3
    SSLServerCert default
  3. Add the following to redirect all HTTP traffic to HTTPS; it is required for at least the login page, password change, credit card, XML Gateway, and a few other sensitive pages; it is optional for the rest:
    LoadModule rewrite_module modules/mod_rewrite.so
    RewriteEngine on
    RewriteCond %{SERVER_PORT} =80
    RewriteRule ^(.*) https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
  4. Copy httpd.conf to WAS:

Step 8. SSL in WAS

Let’s enable SSL in WAS.

  1. Ensure the default key store has a personal certificate signed by the signer certificates verified earlier:
  2. Set the default SSL configuration to use that server certificate (default):

WAS will not have the Let’s Encrypt certificate, but that’s OK for now.

Step 9. Backup + restart

Backup the files, and restart IHS and WAS.


The result is that the browser now trusts the site:


Let’s Encrypt does not provide Extended Validation (EV) certificates.

Future work

  • Use an ACME client for Windows
  • Automate the manual steps
  • Setup certificate renewal
  • Setup certificate revocation
  • Setup the new certificate in WAS too
  • Setup WAS for remote web server management
  • Replace IHS with nginx


That was my setup of SSL/TLS for Infor e-Commerce using Let’s Encrypt as the certificate authority. In a next post, I would like to setup the certificate in WAS too and setup automatic certificate renewal.

That’s it! Please like, comment, subscribe, share, contribute.

Published by


M3 Technical Consultant

3 thoughts on “Let’s Encrypt Infor e-Commerce”

    – Changed preferred path of iKeyman to IHS (instead of WAS)
    – Updated to latest version of iKeyman for SHA256 (instead of SHA1)
    – Changed screenshot of New CSR for SHA256 (instead of SHA1)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s