| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Implementing SSL without instaling certificate onto trustore |
« View previous topic :: View next topic » |
| Author |
Message
|
| vickas |
 Posted: Mon Dec 24, 2018 12:17 am Post subject: Implementing SSL without instaling certificate onto trustore |
 |
|
Centurion
Joined: 18 Aug 2013
Posts: 126
|
HI Experts ,
we have a requirement to call a HTTPS service without installing/downloading onto the ESB server ( i.e placing onto the broker truststore). The HTTPS service providers keep saying that the service provider hosts their certificate on cloud and its get changing without any notice.
So they want & recommend us to " check that we have a certificate without requiring you to download and install it" .
we - "here it refers to the service provider ".
So how can we proceed here ?
what do they mean when they say "check for certificate" ?
can we reach the HTTPS service without importing certificate in broker truststore ?
PLS help me with your inputs. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Dec 24, 2018 5:08 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
In this case, IIB is the SSL Client. If you are using the HTTPRequest Node to call out to the SSL Server, and both SSL partners trust the same Certificate Authority, then there is no need to install or copy certificates. IIB as an SSL Client can check if the cert presented by the SSL Server is correct for the URL you called - no need to copy the actual certificate.
See the Enable SSL certificate hostname checking parameter of the HTTPRequest Node.
If you set this parameter to yes, the only thing the message flow needs is access to a trust store with the trusted Certificate Authoritys root and intermediate certificates. These certs change very, very rarely (see more below). The message flow will only establish a connection if the SSL Server presents the correct certificate for the URL that the message flow calls. The certificate has to be non expired, signed by the trusted CA and its CN must match the URL you called. There should only be one certificate in the world that meets that criteria, if we trust our Certificate Authorities are doing their job. At this point the SSL Server can renew or replace their certificate as often as they want and you never need to get a copy from them, but you always know your connection will succeed only if the one correct certificate is presented.
When both ends of a SSL Handshake trust the same CA, there is no need to copy certificates between systems. Imagine if that were true. Every time Google, or IBM, or Facebook, or your bank, etc changed their cert they would have to contact millions of SSL Clients to provide a copy of their new cert. It just would not work. Our Web browsers have trusted CA root and intermediate certs in their trust stores, these are updated periodically thru routine patching and the browsers throw a warning if the URL you go to presents an incorrect certificate. Millions of websites can change their SSL certs regularly, no one needs to copy certificates, you can be sure you are talking to the correct website. IIB can do the same thing when its the SSL Client to an SSL Server and both ends trust the same CA. But you do need to maintain your root and intermediate certs in the trust store. Again, those change very rarely.
As long as your service provider as the SSL Server presents a certificate where the CN in the cert matches the URL that is being called, and its signed by a CA both you and they trust, then setting the HTTPRequest node Enable SSL certificate hostname checking parameter to yes should ensure the connection will only ever work if a cert that matches those details exactly is presented by them. Their side can renew that cert every day if it wants, but there will be no need to copy anything new each time. Instead of a human manually checking if its the correct cert for that URL and manually putting a copy of it into the trust store, now the technology (IIB) is checking to make sure its the only and only one certificate in the world that should be seen for that URL.
Note that Certificate Authorities do not collaborate. While one CA should never have 2 valid certificates for the same address, it is possible (however unlikely) that a second CA might give out its own cert for that same URL, perhaps to a bad actor. To mitigate this, a trust store should not contain the signer certs of every CA. It should contain the signer certs of only the CAs you wish to trust with your SSL partner, ideally only one CA.
We have to get out of the practice of copying certificates all over the place. Its needless busy work most of the time. It ignores the main benefit of using a Public Key Infrastructure with trusted Certificate Authorities. Copying certificates is a method that must be used with self signed certificates, or only if you are dealing with stale technology that can not do a basic check on the validity of that cert for that connection. IIB as an SSL Client can check if the cert presented by the SSL Server is correct for the IIB you called - no need to copy the actual certificate.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Wed Jan 02, 2019 7:37 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 364
Location: Columbus, OH
|
| PeterPotkay wrote: |
| the only thing the message flow needs is access to a trust store with the trusted Certificate Authoritys root and intermediate certificates. |
Small nitpick. Clients should only install Root CA's. Servers should be returning the server (ie hostname based cert) and any intermediate certificates needed to complete the SSL chain to a Root CA.
This way clients only need to add Root CA's to their trust stores.
Clients that need to install intermediate certificates are connecting to a misconfigured server. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 04, 2019 10:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| joebuckeye wrote: |
| PeterPotkay wrote: |
| the only thing the message flow needs is access to a trust store with the trusted Certificate Authoritys root and intermediate certificates. |
Small nitpick. Clients should only install Root CA's. Servers should be returning the server (ie hostname based cert) and any intermediate certificates needed to complete the SSL chain to a Root CA.
This way clients only need to add Root CA's to their trust stores.
Clients that need to install intermediate certificates are connecting to a misconfigured server. |
But that's not how it works. If you start from an empty truststore, you need to install the root CA and all the intermediate CA's in your trust chain into your truststore. Otherwise your chain is incomplete and the connection will fail... even though the full trust chain may be floated on the wire... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Mon Jan 07, 2019 6:15 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 364
Location: Columbus, OH
|
| fjb_saper wrote: |
| joebuckeye wrote: |
| PeterPotkay wrote: |
| the only thing the message flow needs is access to a trust store with the trusted Certificate Authoritys root and intermediate certificates. |
Small nitpick. Clients should only install Root CA's. Servers should be returning the server (ie hostname based cert) and any intermediate certificates needed to complete the SSL chain to a Root CA.
This way clients only need to add Root CA's to their trust stores.
Clients that need to install intermediate certificates are connecting to a misconfigured server. |
But that's not how it works. If you start from an empty truststore, you need to install the root CA and all the intermediate CA's in your trust chain into your truststore. Otherwise your chain is incomplete and the connection will fail... even though the full trust chain may be floated on the wire... |
Yes, that is how it is supposed to work. Clients are only supposed to install root CA's, not intermediate certificates. Intermediate certificates are the responsibility of the server, not the client. If you are needing to install intermediate certificates in a client then the server you are connecting to is not configured correctly.
Browsers and mobile devices only store Root CA's for what it's worth. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jan 07, 2019 11:39 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
I'm just watching from the sidelines as I don't know the answer but am interested. Leaf certificates change the most often, Intermediate change less frequently, Roots the less frequently of all. Obviously the ideal solution if you are interested in avoiding the needless busy work of swapping certs that don't really need to be would be present in the trust store to begin with is to only have the root(s) in a trust store.
I've always populated Roots and Intermediates into a Trust Store, but that is as much a force of habit as anything else. I have dealt with connections where it didn't work until I populated the trust store with the Intermediates, but that could be because the SSL Server wasn't configured properly to send the whole chain?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Tue Jan 08, 2019 7:35 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 364
Location: Columbus, OH
|
We discovered this during our working with Datapower and some interactions with 3rd parties.
In Datapower the Id Credentials you set up for endpoints (ie server) includes a section on Intermediate Certificates while the Validation Credentials you setup for calling endpoints (ie client) just includes certificates you trust.
IIRC, if you trust an intermediate certificate then that is where the chain ends and it doesn't go further up the chain.
We discovered we were doing this wrong when a 3rd party was attempting to connect to an external facing endpoint and our HTTPS FSH only had the DNS certificate in its Id Cred object. Before then we had been loading up our clients with the intermediate certificates (and it was becoming a pain to manage across the company).
Having to only worry about intermediate certificates on the server side makes certificate management much easier for all parties. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jan 08, 2019 12:37 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| joebuckeye wrote: |
We discovered this during our working with Datapower and some interactions with 3rd parties.
In Datapower the Id Credentials you set up for endpoints (ie server) includes a section on Intermediate Certificates while the Validation Credentials you setup for calling endpoints (ie client) just includes certificates you trust.
IIRC, if you trust an intermediate certificate then that is where the chain ends and it doesn't go further up the chain.
|
You'd love to read my 6 month PMR with IBM DataPower where I fought to convince them IBM DataPower is in the stone ages with its TLS (SSL) implementation. Its stuck in self sign certificate design. When DataPower is the SSL Client, there is no way to ask it to do host name checking. If you only put the Root or Intermediate in the ValCred, you trust every valid certificate signed by that Root/Intermediate, whether its for the URL you called or not. Calling all men-in-the-middle!
Back and forth we went, they insisting there is no problem, just put the SSL Server's Leaf Certificate in the ValCred and do exact match. Nonsense! This is what you have to do with Self Signed Certificates. Why do I have to do this if both ends use and trust the same Certificate Authority? Does DataPower not fully and properly support a PKI? I argued no.
Similar issue on the front side, where DataPower is the SSL Server. No way for it to filter connections on values in the Distinguished Name of the SSL Client certificate from the ValCred settings. You could accomplish it in the MPG after the connection was established. But it should be configurable in the ValCred, like MQ's SSLPEER.
Whether DataPower is the SSL Server or the SSL Client, there is no way in the ValCred to control which certs you trust short of acquiring actual copies of the partner certificates to populate the ValCred and doing an exact match. Sure it works. But its a Self Signed Model. It. Does.Not.Scale. It forever marries you to the SSL Partner and requires coordination anytime they want to renew their cert. This is ridiculous for a modern piece of software.
Back and forth the PMR went. I had to prove with my traces DataPower would accept man-in-the-middle certs if all I did was include the Root/Intermediate. When I pressed them to prove it themselves, they actually told me they weren't allowed to use CA certs because they were too expensive, they have to use Self Signed Certs. No wonder the whole design works like it does.
Finally I got the PMR to the point where they said the product architects reviewed "my" requirements and agree something should be done. No commitment, but apparently something in 2019. Its so easy to fix and remain backwards compatible. Just add new optional fields to the ValCred object that allow you to filter on the DN when you are the SSL Server (like MQ' SSLPEER) or when the SSL Client to do actual hostname checking against the SAN of the SSL Server's cert to make sure the URL you call is there.
Back to IIB....
Its nice the HTTPRequestNode allows you to ask for HostName checking. Good, IIB has its act together in this reqard when its the SSL Client.
But I don't see a way (like MQ's SSLPEER) to tell the HTTPInput node to only allow SSL Client if they cert the client presents has a DN that matchs a filter we configure on the HTTPInput node, no matter how specific or loose we need that pattern to be.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
