Author |
Message
|
zpat |
Posted: Mon Mar 14, 2022 7:13 am Post subject: MQ AMS and existing certificates |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Our MQ infrastructure means that each MQ client already has a certificate issued by our own CA.
Clients might be C based or Java/JMS based. Typically Linux hosted.
Our MQ QMs likewise have a certificate issued by our own CA.
QMs in this case are mainly z/OS based (but might be distributed).
Let's assume MQ v9.0 or higher will be used.
The keystores (or keyrings) will hold both one "personal" certificate and the internal CA signer certificates (trusted signers).
So far so good, so we can use TLS 1.2 on all MQ channels internally.
Now we want some applications to use AMS to either sign or encrypt messages on certain queues, between client app A and client app B.
Do we need to obtain more certificates to do this? Or can we re-use the certificates we already have?
Is there an idiots guide or presentation on this anywhere please?
Am I right to think that the QM cert is not involved with this AMS aspect since both ends are client applications? _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
hughson |
Posted: Mon Mar 14, 2022 8:13 pm Post subject: Re: MQ AMS and existing certificates |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
zpat wrote: |
Now we want some applications to use AMS to either sign or encrypt messages on certain queues, between client app A and client app B.
Do we need to obtain more certificates to do this? Or can we re-use the certificates we already have? |
No - you can use the same ones, but you will have to put client app A's certificate into client app B's keystore and vice versa - no certificate delivery efficiency gained from CA certificates here because no "handshake".
zpat wrote: |
Am I right to think that the QM cert is not involved with this AMS aspect since both ends are client applications? |
You are correct.
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
zpat |
Posted: Mon Mar 14, 2022 11:27 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Thanks.
OK, so they need to add each other's personal certificates into their keystores.
It that a simple case of "export" and "import" using the MQ key management tool?
I get confused about exporting/importing private/public keys.
Of course we will need to renew the certs everywhere as well - another dimension to worry about.
How does one enable AMS on a MQ client application? Is it automatic if the queue in question has a policy set up? _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
hughson |
Posted: Tue Mar 15, 2022 1:26 am Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
zpat wrote: |
How does one enable AMS on a MQ client application? Is it automatic if the queue in question has a policy set up? |
You may find the following tutorials in the IBM Docs helpful in this regard, User scenarios for AMS.
There is a Windows and Unix Quick start and a Java Quick start. It should cover all you need, including enabling AMS on the client and the "extract" and "add" commands you need for the certificates.
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
zpat |
Posted: Wed Apr 06, 2022 6:11 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Yes, this is a key paragraph
Quote: |
Share the certificates between the two key databases so that each user can successfully identify the other. This is done by extracting each user's public certificate to a file, which is then added to the other user's key database.
Note: Take care to use the extract option, and not the export option. Extract gets the user's public key, whereas export gets both the public and private key. Using export by mistake would completely compromise your application, by passing on its private key. |
I had someone trying to tell me that we needed different certificates (from our normal MQ client ones) for AMS because the other end had to hold the sender's cert. However that is missing the point of PKI entirely.
However the KC examples are using self-signed certificates. My question is about using AMS with CA signed certificates.
Is it still necessary to extract the public key from the personal cert or is the CA signer cert all that is needed at the recipient end?
If the latter - what stops anyone with the CA signer cert reading the message? _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
hughson |
Posted: Thu Apr 07, 2022 8:00 pm Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
zpat wrote: |
Is it still necessary to extract the public key from the personal cert or is the CA signer cert all that is needed at the recipient end? |
The CA signer cert plays no part in AMS encryption at all.
The public key is needed for the specific DN in the policy in order to encrypt the message so that only the owner of that matching private key can decrypt.
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
zpat |
Posted: Fri Apr 08, 2022 8:31 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
OK, I thought PKI meant encrypt with private key and decrypt with public key (like web pages).
But you are saying encrypt with the public key of the recipient and then they can decrypt with their private key.
What happens if a AMS message is allowed to be read by multiple recipients?
It's slightly unfortunate that all the examples I can find use self-signed certificates.
We seem to be on the verge of adopting AMS for a number of reasons (including use of cloud hosting) and the subsequent key/cert management has the potential to become a nightmare.
I am hoping we can use our existing (Internal CA issued) certs, but it sounds like at cert renewal time it will mean updating copies of their public keys all over the place.
In a 24x7 environment with large numbers of customers, that is quite daunting - when do I retire again?  _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Apr 08, 2022 8:59 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
zpat wrote: |
OK, I thought PKI meant encrypt with private key and decrypt with public key (like web pages).
But you are saying encrypt with the public key of the recipient and then they can decrypt with their private key.
What happens if a AMS message is allowed to be read by multiple recipients?
It's slightly unfortunate that all the examples I can find use self-signed certificates.
We seem to be on the verge of adopting AMS for a number of reasons (including use of cloud hosting) and the subsequent key/cert management has the potential to become a nightmare.
I am hoping we can use our existing (Internal CA issued) certs, but it sounds like at cert renewal time it will mean updating copies of their public keys all over the place.
In a 24x7 environment with large numbers of customers, that is quite daunting - when do I retire again?  |
Same as when you have a list of selfsigned certs. The system uses (I believe a DH algo) to go over all keys and then encrypts the message with the resulting key. This means that all recipients can decrypt...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
zpat |
Posted: Fri Apr 08, 2022 12:24 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Clever stuff.
Not sure if I should view the resulting application keystore maintenance as a nightmare or as "job security".
It's not so bad on distributed as they give MQ admins free rein on those platforms, but on Ye Olde mainframes we have to ask security nicely for keyring changes at some ungodly hour of the night.
 _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
|