Reduce queue manager impact when clients use expired certificate (results in denial of service)

Client connections which are using an expired SSL certificate are (correctly) refused by the queue manager. However, there is still an overhead on the queue manager side in accepting, assessing and then rejecting that connection attempt.

Further, although a message is issued to the CHIN log to indicate that this has happened, the message (CSQX658E “CSQXRESP SSL certificate has expired”) does not include detail to identify the certificate being used on the connection - the source IP address is included, but this is insufficient information in the case when all connections are routed via a network device, or are originating from a cloud-type environment where many thousands of application instances share a pool of IP addresses.

In our example, the connection attempts were from a could-type environment, and were being retried in very quick succession by multiple instances of the rogue client; the resulting traffic took the profile of a denial of service attack. While we would not want to completely block all IP addresses from which the requests originated, we need to be able to prevent the rogue application from affecting the service for other users. The same requirement would apply if the presented cert had been revoked (this logic may exist already, I've not tested this case).

This RFE has three key questions:

1. Can the channel name be added to the CSQX658E message?
2. Can some part of the presented DN be added to the CSQX658E message (or to a new, related message)
3. Can something be done to help prevent DOS when a client is using a 'bad' certificate - ie expired or revoked?