| Author | Message | 
		
		  | felipejo | 
			  
				|  Posted: Wed Jul 26, 2017 1:00 pm    Post subject: Problem using SSL in a SoapRequest node. - IIBv9 |   |  | 
		
		  | Newbie
 
 
 Joined: 26 Jul 2017Posts: 3
 
 
 | 
			  
				| Hi, 
 I have:
 - a certificate .pfx
 - IBM IntegrationBus v9
 - Linux RHEL v7
 
 I have some trouble using certificate to call a external webservice that uses this certificate. The old cerficate expires and the CA sends me this new .pfx. When I have configured the keystore and the truststore, I received this message when I executed the ws:
 
 
 javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j:
 PKIX path building failed: java.security.cert.CertPathBuilderException:
 PKIXCertPathBuilderImpl could not build a valid CertPath.;
 internal cause is:
 java.security.cert.CertPathValidatorException:
 The certificate issued by CN=Autoridade Certificadora Raiz Brasileira v2, OU=Instituto Nacional de Tecnologia da Informacao - ITI, O=ICP-Brasil, C=BR is not trusted; internal cause is:
 java.security.cert.CertPathValidatorException: Certificate chaining error
 
 
 The old certificate had the Root CA certificate like Autoridade Certificadora Raiz Brasileira v2.
 
 The new certificate has the Root CA certificate like Autoridade Certificadora Raiz Brasileira v5.
 
 
 See my config bellow:
 
 mqsireportproperties IB9PRD01 -o BrokerRegistry -r
 
 uuid='BrokerRegistry'
 brokerKeystoreType='PKCS12'
 brokerKeystoreFile='/var/mqsi/certificates/env/cert_2017/cert_2017.pfx'
 brokerKeystorePass='brokerKeystore::password'
 brokerTruststoreType='PKCS12'
 brokerTruststoreFile='/var/mqsi/certificates/env/cert_2017/cert_2017.pfx'
 brokerTruststorePass='brokerTruststore::password'
 brokerCRLFileList=''
 httpConnectorPortRange=''
 httpsConnectorPortRange=''
 brokerKerberosConfigFile=''
 brokerKerberosKeytabFile=''
 modeExtensions=''
 operationMode='advanced'
 shortDesc=''
 longDesc=''
 
 I used these commands bellow:
 
 
 
   
	| Code: |  
	| mqsichangeproperties IB9PRD01 -o BrokerRegistry -n brokerKeystoreFile -v /var/mqsi/certificates/env/cert_2017/cert_2017.pfx
 mqsichangeproperties IB9PRD01 -o BrokerRegistry -n brokerTruststoreFile -v /var/mqsi/certificates/env/cert_2017/cert_2017.pfx
 mqsireportproperties IB9PRD01 -o BrokerRegistry -r
 
 mqsistop IB9PRD01
 
 mqsisetdbparms IB9PRD01 -n brokerKeystore::password -u ignore -p 123456
 mqsisetdbparms IB9PRD01 -n brokerTruststore::password -u ignore -p 123456
 
 mqstart IB9PRD01
 
 
 |  
 When I tried to use a .JKS for the BrokerRegistry keystore, i received the error:
 
 java.security.KeyStoreException: problem accessing trust storejava.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
 
 
 Can you have some advices?
 
 Thanks a lot and sorry for my bad english!
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | mqjeff | 
			  
				|  Posted: Thu Jul 27, 2017 3:45 am    Post subject: Re: Problem using SSL in a SoapRequest node. - IIBv9 |   |  | 
		
		  | Grand Master
 
 
 Joined: 25 Jun 2008Posts: 17447
 
 
 | 
			  
				| 
   
	| felipejo wrote: |  
	| Thanks a lot and sorry for my bad english! |  My Spanish (Portugese) is worse than your English...
 
 Usually a certificate chaining error, it means that you don't have the full set of keys in the trust store to go from the specific cert up through it's CAs.
 
 Notice, it's the truststore here, not the keystore.
 _________________
 chmod  -R ugo-wx /
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | felipejo | 
			  
				|  Posted: Thu Jul 27, 2017 5:34 am    Post subject: |   |  | 
		
		  | Newbie
 
 
 Joined: 26 Jul 2017Posts: 3
 
 
 | 
			  
				| So, All I need to do is to put the old set of keys in my .pfx? 
 I´ll try it, and soon i'll post the results.
 
 Thanks mqjeff.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | Vitor | 
			  
				|  Posted: Thu Jul 27, 2017 5:46 am    Post subject: |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 11 Nov 2005Posts: 26093
 Location: Texas, USA
 
 | 
			  
				| 
   
	| felipejo wrote: |  
	| So, All I need to do is to put the old set of keys in my .pfx? |  
 No - you need to make sure you have all the certificates for the intermediate CAs in your trust store. So you trust the CA with v2 on the end of it's name but don't trust the CA with v5 on the end of it's name.
 
 You need the new (v5) root and intermediate certificates that go with your new personal certificate from the CA people, and add those to your trust store to form a chain.
 _________________
 Honesty is the best policy.
 Insanity is the best defence.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | joebuckeye | 
			  
				|  Posted: Thu Jul 27, 2017 10:50 am    Post subject: |   |  | 
		
		  |  Partisan
 
 
 Joined: 24 Aug 2007Posts: 365
 Location: Columbus, OH
 
 | 
			  
				| 
   
	| Vitor wrote: |  
	| No - you need to make sure you have all the certificates for the intermediate CAs in your trust store. So you trust the CA with v2 on the end of it's name but don't trust the CA with v5 on the end of it's name. 
 You need the new (v5) root and intermediate certificates that go with your new personal certificate from the CA people, and add those to your trust store to form a chain.
 |  
 I agree that adding the intermediate certificates will probably solve his issue but that is not the correct solution.
 
 The external website should be returning the intermediate certificates with it's certificate.  Clients should only have to root CA's in their truststores, not intermediate certs.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | felipejo | 
			  
				|  Posted: Thu Jul 27, 2017 11:24 am    Post subject: |   |  | 
		
		  | Newbie
 
 
 Joined: 26 Jul 2017Posts: 3
 
 
 | 
			  
				| Well, 
 I did what mqjeff said about put all my chain in the .pfx.
 
 In my trust.pfx I put the v2 chain and the v5 chain.(Root CA and itermediate).
 
 This trust.pfx I set on my trustStoreFile configuration at BrokerRegistry.
 
 It seems to work very well.
 
 Thanks mqjeff and Vitor.
 
 
 
   
	| Quote: |  
	| I agree that adding the intermediate certificates will probably solve his issue but that is not the correct solution.
 
 The external website should be returning the intermediate certificates with it's certificate. Clients should only have to root CA's in their truststores, not intermediate certs.
 
 |  
 joebuckeye, Can this solution that I made can generate any problems?
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | fjb_saper | 
			  
				|  Posted: Thu Jul 27, 2017 9:04 pm    Post subject: |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 18 Nov 2003Posts: 20767
 Location: LI,NY
 
 | 
			  
				| 
   
	| felipejo wrote: |  
	| 
 joebuckeye, Can this solution that I made can generate any problems?
 |  Well it really depends on what you are doing. If the v2 intermediate cert is no longer used anywhere on the broker, you can remove it from the cert store.
 
 The risk of keeping it in the cert store, is the risk of trusting an intruder if the v2 cert has been compromised.
 
 As to Joe's comment: most browsers receive periodic updates including to the certs in their truststores... For IIB you will have to make these updates as needed...
 
 Have fun
  _________________
 MQ & Broker admin
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | joebuckeye | 
			  
				|  Posted: Fri Jul 28, 2017 4:11 am    Post subject: |   |  | 
		
		  |  Partisan
 
 
 Joined: 24 Aug 2007Posts: 365
 Location: Columbus, OH
 
 | 
			  
				| 
   
	| felipejo wrote: |  
	| joebuckeye, Can this solution that I made can generate any problems? |  
 As fjb_saper says, the more certs you put into your trust store the more certs you will need to maintain and watch for their expiration dates and replace when needed.
 
 We actually discovered this issue years ago while supporting endpoints on Datapower.  We were only having the Front Side Handlers there return the server cert (ie stuff.abc123.com) and having the consumers put the root CA's and intermediate certs in their trust stores.  If the intermediate cert needed replacing or a new one was needed then we would have to work with all the consumers to make sure they updated their trust stores.  Quite a pain.  Doing some research we saw that best practice is for the endpoints to return the server cert and all the intermediate certs needed to establish the cert chain back to a trusted root CA.  This meant that the consumers then only had to worry about root CA certs (which generally last for many, many years) and our consumers then didn't have to worry about periodic cert updates unless a new root CA was needed (which is pretty rare).  This keeps most cert maintenance on the server side and lessens the places where updates need to be made.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  |  |