| Author |
Message
|
| andrewfemin |
 Posted: Thu Sep 06, 2018 3:39 am Post subject: IIB 10 Keystore settings |
 |
|
Acolyte
Joined: 26 Aug 2017
Posts: 54
|
Hi,
We currently have IIBv9 running on AIX. We have a Java Key Store configured in a local directory and the brokerKeystoreFile and brokerTruststoreFile properties of the broker are pointing to that directory. Whenever we have a message flow with a HTTPS request, we manually download the certificate(using a browser), upload it to the keystore(using keytool) and restart the execution group. If we don't do this, the HTTPRequest node throws SocketException.
We are now in the process of upgrading to IIBv10 in a Linux server. We have readied the new environment and are doing our testing. We still haven't created a keystore and haven't updated any Integration Node properties related to keystore. brokerKeystoreFile and brokerTruststoreFile are empty in the Integration Node. We have observed that in this new environment, without any keystore, the message flows with such HTTPS requests are working fine. They are able to make requests to https URLs without us explicitly uploading certificates to the Integration Node keystore.
I am unable to find any documentation in the KC related to this. Can someone please explain this behavior? Is it a feature of IIB 10? Can I trust it and take it to Production? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Sep 06, 2018 7:49 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
set environment variable IBM_JAVA_OPTIONS to javax.net.debug=ssl and see what ssl stores are being used in your case. I trust that it might work because the current truststore being accessed is not empty... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Thu Sep 06, 2018 8:28 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
The default truststore for your IIB 10 install is probably more up to date than the one from IIB 9 and it may have the proper Root CA's for the calls you are making.
Over time as old CA's expire or new ones are added you will need to maintain the truststore used by IIB. |
|
| Back to top |
|
|
| andrewfemin |
| Posted: Thu Sep 13, 2018 10:23 pm Post subject: |
|
|
Acolyte
Joined: 26 Aug 2017
Posts: 54
|
| Thanks for the replies. Even if the current trust store has the Root certificates and the Intermediate certificates, shouldn't it still fail because the URL certificates are missing in the Keystore? In IIB 9, message flows throw errors when all the certificates are not manually imported into the Keystore. Does IIB 10 do the certificate chaining by itself, like a browser? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 14, 2018 2:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| andrewfemin wrote: |
| Thanks for the replies. Even if the current trust store has the Root certificates and the Intermediate certificates, shouldn't it still fail because the URL certificates are missing in the Keystore? In IIB 9, message flows throw errors when all the certificates are not manually imported into the Keystore. Does IIB 10 do the certificate chaining by itself, like a browser? |
This is only the case if you verify the certs used in a SOAP with ssl headers.
For standard http ssl stuff it is enough to have the signer certs in the truststore and of course present an ssl cert as a server...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| andrewfemin |
| Posted: Mon Sep 24, 2018 1:33 pm Post subject: |
|
|
Acolyte
Joined: 26 Aug 2017
Posts: 54
|
| fjb_saper wrote: |
| set environment variable IBM_JAVA_OPTIONS to javax.net.debug=ssl and see what ssl stores are being used in your case. I trust that it might work because the current truststore being accessed is not empty... |
Thanks for this. I did this and found that the Integration Node is indeed referring to a keystore file in a location.
But when I run this command:
| Code: |
| mqsireportproperties TESTNODE -o BrokerRegistry -r |
this is what I get:
| Code: |
BrokerRegistry
uuid='BrokerRegistry'
brokerKeystoreType='JKS'
brokerKeystoreFile=''
brokerKeystorePass='brokerKeystore::password'
brokerTruststoreType='JKS'
brokerTruststoreFile=''
brokerTruststorePass='brokerTruststore::password'
brokerCRLFileList=''
httpConnectorPortRange=''
httpsConnectorPortRange=''
brokerKerberosConfigFile=''
brokerKerberosKeytabFile=''
allowSSLv3=''
allowSNI=''
reenableTransportAlgorithms=''
reenableCertificateAlgorithms=''
mqCCDT=''
modeExtensions=''
operationMode='advanced'
adminMessageLogging=''
productFunctionality=''
mqKeyRepository=''
dataCapturePolicyUri='/apiv1/policy/DataCapture/default'
shortDesc=''
longDesc='' |
Here are the questions I have:
1. Why isn't it showing the keystore here?
2. Is it ok to leave it without updating? What is the recommended approach here?
Thanks |
|
| Back to top |
|
|
| abhi_thri |
| Posted: Tue Sep 25, 2018 12:23 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
| andrewfemin wrote: |
1. Why isn't it showing the keystore here? |
That is the default behavior, i.e if keystore/truststore paths are not overridden then IIB will use the ones came with the installation jre path but agree it would be useful if the default path was explicitly shown at those params.
| andrewfemin wrote: |
2. Is it ok to leave it without updating? What is the recommended approach here?
|
It depends on your keystore/truststore maintenance process, if you intend to add certificates to it then it is best to keep it separate, eg:- take the default ones and move it elsewhere on the filesystem. You can then add your certificates to it and specify this path to the Broker.
Using the default keystore/truststore could cause issues in future, eg: if new fixpack is installed then the default path will now point to the new installation jre which means your certs won't be in there. |
|
| Back to top |
|
|
|
|
