Setting up a Certificate Trust Store for LDAP

The Active Directory servers support encrypted LDAP connections on port 636. These servers identify themselves with digital certificates, and Tomcat requires a certificate trust store to allow the connections to be verified. The standard Linux openssl command can be used to retrieve certificates from the LDAP server or servers that you are using. The Console Management provides a command script to create a trust store and add certificates to it.

For example, if your assigned server is ad.example.com, login to Linux using PuTTY or another SSH utility and run the following command:

openssl s_client -connect ad.example.com:636 -showcerts < /dev/null

If the connection test is successful, you will see an output that is similar to the following examples:

CONNECTED(00000003)
depth=2 DC = com, DC = bmc, DC = adprod, CN = BMC-CA
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
0
s:/C=US/ST=Texas/L=Houston/O=BMC Software Inc/OU=MainView Console Management/CN=ad.example.com
1 s:/DC=com/DC=bmc/DC=adprod/CN=BMC Issuing CA Phx
i:/DC=com/DC=bmc/DC=adprod/CN=BMC-CA
-----BEGIN CERTIFICATE-----
MIIGnjCCBYagAwIBAgITXwAAAA/agNE4CNfdxwABAAAADzANBgkqhkiG9w0BAQsF
.
.
.
XvHg4Fedwi6bJ6ouUFFkj63+
-----END CERTIFICATE-----
2
s:/DC=com/DC=bmc/DC=adprod/CN=BMC-CA
i:/DC=com/DC=bmc/DC=adprod/CN=BMC-CA
-----BEGIN CERTIFICATE-----
MIIDpjCCAo6gAwIBAgIQQ+2avlaOaL9Ct+UYsTEBSjANBgkqhkiG9w0BAQsFADBT
.
.
.
ABleXAE3WdzdiM0hS0wywRLPnEQVA5wzojA=
-----END CERTIFICATE-----
---
i:/DC=com/DC=bmc/DC=adprod/CN=BMC Issuing CA Phx
-----BEGIN CERTIFICATE-----
MIIG2zCCBcOgAwIBAgITaQAC2Ya4HR00SldxpAAEAALZhjANBgkqhkiG9w0BAQsF
.
.
.
cihePziMi59AzKVtqk6Z8WhGv2ywtkjHP84nbG2o0A==
-----END CERTIFICATE-----
Server certificate
subject=/C=US/ST=Texas/L=Houston/O=BMC Software
Inc/OU=MainView Console Management/CN=ad.example.com
issuer=/DC=com/DC=bmc/DC=adprod/CN=BMC Issuing CA Phx
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4885 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol: TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID: B7A58C88867A48A084725F13F8B37E5BC82EA342038835A74F2BF025EAB0D140
Session-ID-ctx:
Master-Key:
60FE0B0E65EDB66E1E4836F2C88775F295CCBEE7506AC0A919C6E43E0011BB9926823D245C07E60C805D7689B840C342
Key-Arg: None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time:1609795266
Timeout: 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
DONE

Each pair of BEGIN CERTIFICATE and END CERTIFICATE lines enclose an encoded digital certificate. The output displays the three most common types of server certificates.

The first certificate is the actual server certificate.

0 s:/C=US/ST=Texas/L=Houston/O=BMC Software Inc/OU=MainView Console Management/CN=ad.example.com
i:/DC=com/DC=bmc/DC=adprod/CN=BMC Issuing CA Phx
-----BEGIN CERTIFICATE-----
MIIG2zCCBcOgAwIBAgITaQAC2Ya4HR00SldxpAAEAALZhjANBgkqhkiG9w0BAQsF
.
.
.
cihePziMi59AzKVtqk6Z8WhGv2ywtkjHP84nbG2o0A==
-----END CERTIFICATE-----

Notes

In the certificate output:

The subject (s) line describes the server hostname.
The issuer (i) line identifies the first (or intermediate) signer of the server certificate.

The second certificate is the intermediate signer certificate. The intermediate certificate indicates that it was signed by a higher level or root certificate.

1 s:/DC=com/DC=bmc/DC=adprod/CN=BMC Issuing CA Phx
i:/DC=com/DC=bmc/DC=adprod/CN=BMC-CA
-----BEGIN CERTIFICATE-----
MIIGnjCCBYagAwIBAgITXwAAAA/agNE4CNfdxwABAAAADzANBgkqhkiG9w0BAQsF
.
.
.
XvHg4Fedwi6bJ6ouUFFkj63+
-----END CERTIFICATE-----

The third certificate is the top-level root certificate. In this certificate the subject (s) and issuer (i) lines are the same.

2 s:/DC=com/DC=bmc/DC=adprod/CN=BMC-CA
i:/DC=com/DC=bmc/DC=adprod/CN=BMC-CA
-----BEGIN CERTIFICATE-----
MIIDpjCCAo6gAwIBAgIQQ+2avlaOaL9Ct+UYsTEBSjANBgkqhkiG9w0BAQsFADBT
.
.
.
ABleXAE3WdzdiM0hS0wywRLPnEQVA5wzojA=
-----END CERTIFICATE-----

Once you get the certificates, place the intermediate and root certificates in a trust store for Tomcat. The server certificate is not required.

To do this, you have to repeat the openssl command, but now redirect the output into a file named root1.pem, then create a second copy of that file and name it as intermediate1.pem.

openssl s_client -connect ad.example.com:636 -showcerts< /dev/null > root1.pem

cp root1.pem intermediate1.pem

Edit both .pem files and remove everything except one single certificate, with BEGIN CERTIFICATE as the first line followed by the encoded lines ending in END CERTIFICATE. Make sure you have the root1.pem file containing the top certificate and intermediate1.pem file containing the intermediate certificate. The files you have should look as follows:

