This post describes how to set up self signed certificates to authenticate end user’s access to mqweb.
You can use self signed, which is fine for test and small environments, or use signed certificate which are suitable for production, and typical environments. Using certificates means you do not need to specify userid and password.
The userid is taken from the CN part of the subject, and this userid is used to grant access depending on the configuration in the mqwebuser.xml file.
Information about certificates used for authentication are stored in the trust store. For a CA signed certificate, you only need the CA certificates, not the individual certificates. With self signed, you need a copy of the individual self signed certificate in the mqweb trust store.
Create the trust store if required.
/opt/mqm/bin/runmqckm -keydb -create -db trust.jks -pw zpassword -type jks
You need to do this once.
Create the self signed certificate for the end user
openssl req -x509 -config openssl-client2.cnf -newkey rsa:2048 -out testuser.pem -keyout testuser.key.pem -subj “/C=GB/O=aaaa/CN=testuser” -extensions ss_extensions -passin file:password.file -passout file:password.file
- openssl req -x509 –x509 makes this a self signed request
- -config openssl-client2.cnf – use this config file
- -newkey rsa:2048 – create a new private key with 2048 bits rsa key
- -out testuser.pem – put the request in this file
- -outform PEM – with this format
- -keyout testuser.key.pem – put the key in this file
- -subj “/C=GB/O=aaaa/CN=testuser” – this is the DN. The CN= is the userid used by mqweb to determine the role. It must match the case of userid
- -extensions ss_extensions – see below
- -passin file:password.file -passout file:password.file – passwords are in this file
[ ss_extensions ] subjectKeyIdentifier = hash #Note: there is a bug in Chrome where it does # not accept certificates if basicConstraints # is specified # basicConstraints = CA:false subjectAltName = DNS:localhost, IP:127.0.0.1 nsComment = "OpenSSL Self signed Client" keyUsage = critical, keyEncipherment extendedKeyUsage = critical, clientAuth
Create an intermediate pkcs12 keystore so it can be imported to your browser.
You need to import the certificate and private key into the browser’s keystore. The only way I found of doing this was via an intermediate pkcs12 keystore (with extension .p12). If you import the certificate and key from the web browser, it will expect a .p12 file.
openssl pkcs12 -export -in testuser.pem -inkey testuser.key.pem -out testuser.p12 -name “testuser” -passin file:password.file -passout file:password.file
- openssl pkcs12 – request to process a pkcs12 keystore
- -export – to create it
- -inkey testuser.key.pem – this private key
- -in testuser.pem – this certificate returned from the CA
- -out ssks.p12 – the name of the key store which is created
- -name testuser – create this name in the keystore
- -passout file:password.file -passin file:password.file – use these passwords
Import the intermediate keystore into the trust store
/opt/mqm/bin/runmqckm -cert -import -target trust.jks -target_type jks -file testuser.p12 -label testuser -pw password -target_pw zpassword
- /opt/mqm/bin/runmqckm – run this command
- -cert – we want to process a certificate
- -import – w want to import a file
- -target trust.jks – this is the mqweb trust store
- -target_type jks – it is a jks store
- -file testuser.p12 – input file
- -label testuser – this is the label in the trust.jks keystore
- -pw password – the password of the testuser.p12
- -target_pw zpassword – the password of the trust.jks keystore
In the message.log I had
E CWPKI0022E: SSL HANDSHAKE FAILURE: A signer with SubjectDN CN=testuser, O=aaaa, C=GB was sent from the target host. The signer might need to be added to local trust store /home/colinpaice/ssl/ssl2/trust.jks, located in SSL configuration alias defaultSSLConfig. The extended error message from the SSL handshake exception is: PKIX path validation failed: java.security.cert.CertPathValidatorException: The certificate issued by CN=testuser, O=aaaa, C=GB is not trusted; internal cause is:
java.security.cert.CertPathValidatorException: Certificate chaining error
When I restarted mqweb and the certificate was accepted.
I had the same message when I did not import the certificate into the trust store.
Import the temporary keystore into the Chrome keystore
pk12util -i testuser.p12 -d sql:/home/colinpaice/snap/chromium/986/.pki/nssdb/ -W password
- pk12util – this command
- -i testuser.p12 – from this keystore
- -d sql:/home/colinpaice/snap/chromium/971/.pki/nssdb/ – into this key store
- -W password – using this password (for the temporary .p12 file)
Remove the intermediate file
Update the mqweb configuration
<webAppSecurity allowFailOverToBasicAuth="false" /> <keyStore id="defaultKeyStore" location="/home/colinpaice/ssl/ssl2/mqweb.p12" type="pkcs12" password="password"/> <keyStore id="defaultTrustStore" location="/home/colinpaice/ssl/ssl2/trust.jks" type="JKS" password="password"/> <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" serverKeyAlias="mqweb" trustStoreRef="defaultTrustStore" sslProtocol="TLSv1.2" clientAuthentication="true" clientAuthenticationSupported="true" />
You need to restart mqweb so it picks up any changes to the trust store.
No messages are produced in /var/mqm/web/installations/Installation1/servers/mqweb/logs/messages.log if the trust store was opened successfully.
Use a command like grep ” E ” messages.log and check for messages like
CWPKI0033E: The keystore located at /home/colinpaice/ssl/ssl2/trust.jks did not load because of the following error: Keystore was tampered with, or password was incorrect
Try using it in Chrome
You need to restart Chrome to pick up the changes to its keystore. Use the url chrome://restart/
Use the url chrome://settings/certificates , to check your certificate is present under “Your certificates”. If not use url chrome://version to display the profile being used, and that it matches the store used in the pk12util command above.
Try connecting to mqweb using a url like https://127.0.0.1:9443/ibmmq/console/ .
You should be logged on with no password request. In the top right hand corner of the screen you should have a black circle with a white “i” in it. This shows you are logged on with certificates.