Brain check and reset, needed for AMS keystores on midrange.

I was working with AMS between midrange and z/OS and could not get my head around key store set up. The concept was relatively easy – it was the practice that made my head hurt.

I was reminded of a conversation with someone from MQ midrange development over the number of users that MQ should support, and whether a linked list, or binary tree would be better. The midrange guy said linked list would be OK, and easier to implement, I said a linked list would not scale. We had a break, and went for a coffee. I asked him “what do you call a large number of userids?” He replied “about 100”. “Ah, I see the problem. On z/OS 1000 is a small number of userids, and 100,000 is a large number of userids”. We then agreed the problem was too hard to solve.

I have the same sort of problem with AMS keystores. If you have 1000 client machines using MQ AMS, how do you keep the key store up to date? If someone joins the department, then the userid cannot use AMS until all of the key stores have been updated to include the userid’s public certificate.

Other applications using TLS and encryption have a key store to contain just your user’s private key information, and a trust store containing the public keys of users, or Certificate Authority (certificates you trust).
The theory being you create someone’s private key, once only, and the file with public keys can be downloaded whenever it changes, as part of the enterprise refresh of machines (think Microsoft updates which gets pushed to machines).

With AMS, there is a weakness, that only one key store is used which contains both the private, and the public keys. It is now harder to keep the key store current.

You cannot just download a key store for every one to use, as it would have all the private keys in it. (I could then use your private key, and pretend to be you.)

I had problems trying to come up with a process for updating all of the key stores, adding new certificates, and removing unwanted ones. This is where my brain had problems trying to find a solution. I gave up for the evening, and came back next morning when my brain had had a wake-up reset, and I could see a solution.

You download the public certificates file whenever there are update to it, then, on the client machine, you import the private key to this key store, rename the files ( current to old, new to current), restart the client, and then delete the old key store. This should be a simple process to implement.

If you allow a day for the change management process to approve the change to the key store, overnight download of the change, and a restart of the client at start of day, you should be able to get a change implemented in a couple of days!

Of course it is not that simple, as you have the .cms key stores used by C applications, and the Java keystores used by Java applications – so you have to worry about two keystores! But this is just a SMOP (a Small Matter Of Programming).

Other AMS blog posts

4 thoughts on “Brain check and reset, needed for AMS keystores on midrange.

  1. If someone new joins then they get a new personal certificate issued by the corporate CA signer authority. The signer for that CA will be already in all the truststores needed. It would be very odd to use self-signed certs or to add every users public key instead of using conventional PKI with a signer cert issued by an trusted CA. No updates to the QM keystores are needed when new users (or new MQ clients) join.


    1. Hello Peter.

      Thanks for your comment on my blog post.

      During a TLS handshake the backend system only needs the CA of the signer. The backend does a checksum of the certificate and uses the CA’s public certificate to encrypt it. If this is the same as the value in the certificate, then the certificate is trusted. All the back end needs is the CA. So in this situation you are correct. All this requires a conversation, synchronous delivery.

      If I want to encrypt a payload just for you, using asynchronous delivery, like AMS does. I need to use your public certificate to encrypt the key. You then take the encrypted payload, decrypt the key using your private key, then use the decrypted information as the symmetric key unlock the payload.
      There is no handshake, it is send a parcel to you.



      In this case I need to have the public certificate of all the people I am going to send it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s