Im trying to use JKS ssl certificate in JMeter to authenticate to a IBM MQ connection factory. I have updated the jmeter system.properties with javax.net.ssl.keyStore and password fields with relevent entries. But it fails to connect stating
"Failed to connect to Queue Manager".
I am not able to debug it either because even though i updated the debugging in jmeter with log_level to "debug" in jmeter.properties its not displaying the necessary logs either.
I tried to use custom jndi.properties file and this is not recognized either (created a jar and stored it in lib and lib/ext folders). I have also tried to use ssl manager option of jmeter.But no luck on that either.
If anyone has configured Jmeter JMS Publisher(Not point to point) to authenticate to IBM MQ queue manager,any help would be really appreciated.
There is a tremendous amount of information missing from this question. You will need to add detail if you want a more precise answer. However, perhaps in working through my reply you will find the error and fix it. If so, please come back and update your question with the details of what you did to fix it.
You mention that you want JMeter to authenticate to MQ. There is no mention of MQ authenticating to JMeter. However there is no option to use TLS with MQ where the QMgr does not require a certificate. Therefore, you need the following:
On the QMgr side
The QMgr must have a personal certificate.
The label of the QMgr's certificate must be in a specific format or (as of v8.0) the QMgr's property needs to point to the right certificate.
If the QMgr's certificate is CA-signed, the CA's signer cert(s) must be available to the QMgr for it's own certificate.
The QMgr must have either the CA signer cert(s) for JMeter's certificate (if CA-signed) or JMeter's public certificate (if self-signed).
The QMgr's channel must specify a CipherSuite.
On the JMeter side
JMeter must have a personal certificate.
If JMeter's certificate is CA-signed, the CA's signer cert(s) must be available in the trust store.
JMeter must have either the CA signer cert(s) for the QMgr's certificate (if
CA-signed) or the QMgr's public certificate (if self-signed).
JMeter's MQ channel must specify the Cipherspec that corresponds to the CipherSuite set at the QMgr.
Of all the information I've listed here, almost none of it is available in the question as written. Someone responding has no reason to believe that the QMgr is even set up for TLS at this point. Nothing in the question indicates that this has been done. Assuming the QMgr is set up for TLS, does it work with IBM's sample programs? Again, we have no way to know from the question as written.
Please be aware though that, like any good security error, nearly all of the information is logged at the QMgr side. For example, if a login fails, the last thing you want to do is to tell the attacker that the User ID is bad or the password is bad. The error message should never provide more information for the attacker.
With this in mind, security errors on the client side tend to produce client-side error logs. Security errors on the QMgr side produce QMgr-side logs and very sparse client messages. If you follow up here, please post sufficient info for us to help diagnose the issue, including the QMgr-side error log entries.
Related
We are just starting to use google cloud data fusion for our ETL.
We have a use case to hit a server(self-signed) and get some info using the http-plugin in the data fusion product.
In my pipeline, i am turning off SSL verification to accept any certificates but getting an error
javax.net.ssl.SSLPeerUnverifiedException: Certificate for <on000120.aeo.ae.com> doesn't match any of the subject alternative names: []
Help text for the field also suggests to urn it off. See image.
Could someone please help?
I followed the instructions at https://www.freecodecamp.org/news/how-to-get-https-working-on-your-local-development-environment-in-5-minutes-7af615770eec/ to generate the key and crt files, so I had a file called v3.ext (which includes subjectAltName) and used that to generate the server.crt file. When I started my server with these files, I was able to deploy and run a pipeline using HTTP source from that local HTTPS server. How did you generate your crt and key? Would you please describe the plugins you're using?
I assume that issue that you've reported is not connected with Data Fusion runtime environment, but might be supposedly related the target HTTPS web server SSL/TLS configuration. Most of the time this issue occurs when the common name or SAN(Subject Alternative Name) of your SSL/TLS Certificate does not match the domain or address that you hit in HTTP call, hence this page is not listed in SAN's list and I can suppose that you didn't add any of domain names there.
As far as I know Data Fusion http-plugin, which is based on Java HTTP Client implementation, promotes HostnameVerifier class, that is used for URL's hostname and the server's identification hostname verification during establishing handshake between parties, you may take a look at the source code and find inherited method getDefaultHostnameVerifier() as well. Therefore, this can lead to the error, during http client intentions to launch SSL/TLS connection channel.
Even though, you turned of trust keystore certificate inspection in the plugin settings, the issue will persist because hostname validation still failing.
I'm adding Google reCaptcha v3 to my J2EE application that runs under WebSphere 6.1. (I know, its no longer supported. A software upgrade is on the plan, just not immediately.)
I've followed the steps below to add the www.google.com:443 cert to WebSphere's NodeDefaultTrustStore, and after restarting WebSphere, the SSL cert is accepted no problem. My servlet code that does the reCaptcha verify logic works fine and all is well.
However, the following day, the certificate I imported is no longer accepted. When I import it again, I see that the Fingerprint (SHA digest) is different than the previous day. It looks like Google changes their SSL cert on a daily basis. Is this true? If so, how do I get around this problem in WebSphere?
CWPKI0428I: The signer might need to be added to the local trust store.
You can use the Retrieve from port option in the administrative console to retrieve the certificate and resolve the problem.
If you determine that the request is trusted, complete the following steps:
Log into the administrative console.
Expand Security and click SSL certificate and key management.
Under Configuration settings, click Manage endpoint security configurations.
Select the appropriate outbound configuration to get to the (cell):ServerNode01Cell:(node):ServerNode01 management scope.
Under Related Items, click Key stores and certificates and click the NodeDefaultTrustStore key store.
Under Additional Properties, click Signer certificates and Retrieve From Port.
In the Host field, enter www.google.com in the host name field, enter 443 in the Port field, and www.google.com_cert in the Alias field.
Click Retrieve Signer Information.
Verify that the certificate information is for a certificate that you can trust.
Click Apply and Save.
"Retrieve from port" adds the leaf certificate. To do something more reliable, trust the issuer. The current issuer for is GlobalSign root CA R2 which you can grab from https://pki.goog/ (GS Root R2)
Unfortunately it is hard to automate grabbing the root CA in tools like "retrieve from port" because many SSL toolkits do not send the root CA over the wire during the handshake -- because the client should already have it.
Here's an approach for WebSphere Liberty that might work for 6.1, I haven't tried it.
https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_add_trust_cert.html
Use the openssl method but take the -second- certificate in the list (which doesn't expire until 2021).
Let us say, I used a queue manager QMGR1 in host1 to create a CSR and obtain a CA-verified certificate labeled ibmwebspheremqqmgr1. Can I use load the same certificate (and its root and intermediary chains) in another host host2 for the a queue managed named same (i.e. QMGR1) ? In other words, a certreq needs to be present when we 'receive' a certificate using rumqakm or no? Can we just 'add' a cert (like we do the chains)? If the question is not clear, please ask, i can provide more details. In my case host2 is production. host1 is a QA environment where we test connectivity. Thanks.
Update question from comments 26DEC16
Specific to MQ, I believe I would have to load CSR first on host2 and then receive the CER again, right? I wonder how do I 'load' the CSR without creating it. I see an option to recreate it in runmqakm, never used that before and not sure if that will work.
TL;DR: Yes.
When you create a CSR using IBM GSKit (e.g. runmqakm), the result is a certificate that is unsigned and the CSR file itself. The CSR is cryptographically bound to the unsigned certificate that remains in the .rdb file of the keystore. The signed CSR cannot be received into just any keystore at that point.
When you receive the signed CSR, it is combined with the pending unsigned certificate and moved to the .kbd file of the keystore. At this point it is a valid personal certificate with the label name you specified (ibmwebspheremqqmgr1 in this case) and the DN that you specified.
Once completed you have a usable personal certificate. If you wanted to use it on another QMgr you would need to get that certificate to that other QMgr in one of two ways:
Copy the set of files that comprise the keystore.
Export the personal certificate to a file and then import that file into the other QMgr's keystore.
If you copied the entire keystore and the other QMgr is also named QMGR1 then you can use them immediately. If the other QMgr has a different name, then you'd have to rename the certificate to something other than ibmwebspheremqqmgr1, or in a modern QMgr set the QMgr's CERTLABL attribute to ibmwebspheremqqmgr1. Generally, you want the cert label to reflect the name of the QMgr using it so a QMgr named QMGR2 with a CERTLABL of ibmwebspheremqqmgr1 is not recommended.
If you import the certificate then you can set the label during the import command.
Keep in mind, the label and the Distinguished Name are two completely different and unrelated things. The distinguished Name is the value that the CA verified and signed off over and is cryptographically bound tot he keys in the cert. It is the thing that a remote connection partner decides whether to trust or not.
The label is how the local QMgr or client finds its own certificate. Imagine you had created two personal certificates, the QMgr needs to know which one to send. It finds the correct one by matching the label of the certificate to the expected value of ibmwebspheremq[qmgr name in lower case] or against the QMgr's CERTLABL attribute if it is not blank.
This is why the certificate label can be changed easily with a GSKit command but the Distinguished Name is immutable.
With this in mind, note that external, and many internal, CAs will expect the certificate Common Name of the certificate to contain the fully-qualified hostname where the certificate will be used. HTTPS clients check that the certificate CN matches the hostname when they connect. For an MQ connection, this is not the case. You can put anything in the CN that your CA will sign and use it on a QMgr of any arbitrary name. So your certificate can have CN=QMGR1 and that QMgr can live on mqhost.yourcompany.com and MQ likes it just fine. However, clients using the new MQ REST API will not! This is an important distinction for people hoping to use the new MQ REST API.
Finally, please note that best practice is to generate the certificates where they will be used, protect them using filesystem permissions, keep them in local storage, and never copy or move them from that location. Public/Private key crypto was invented to solve the very difficult problem of securely exchanging private keys. If the personal certs are copied around it defeats the purpose of using them in the first place.
The various commercial PKI packages (i.e. IBM Tivoli Key Lifecycle Manager, Venafi, etc.) all solve this problem using FIPS-certified algorithms that don't store keys or crypto primitives on disk, securely wipe memory space before releasing it, and in general take excruciating care to not leave keys unprotected in transit, disk or memory. If you must copy personal certs around, use a real PKI package designed for that purpose if the company has one. Otherwise, export them to a .p12 with a very long and random password and avoid email, FTP, or other non-secure means of copying the file around.
I am trying to write a java application connecting to server connection channel with SSL enabled.
So far, I have been successfully connected to the channel by setting authentication to 'optional'. However, when I set it to be 'required', the connection fails.
Here is what I did:
Create key db for queue manager and keystore for the java client user.
Create key/self-signed certificates for the queue manager and the client user, with names prefixed ibmwebspheremq.
Export, exchange and import certificates for the queue manager and the client. (I did answered 'yes' when being asked whether I trust the queue manager cert).
The location and password to the truststore and keystore are set to point to the same keystore at the client side, where the orgininal created client user key and the imported queue manager key are.
With other settings being the same, if I switch back to 'optional' authentication, the connection works.
I think there is something I understand incorrectly about this ssl authenticaion but cannot figure out what.
Could someone kindly help me?
I beat my head against that wall for a couple of weeks. IBM L2 Support eventually clued me in. My issue here was that keytool will use DSA algorithm unless you specify RSA. This results in keys of length 1022 instead of 1024, which WMQ doesn't like. The fix was to specify -sigalg RSA when generating the certificate and everything works.
I've asked the IBM WMQ team and WMQ FTE team to add this to their Infocenter documentation.
I have a self-hosted service that I want to add transport security to.
I've set WSHttpBinding.SecurityMode to Transport and the ClientCredentialType to HttpClientCredentialType.None.
I've created a certificate and set it to my host with
ServiceHost.Credentials.ServiceCertificate.SetCertificate()
I've also registered it using
netsh http add sslcert ipport=127.0.0.1:80 certhash=[MyCertHash] certstorename=MY appid=[TheGuidOfTheAppTahtRunsTheService] verifyclientcertrevocation=disable
I'm getting the following error message whenever I try to call the service:
"Authentication failed because the remote party has closed the transport stream."
Does this mean the the client and server try to authenticate each other? How can I disable it?
To make things clear, I do not want to install a certificate at the client, I'm not looking for any authentication atm, just securing the messages content, if that's even possible.
This MSDN post may help solve your problem. The initial request in the post is to configure a different security mode than yours but they switch to Transport mode for troubleshooting and that info should apply to your situation.
If what you describe is all you've done to install the certificate then you're missing a few steps. The post outlines the process to get a valid certificate installed. Good luck!!
Certificates can be a pain in the ass some times to get working. First thing you should always do with WCF is turn on tracing:
http://msdn.microsoft.com/en-us/library/ms733025.aspx
Then, you can use SVCTraceViewer to view the exceptions that your service is generating behind the scenes and get a little insight into what is happening, which is a must with many WCF problems. 9 out of 10 times, the trace will tell you everything you need to know.
Also, make sure that both the client and the server have the certificate configured, since the certificate needs to be installed on both machines.
I was trying to track down this same error, and came across this post. WCF tracing doesn't help as the error appears on the client side in the HTTP stack, and on the server side the request is rejected before it ever makes it to the WCF layer.
I found that I wasn't being thorough enough. Make sure all the following conditions are met. I had some but not all of these properly set up:
The server's certificate issuer has a valid and matching issuing
trusted root CA on the same machine.
The server certificate subject name matches the machine name
exactly, and the machine name the client is accessing matches as well ("localhost" vs the server's Environment.MachineName value)
The server certificate's thumbprint
has been set by an Administrator
using the following command (use
netsh equivalent for newer versions of Windows)
httpcfg set ssl -i 0.0.0.0:{port} -h {thumbprint}
This client also has the same valid issuing root CA certificate on the client machine.
Here's a good reference: SSL with Self-hosted WCF Service.