SSL certificates are stored in SSL key repositories. The SSLKEYR attribute of the queue manager identifies which key repository to use – giving the path of the key repository file. But the key repository can hold several certificates, so we identify which certificate to use for which queue manager or client using the certificates’ label names.

For queue managers, the certificate label name should be ibmwebspheremq with the queue manager name (converted to lower-case) appended.

For clients, the certificate label name should be ibmwebspheremq with the name of the user who runs the client (converted to lower-case) appended.

There we go – easy. Except that’s not all there is to it. There is an exception. This post is a discussion of that exception, how it came to happen, and a discussion on whether it’s a good idea or not.

Background

WebSphere MQ uses GSkit libraries to provide SSL support, and GSkit commands for SSL administration. GSkit isn’t a WMQ-specific thing – it’s a package which is included with many IBM products. This means we inherit all sorts of stuff that aren’t necessarily needed for WMQ.

Default certificates

For example, GSKit allows for one certificate in every key repository to be marked as the default certificate. And the GSkit commands includes a -setdefault switch to identify which certificate is the default one.

When searching for a certificate with a given label name, the default behaviour for GSkit library commands is that (if such a certificate is not found), the default certificate is returned and used instead.

This meant that you didn’t need to specify an SSL certificate label for WMQ – you could mark the certificate as default, and it would be used instead.

A brief history of default certificates in WebSphere MQ

This was not intentional. When identified it was classified as a defect, and this was corrected in APAR IC43762. If we don’t find the certificate with the right label, we stop – and the connection fails.

So the hole was plugged and the story ended there, right?

Wrong.

It turned out that some customers had noticed the default certificate behaviour and were using it in earnest. “Correcting this defect” broke their setup – they had no certificates labelled with ‘ibmwebspheremq…’ and were relying on default certificates to be used. And now they weren’t.

So, the original behaviour was restored (in APAR IC50156), albeit wrapped in an environment variable (AMQ_SSL_ALLOW_DEFAULT_CERT) so people could no longer do this by accident.

The case against

And that’s where we’re at today. If you really want to, you don’t need to specify certificate labels. But – in my opinion – you really should. Default certificates are a bad idea.

By breaking the link between the user who runs a client, and the certificate that they are allowed to use to identify themselves, you introduce the risk of other users running a client with falsified credentials. A user who shouldn’t be allowed to connect to a queue manager just needs to get on to a machine where a key repository with a default certificate is stored, and they can use that certificate to get access. It wouldn’t matter who they are – they can run a client and if no certificate was found for them, the default would be used instead.

Worse still, with default certificates a queue manager administrator could:

  • Create one key repository
  • Create one personal certificate in that key repository and make it default
  • Give that key repository file to everyone who wants to connect to their queue manager – let every client and every other queue manager use the same certificate

On the plus side, they only need to worry about authorising one certificate to be able to connect to their queue manager. But on the down side, they’re only authorising one certificate! The point of the SSL certificate is to uniquely identify something. Anything that encourages reuse and sharing of certificates detracts from that aim – if such a shared certificate and it’s private key was to be compromised, their whole network would be exposed. If you can’t identify who is who or verify from whom data is originating, then you lose control of the security of your network.

If the main incentive is ease of administration (say that you have a large number of clients, all requiring a certificate) then there are better ways to manage this. Distribute the work – the ability to establish a chain of trust from a trusted signer down to individual certificates allows for some of this administration to be delegated, so all the certificates for all of your clients don’t need to be created in one place by one person. And this avoids the need for everyone to share the same credentials. After all, isn’t it the equivalent of saying that giving a different username and password to everyone is too difficult, so why don’t we all use the same userid?

If authentication isn’t why you are using SSL – you don’t care who is who but you need data to be encrypted – then there are other ways to accomplish this, too. The channel attribute SSLCAUTH can let you specify that authentication isn’t required for incoming connections, without the need for default certificates.

The case for

I could, of course, be completely wrong. I’ve never been responsible for the administration of a large network, so I have only a theoretical knowledge of what it is like.

My first argument – about the risk of fraudulent use of default certificates – isn’t without holes. It relies on the user being able to access the key repository with the default certificate in. Administrators concerned with security also need to ensure that only users who need access to the queue manager have read-access to SSL key repository files. This would avoid the sort of abuse that I identified.

SSL certificate administration is only one part of security, and can’t be considered a solution on it’s own. Once a user connects, there still remains a number of other ways to protect a queue manager – standard MQI permissions checks, channel security exits, API crossing exits, additional OAM Authorization Service components, not to mention non-WebSphere MQ approaches like firewalls and other network configurations. As a part of a whole, carefully considered approach to queue manager security, it is perhaps a little sweeping to write off default certificates are “a bad thing”.

The rest of my argument mainly focused on the worst case (although quite real!) scenario of wide sharing and reuse of certificates. And this is still, in my opinion, a bad idea. But, although default certificates make this easier to do, they don’t require it – so perhaps I was setting up a bit of a straw man there.

What do you think?

What do people think? Are default certificates a good thing? Support for them is still there – just set AMQ_SSL_ALLOW_DEFAULT_CERT=1 in the environment of your SSL client or queue manager, and you can use it.

But should you?


Note 1: This topic was covered in a Technote last year, and some of the text in this post was nicked from there. But I helped write the Technote, so I’m happy plagiarizing myself! 🙂

That said, my rant is my own, and the Technote covers the formal statement on this topic from IBM. The Technote can be found here.

Note 2: The discussion here does not apply to Windows systems running WebSphere MQ v5.3 – which use a different approach for SSL administration.

Note 3: The discussion here also does not apply to Java and JMS clients, as these do not use labels to identify certificates to use.

Note 4: The maintenance levels at which support for default certificates was removed and then later restored are documented in the Technote mentioned above.

Advertisements