To add to what Luc-Michel says above,
SSLCIPH controls whether a channel expects encrypted communication or not. A blank value indicates you want clients (apps or queue managers) to connect with plaintext. Any other value indicates you want encrypted communication and sets what CipherSpec (or in the case of alias: Cipherspecs) are valid for clients to connect with. Any mismatch will result in a channel terminating the connection.
SSLCAUTH is what Luc-Michel says above, the communication will be encrypted with TLS so long as SSLCIPH is not blank but SSLCAUTH controls whether the connecting client has to provide a valid certificate for identity or not
- (OPTIONAL) indicates that you don't expect one, allowing anonymous connections, but if one is supplied it has to be valid.
- (REQUIRED) indicates you require one and will reject clients that do not provide a valid certificate.
Finally, CERTLABL is a special case, this is set to override what certificate your queue manager server will provide to connecting clients during the TLS handshake. It overrides the CERTLABL setting on the QMGR object. So if your queue manager is configured to present a certificate with DN "CN=QMGR" then you can use CERTLABL to change that to a different certificate
In all cases. CERTLABL and SSLCAUTH are redundant, haivng no effect, if SSLCIPH is blank.
------------------------------
Rob Parker
Security Architect, IBM MQ Distributed
IBM UK Ltd
------------------------------
Original Message:
Sent: Mon July 31, 2023 06:32 AM
From: Luc-Michel Demey
Subject: using SSL in MQ but allow also none ssl connection
SSLCAUTH(OPTIONAL) enables one-way encryption to be used, i.e. :
- the local Queue Manager has a certificate
- the remote MQ client or Queue Manager does not have a certificate
- the link is encrypted using TLS
However, in this case, the remote side must have a certificate store with the roots certificates that signed the local certificate, so that it can be verified.
------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
#IBMChampion
Original Message:
Sent: Mon July 31, 2023 06:07 AM
From: rniew
Subject: using SSL in MQ but allow also none ssl connection
Hello Luc.
So SSLCAUTH(OPTIONAL) on a CERTLABL enabled Channel, does not make sense either.
We need to discuss it with the requesting team.
Thanks!
------------------------------
rniew
IT Spe
IBM
(49171) 722-9761
Original Message:
Sent: Mon July 31, 2023 05:31 AM
From: Luc-Michel Demey
Subject: using SSL in MQ but allow also none ssl connection
hello,
Once a certificate has been assigned to the Queue Manager, TLS (SSL) is activated at channel level.
It is therefore possible to have TLS on a channel with a cipherspec 1, another with a cipherspec 2, and a third without a cipherspec.
The listening port is set at the listener level, which does not know the TLS status, so it is not possible, for example, to have SSL communications via 1515 and unencrypted communications via 1414.
However, be careful about leaving one channel non-TLS when the others are, it's a bit like having an armoured door in front of the house, and the back door on the garden side closing with a simple hook.
------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
#IBMChampion
Original Message:
Sent: Mon July 31, 2023 05:17 AM
From: rniew
Subject: using SSL in MQ but allow also none ssl connection
We need to configure SSL at queue manger level (cleint>Qmgr and qmgr > qmgr). To do so we must:
- Manage the digital certificates that are used by the queue manager.
- Configure the queue manager for SSL-enabled messaging.
- Configure channels to support secure messaging using SSL.
But we also need to allow none SSL connection through 1414.
Is it possible? Do we only need to define new channels without SSLCIPH and use those to connect?
Best regards + thanks
------------------------------
rniew
IT Spe
IBM
(49171) 722-9761
------------------------------