|
| 1 | +# Running the TLS tests |
| 2 | +The TLS connection tests found in [tls_connections_test.go](../tls_connections_test.go) |
| 3 | +demonstrate how to configure two different patterns of TLS; |
| 4 | +- Anonymous ("one way") TLS to encrypt traffic between the client application |
| 5 | +and the queue manager |
| 6 | +- Mutual TLS authentication, where the client application also authenticates itself |
| 7 | +to the queue manager by providing a client certificate |
| 8 | + |
| 9 | +In order to successfully run the TLS examples you must first apply some specific |
| 10 | +configuration to your queue manager using the following three steps; |
| 11 | + |
| 12 | + |
| 13 | +## Step 1: Define the queue manager channels |
| 14 | +The tests assume that two new channels have been created on the queue manager - one |
| 15 | +to demonstrate anonymous TLS, and the other for mutual TLS. |
| 16 | + |
| 17 | +You can define the necessary channels by executing the following runmqsc commands |
| 18 | +against your queue manager. Note that if your queue manager is configured to block |
| 19 | +all access by default (for example a queue manager hosted by the [IBM MQ on Cloud service](https://cloud.ibm.com/catalog/services/mq) or using the developer configuration for the [public MQ Docker container](https://github.com/ibm-messaging/mq-container/blob/6c72c894f775752a8ec8944d73dde4264711f0ff/incubating/mqadvanced-server-dev/10-dev.mqsc.tpl#L42)) |
| 20 | +then you will also need to execute the `SET CHLAUTH` command associated with each |
| 21 | +channel, otherwise you will receive a `MQRC_NOT_AUTHORIZED` after the TLS |
| 22 | +connection has been established. |
| 23 | +``` |
| 24 | +DEFINE CHANNEL(TLS.ANON.SVRCONN) CHLTYPE(SVRCONN) SSLCIPH(ANY_TLS12) SSLCAUTH(OPTIONAL) REPLACE |
| 25 | +SET CHLAUTH(TLS.ANON.SVRCONN) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL) CHCKCLNT(REQUIRED) DESCR('Allow applications to connect') ACTION(REPLACE) |
| 26 | +
|
| 27 | +DEFINE CHANNEL(TLS.MUTUAL.SVRCONN) CHLTYPE(SVRCONN) SSLCIPH(ANY_TLS12) SSLCAUTH(REQUIRED) REPLACE |
| 28 | +SET CHLAUTH(TLS.MUTUAL.SVRCONN) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL) CHCKCLNT(REQUIRED) DESCR('Allow applications to connect') ACTION(REPLACE) |
| 29 | +``` |
| 30 | + |
| 31 | + |
| 32 | +## Step 2: Import the queue manager certificate into the client key store |
| 33 | +The [anon-tls.kdb](anon-tls.kdb) and [mutual-tls.kdb](mutual-tls.kdb) files are |
| 34 | +keystores that contain certificates that are used when the test applications |
| 35 | +connect to the queue manager. |
| 36 | + |
| 37 | +The keystores have been configured to contain the public certificate for the DigiCert Root |
| 38 | +certificate authority (CA) so that the tests will automatically work against any |
| 39 | +queue manager that presents a certificate issued by DigiCert (such as queue |
| 40 | +managers hosted by the IBM MQ on Cloud service), however if your queue manager |
| 41 | +uses a certificate issued by a different certificate authority then you will need |
| 42 | +to import the public part of that certificate into both of the keystores in order |
| 43 | +for the tests to pass. |
| 44 | + |
| 45 | +To do this, obtain a copy of the public certificate for your queue manager in PEM |
| 46 | +format, and import it into each of the keystores as follows; |
| 47 | +``` |
| 48 | +gsk8capicmd -cert -add -db anon-tls.kdb -file MyQMgrCert.pem -label MyQMgrCert -stashed -type kdb -format ascii |
| 49 | +gsk8capicmd -cert -add -db mutual-tls.kdb -file MyQMgrCert.pem -label MyQMgrCert -stashed -type kdb -format ascii |
| 50 | +``` |
| 51 | +Note that the `gsk8capicmd` command is included in the [IBM MQ redistributable client installation](https://ibm.biz/mq91cdredistclients) |
| 52 | +in the `./gskit8/bin` directory, or if you have a local queue manager installation |
| 53 | +then you can substitute that command for the `ikeycmd` command instead. |
| 54 | + |
| 55 | + |
| 56 | +## Step 3: Import the client certificate into the queue manager key store |
| 57 | +For the mutual TLS scenario you must also configure the queue manager so that it |
| 58 | +trusts the certificate that will be presented by the client application. The client |
| 59 | +will present the certificate with the label `SampleClientA` in [mutual-tls.kdb](mutual-tls.kdb), |
| 60 | +but for convenience the same certificate is also included in this directory |
| 61 | +as [SampleClientA.pem](SampleClientA.pem). |
| 62 | + |
| 63 | +The technique for importing the client certificate into the queue manager keystore |
| 64 | +depends on the type of queue manager you are using, for example; |
| 65 | +- For IBM MQ on Cloud queue managers you can import the certificate into the Trust |
| 66 | +Store as [described here](https://cloud.ibm.com/docs/services/mqcloud?topic=mqcloud-mqoc_jms_tls#twoway_mqoc_jms_tls) |
| 67 | +- For software installed MQ queue managers on Linux, use the `runmqckm` command [as described here](https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q012830_.htm) |
| 68 | + |
| 69 | +Note that in both cases you must refresh the queue manager security configuration |
| 70 | +in order for the new certificate to take effect - for example by executing the |
| 71 | +runmqsc command `REFRESH SECURITY TYPE(SSL)` or equivalent. |
| 72 | + |
| 73 | + |
| 74 | +## Reference: Creating your own key store files |
| 75 | +The [anon-tls.kdb](anon-tls.kdb) and [mutual-tls.kdb](mutual-tls.kdb) files in |
| 76 | +this directory have been pre-defined for use with the TLS tests defined in this |
| 77 | +repository, however you will create equivalent files for use with your own |
| 78 | +applications. |
| 79 | + |
| 80 | +The following commands demonstrate how the pre-defined files were created using |
| 81 | +the `gsk8capicmd` command. As noted above this command is supplied with the IBM |
| 82 | +MQ redistributable client installation, but if you have a local queue manager |
| 83 | +installation then you can substitute the `ikeycmd` command instead. |
| 84 | + |
| 85 | +``` |
| 86 | +# Create the anon-tls key store |
| 87 | +gsk8capicmd -keydb -create -db anon-tls.kdb -pw myKeystorePW -type kdb -expire 0 -stash |
| 88 | +
|
| 89 | +# Import the DigiCert Root CA certificate so that queue managers with certificates |
| 90 | +# issued by that CA will be trusted by default |
| 91 | +gsk8capicmd -cert -add -db anon-tls.kdb -file DigiCertRootCA.pem -label DigiCertRootCA -stashed -type kdb -format ascii |
| 92 | +
|
| 93 | +# Create the mutual-tls key store |
| 94 | +gsk8capicmd -keydb -create -db mutual-tls.kdb -pw myMutualKeystorePW -type kdb -expire 0 -stash |
| 95 | +
|
| 96 | +# Import the DigiCert Root CA certificate so that queue managers with certificates |
| 97 | +# issued by that CA will be trusted by default |
| 98 | +gsk8capicmd -cert -add -db mutual-tls.kdb -file DigiCertRootCA.pem -label DigiCertRootCA -stashed -type kdb -format ascii |
| 99 | +
|
| 100 | +# Create a new self-signed private key and certificate inside the mutual-tls keystore. |
| 101 | +# The client will present this certificate to identify itself to the queue manager |
| 102 | +gsk8capicmd -cert -create -db mutual-tls.kdb -pw myMutualKeystorePW -sig_alg SHA256WithRSA -expire 3650 -label SampleClientA -dn "O=Sample Client Corporation, C=UK" |
| 103 | +
|
| 104 | +# Extract the public part of the self-signed certificate so that it can be added |
| 105 | +# to the queue manager keystore in order that the queue manager trust the client |
| 106 | +gsk8capicmd -cert -extract -db mutual-tls.kdb -pw myMutualKeystorePW -label SampleClientA -target SampleClientA.pem |
| 107 | +``` |
0 commit comments