Verify that you have valid certificate files by using an openssl command, which will decode and display the certificate information. For example:

openssl x509 -in root1.pem -text -noout

A valid file may display something as follows:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
           43:ed:9a:be:56:8e:68:bf:42:b7:e5:18:b1:31:01:4a
    Signature Algorithm:sha256WithRSAEncryption
        Issuer: DC=com, DC=bmc, DC=adprod,CN=BMC-CA
        Validity
            Not Before: Sep 19 21:27:52 2012 GMT
            Not After : May 15 03:08:08 2046 GMT
        Subject:DC=com, DC=bmc, DC=adprod, CN=BMC-CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                   00:97:dc:c2:39:3e:f8:51:0b:bb:ba:3d:43:cc:fd:
                    ab:95:e4:ec:bc:9a:24:99:ac:07:0e:e3:83:85:f6:
                    b5:04:81:1d:37:ed:20:8a:30:41:87:1c:9d:6a:be:
                   03:c1:22:8a:01:dc:cd:d4:83:ad:ec:b9:64:38:66:
                   30:61:69:03:5b:3f:4a:37:42:8d:a4:d5:2b:12:c3:
                   81:44:61:8b:6e:b6:e6:06:e7:ea:9c:48:3e:1e:a4:
                    ec:d9:57:c5:27:85:ff:88:03:2d:e5:7a:a8:31:ac:
                   47:3b:32:41:df:4e:1d:c8:2e:ca:af:d6:4d:c0:0f:
                    cb:c2:40:e6:3a:e9:80:a6:cc:24:0e:1b:be:c5:01:
                   33:0d:79:01:3c:a7:e4:9b:29:69:3d:53:c6:3f:76:
                   8f:97:95:e9:90:29:4b:fc:bf:17:70:00:8f:71:83:
                   5b:d2:17:14:1f:90:55:50:60:14:e8:98:ce:b3:f9:
                   06:97:14:25:db:ac:7e:18:a2:4c:a7:1b:af:1f:db:
                   25:5a:ba:f7:77:95:4e:2f:89:6e:5a:08:04:43:3c:
                    b1:7d:77:d3:59:ec:26:9c:5f:fb:66:46:29:d6:5f:
                    e1:8f:f2:37:ea:53:44:be:d2:f4:82:fb:56:99:30:
                   1a:b7:37:4a:2d:93:78:f2:77:e5:36:99:a0:98:b5:
                   2c:59
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage:
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                A0:A8:B1:CE:4E:CE:09:AC:B5:D7:4F:59:53:2E:3D:2B:77:7A:2A:14
           1.3.6.1.4.1.311.21.1:
               ...
           1.3.6.1.4.1.311.21.2:
               ...d.TM....b.=.,.....-
    Signature Algorithm: sha256WithRSAEncryption
        37:ea:de:7f:6f:b8:dd:f2:aa:38:3a:93:a2:aa:79:71:ae:95:
        58:dd:4f:5d:34:0c:9a:26:5f:ca:0e:f6:51:47:a1:88:76:5c:
         dc:a7:fc:80:a6:99:97:47:a8:fc:22:82:f0:63:53:79:e8:b7:
        1e:a6:6a:18:f6:64:5d:54:66:89:c4:02:70:ea:5d:0d:cd:72:
         cf:07:2b:b1:c0:74:79:ed:08:a9:2a:50:d7:ae:5c:02:67:37:
         a2:37:17:66:ae:44:7c:c1:be:63:b1:a3:a7:73:92:1c:7a:fc:
        7b:81:22:3e:c4:52:e5:a3:34:4c:72:a7:2e:66:00:8d:e6:a5:
        4c:c5:cb:18:04:77:54:3b:9f:7b:ce:03:ee:6d:da:c1:f5:fe:
        5b:47:7c:22:14:b1:f3:01:21:3a:66:9f:64:77:4d:b1:4a:34:
         cb:3a:f6:73:11:0a:ab:da:7e:e1:4e:5b:20:9d:b3:53:c9:67:
         b9:93:34:5a:3a:47:26:b8:c1:4e:40:80:94:9d:4c:46:31:67:
        6d:e7:d8:81:20:86:49:5d:28:c7:9c:3f:96:f4:1f:11:2f:e4:
         c9:f5:2f:34:68:09:b6:20:08:de:fd:65:e5:77:00:19:5e:5c:
        01:37:59:dc:dd:88:cd:21:4b:4c:32:c1:12:cf:9c:44:15:03:
        9c:33:a2:30

If in the certificate, the Subject (s) and the Issuer (i) lines are same, then it is the root certificate.

After getting a valid individual signer certificate file, run a Console Management script to first add the root certificate and then the intermediate certificate.

/usr/tomcat/security/add-ldap-trusted.sh root1.pem

/usr/tomcat/security/add-ldap-trusted.sh intermediate1.pem

You can ignore any warnings about using a JKS or Java Keystore format.

The final step of trust store process involves adding it to the Tomcat start configuration. You can do this from the Linux command line by copying a configuration file from one directory to another. There is a period "." at the end of the copy command so that you can keep the same filename.

cd /usr/iocinst/config/tomcat
cp /usr/tomcat/conf/catalina-options.cfg .
chown iocadmin:iocgroup catalina-options.cfg

Now stop and restart the Tomcat web server.

systemctl stop tomcat
systemctl start tomcat

Access Console Management using a web browser to verify that Tomcat has started correctly.

Setting up a Certificate Trust Store for LDAP

BMC AMI Console Management for zEnterprise, BMC AMI Console Automation for zEnterprise, and BMC AMI SecureHMC 4.0

On this page