Currently I am having a problem connecting to the server due to the following issue:
When I tried to connect to the server, it returned an error: MQRC_SSL_INITIALIZATION_ERROR
Upon closer analysis via WireShark, I found that the Client is attempting to connect to the server using SSL v2, while the server can only accept SSL V3, thus rejecting the connection.
I checked through the document, but am not able to find any information on
what SSL version the .Net client supports.
I would like to check whether the SSL version is controlled from the .Net MQ
client, and if so, how can we configure to make it connect via SSL v3?
Thanks.
I'm not sure I agree with your conclusion since WMQ has supported SSL V3.0 and TLS V1.0 since at least V6.0 and possibly earlier. This is more likely a mismatch of configurations between the client and server. The procedure I recommend to resolve SSL/TLS issues is as follows:
My method for debugging SSL connections on WMQ is to progress through the following sequence making sure each step works before advancing to the next:
Get the channel running without SSL. This validates that the channel names are spelled correctly, that a network route exists between the endpoints, that the QMgr's listener is running and that the client points to the right port. You'd be surprised how many times someone mis-keys a port or channel name.
Get the channel running with the SVRCONN definition set to SSLCAUTH(OPTIONAL). This performs an anonymous SSL connection similar to what your browser does. The QMgr presents a certificate to the client but the client is not obligated to send one back. This validates that the QMgr can find its certificate and that the client can find its trust store and properly validates the QMgr's cert. (Note: the QMgr will always request the client cert and the client will always send it if one is present. To perform this test, use a copy of the client's keystore that has the signer cert(s) but not the application's personal cert. Copy the keystore and delete the personal cert from the copy. Do NOT delete the original!)
Set the SVRCONN channel to SSLCAUTH(REQUIRED). This now requires the client to find its keystore (in the last step it required only its trust store) and to be able to find its certificate. It also requires the QMgr to be able to validate the client's cert.
Set up SSLPEER or CHLAUTH mapping rules to narrow the population of validated certificates that will be accepted on the channel.
The difference between steps #2 and #3 helps to isolate the problem by testing the SSL credential exchange in only one direction at a time. This allows you to identify whether the problem exists in the personal cert or the public cert and on which side of the channel. Nearly all problems are sorted out in these two steps.
UPDATE
Notes to respond to questions. There are two types of certificate used with SSL/TLS. The personal certificate contains the private key and is the one that doesn't get passed around. The public certificate is the one that contains the public key and can be given out freely. The private key is held in a keystore. The public keys (usually these are the CA's root and intermediate certs) are stored in a trust store. In some cases, these are separate files. For example, in Java and JMS the JSSE provider looks in the environment for variables that point to the keystore and to the trust store. It is possible in Java and JMS that the keystore and trust store variables point to the same file.
In the case of WebSphere MQ servers and clients other than Java, the keystore and trust store are combined into a single location. Often referred to as a kdb file, it is actually a CMS key database comprised of several files of which one is the KDB. In this case "keystore" is actually shorthand for a combined keystore and trust store. For the .Net client, set the keystore location and other SSL properties in the MQEnviornment.
In the SSL/TLS handshake, the server always sends its public certificate in response to a connections request. The client then must validate that certificate by first checking the signature and validity date, then looking in its trust store for the thing that signed the certificate. If the thing that signed the certificate is an intermediate signer cert (it has itself been signed by something) then the search continues up the signer cert chain until the root cert is reached. Assuming that the server is authenticated, the same procedure is applied in reverse by having the client present a cert and the server validating it.
When the process fails in Step #2 we can debug using knowledge of the process above. The QMgr must first find its cert in its keystore and present it to the client. If the QMgr cannot find its cert, the result is errors in the AMQERR01.LOG file stating this. Always look on the QMgr side first when things die in Step #2!
If the QMgr does find its cert then the next step is that client must be able to find its trust store and then within that trust store must find the necessary signer cert chain. If this fails, there should be errors on the client side to indicate that. For example, a common error when setting the client environment is to specify the entire file name, including the .kdb extension. When this happens the QMgr looks for [keystorename].kdb.kdb which doesn't exist. Another common error is that the personal certificate exists in the keystore but with the wrong label. Non-Java WMQ clients look for the certificate by label name constructed from the literal string ibmwebspheremq followed by the user ID in lower case. For example, if my user ID is TRob then my certificate label would be ibmwebspheremqtrob. Note that this is the certificate's label in the keystore and NOT the certificates Common Name or other field in the Distinguished Name.
Depending on the type of client in use, these may be in the Windows error log, local MQ error logs or other location. If you can't find client-side errors, WMQ tracing is also an option.
Related
For normal TLS the client will check that the server I am communicating with is actually on the FQDN matching the CN, hence if the certificate is for a different domain the TLS should not work by default as the certificate is not for this site.
For mTLS when the server is checking the client certificate, can it somehow check the client address matches the CN somehow or is it simply checking the cert matches the key and cert is trusted on the client side? ie if I use the correct client key/cert from any machine on the internet should the server connect if its configured to trust that certificate, or will it require the client to be somehow at specific address?
It depends on the specific use case.
In some cases mTLS is used in server to server to communication, for example with SIP (VoIP). In these cases the client certificate is often expected to contain the domain of the sender, similar to a server certificate. Keeping with the example of SIP: here the different systems can also switch roles (i.e. both sites can initiate a call) and what was former the client certificate is now used as a server certificate.
In other cases the subject is not validated during the TLS handshake but the users identity is extracted from the certificates subject and provided to the application. The application might then do additional checks, like allowing only users from a specific organisation encoded in the subject. Thus, the subject is still relevant even if it is not used inside the certificate validation during the TLS handshake.
Situation: we can't update der file on the client's device. And the SSL certificate on our web server expires soon.
Is it possible to renew the server's SSL certificate without replacing the client's certificate?
We want to follow this guide: https://www.smashingmagazine.com/how-to-issue-a-new-ssl-certificate-with-an-old-ssl-key/
However, we are not sure if it helps.
The question is:
Does the der file (on the client side) contain only public key and it is safe to renew SSL certificate using the technique described in the link above (keeping same pub/private keys).
Will it work on client's device without replacing der file? Or der file contains not only the public key for SSL certificate but also some other information?
I'm afraid, but based on your original post and clarifications, client will expect from web server the same server certificate as stored in DER file on client device. Client performs exact binary copy comparison (not only public keys).
Any attempts to replace server certificate will result in a connection failure on client. If you plan to replace the certificate on web server, you will have to update client devices as well.
Unfortunately, there are a lot of flawed HPKP implementations (to be honest, didn't see any reliable implementation) that work fine until server certificate is changed. In order to properly handle server certificate replacement, client MUST be able to store at least two server certificates, existing and new one. Here is the high-level server certificate replacement process:
acquire new server certificate from CA in advance.
make application update by including new certificate side-by-side. When client updates the application on their device, client app will trust both, existing and new certificate.
give clients a time to make app update on their devices. Ideally, you should wait until all clients have updated app version with updated certificate.
change SSL certificate in server bindings.
after aa time you can make another update for client certificate by removing expired certificate from trust store.
only this step sequence may guarantee uninterrupted certificate pinning renewal.
I'm have an application deployed to salesforce on the force.com platform,
which I'm trying to configure a 2 way SSL for.
I.e.
I want that for each request sent to from SF to my server, a client certificate will be sent.
I did the necessary configurations on SF for the certificate to be sent, but I'm still getting 403.7 from the server, which means: forbidden, client certificate required.
I installed wireshark on the server, captured traffic to see the 2 way ssl handshake, and I'm trying to find in the server hello message where it tells the client the trusted CAs from which a client certificate should correspond, but I'm having difficulties finding it.
I suspect that's why the client does not send the certificate.
Can anyone point me to where in the server hello I should look? Or perhaps in another packet capture?
Thanks in advance.
Client Key Exchange record:
Here, the server sends its Certificate Request message and the client sends its Certificate message in response, but that message contains 0 certificates.
Typically, this happens when the client was unable to select a client certificate to use. Either it's not configured properly to make use of any certificate, or it can't find one that is issued by one of the acceptable CAs.
Look at the Certificate Request packet and check its certificate_authorities list. This is a list of the CA Distinguished Names (DNs) that the server is willing to accept.
One way or another, the client will need to find a client certificate with which it can build a chain towards of those DNs. In the simplest case, a client certificate issued by such a DN is available. Otherwise, the client could have to build a chain from a client cert to such a DN, it would need to have the necessary intermediate CA certificates to do so. (How this is done depends on the client's configuration mechanisms.)
If intermediate CA certificates are necessary and not available on the client side, you may need to configure your server to accept them and advertise them in the Certificate Request too.
Added a screenshot of the handshake captures. can you please point me to where I should be looking? –
See packet #31. It contains the Certificate Request. Also packet #33 contains the certificate from the client, so the reason is not the client does not send the certificate, but instead that the server either does not like the certificate because the validation failed or because the certificate is not sufficient as authorization for the requested resource. You might get more information from the servers log.
Not sure if this will help anyone else, but for our case of this issue everything was working when running locally in Visual Studio and in IIS, but when deployed to a real server, we were hitting a certificate issue during 2-way SSL as described above and verified in Wireshark.
Anyway, on that server we have also have a .NET 4.7.2 Console application which was calling the same API and everything was working fine.
But, our .NET 4.7.2 web API calls were failing. It appears that when the same code was running inside IIS the cert was not available during the SSL negotiation. (although it loaded fine)
Our solution at this point was to modify the following call to include the 3rd parameter.
certificate = new X509Certificate2(certificatepath, Password, X509KeyStorageFlags.MachineKeySet);
By default X509Certificate2 uses the UserKeySet option, so perhaps the application pool user or another thread in IIS (?) was having trouble accessing the cert for the negotiation.
Here are a couple of the related pages that I found useful during my research:
https://paulstovell.com/x509certificate2/
https://github.com/dotnet/runtime/issues/23437
I am tring to figure out how a secure connection between client and server is established. I tried the SSL example provided by boost::asio library. My question is about the certifacte used by client and server. To be specific, I generated a private key(mykey.pem). Then I used this private key to generate a self-signed certificate(mycert.pem) and I used these files as follow:
Server side:
1)context_.use_certificate_chain_file("mycert.pem", error);
context_.use_private_key_file("mykey.pem", boost::asio::ssl::context::pem, error);
context_.use_tmp_dh_file("dHParam.pem",error);
Client side:
2)ctx.load_verify_file("mycert.pem",error);
With this code the handshake is done perfectly. My question is that how come both the server and client use the same certificate ("mycert.pem") in commands 1 and 2? With this approach a client can pretend to be a server easily.right? Do you think that I missed something here?
The certificate is public information.
It's the private key that allows the entity to prove its identity. The client is guaranteed by the SSL/TLS handshake that only the party with the private key matching the public key in the server certificate can be at the other end with the suitable master secret, so as to be able to decipher the communication. The problem it addresses is whether or not the remote party is indeed the one to which the certificate was issued. (This is similar to checking that the picture on the photo ID matches the person in front of you.)
Configuration of the certificate (and not the private key) on the client side is there to tell it which certificates you are willing to trust. The problem it addresses is whether or not to trust what the certificate say (in particular what it says about the identity of the server). This is normally done using a PKI, so as to build trust via 3rd parties (the CAs). (This is similar to checking that the photo ID itself is genuine, and that you can trust what it says.)
What you've done by trusting this specific server certificate is bypass the use of CAs to make an exception and indicate you were willing to trust this particular certificate to be genuine. (This is fine for a handful of certificates, but using a CA allows your trust structure to be more manageable and add other features, such as the ability to revoke certificates.)
I am working on a website that exposes an xml gateway that clients can submit an xml request to and get an xml response in return. The website/company has been purchased by a larger organization and has been migrated into their infrastructure. The existing production site is using an ssl certificate by a particular certificate authority but the larger organization uses certificates issued by a different certificate authority. We have tried run a test with one of their clients and they are getting an SSL handshake error. The original developer says that the only way to get it to work is to restore the original SSL certificate and not to use the new ones. I am looking for some guidance or direction to diagnose this issue, so any help would be appreciated.
What the developer says, from the description is sensible to me, but the problem is theirs.
To verify that this is exactly what is happening you can do a wireshark capture and then decode the flow as SSL. If the problem is that the client do not trust the certificate send by the server and reject the connection you will see it in the handshake in the wireshark.
If you use a java client you could run it with -Djavax.net.debug=ssl to see the ssl messages from within java.
If this is indeed the problem then you must configure the client's truststore to have the certificate send by the server (which is the original one).
If this configuration is possible of course... This depends on the application
UPDATE:
Well if you migrated to a new CA, i.e. you deploy a new certificate in your interface, then sorry to say, it is "your" -meaning the server side- error.
IMHO, if it is possible, you should redeploy the old certificate for a prespecified period, communicating to all the stakeholders that you plan to migrate to a new certificate signed by a new CA, so that the clients don't break
Then it is their responsibility, within that period, to "fix" their client apps to be able to accept the new certificate. This can be as simple as configuration i.e. importing the certificate to a truststore, to as "complicated" as to change code and rebuild the client app (e.g. if the new issued certificate does not have extensions that the code is verifying or the CN has changed etc).
If it is not possible to redeploy the old certificate then, you just have to communicate the change to all stakeholders and then, they should "fix" it accordingly (as mentioned above)