When connecting to an SSL enabled queue manager using C#, what values do I need to set to get the queues to work?
I currently get this error:
Reason Code: 2393
MQRC_SSL_INITIALIZATION_ERROR
In my code I am setting the MQEnvironment.SSLKeyRepository and MQEnvironment.SSLCipherSpec
Is there something else I need to set with C# to make this work? I have seen some Java examples that set keystore passwords and types and things.
I have also seen examples setting system environment variables too, but that hasn't seemed to make any difference either.
The general pattern for debugging WMQ SSL is as follows...
Get the application to connect using no SSL. This eliminates problems with connectivity, wrong queue or queue manager names, etc.
Get SSL working with server-only authentication. This means setting SSLCAUTH(OPTIONAL) on the SVRCONN channel. The QMgr will present a certificate that the application must trust but the application does not need to authenticate back to the server. This validates that both the application and the QMgr can access their keystores and that the QMgr's certificate or CA chain are properly loaded in the app's keystore.
Finally, set SSLCAUTH(REQUIRED) in the SVRCONN channel so that the application authenticates back to the QMgr. At this point the only possible problems are that the QMgr doesn't trust the app's cert or CA.
If the connection attempt is refused by the QMgr, the errors at the client will purposely be cryptic. The detailed messages will be found in the QMgr's AMQERR??.LOG files. If the failure is at the client, these messages will be found in the client's error logs or you can enable trace.
Enable trace using the strmqtrc command and stop it with endmqtrc. The WMQ Clients manual has a section describing where client trace files end up and another section dedicated to tracing on Windows in general. This can be very useful in determining client-side configuration problems such as failing to find a private key, failing to find a keystore, etc.
In your case, the 2393 indicates that something in the client configuration is failing. Since you are no longer getting the error with the keystore password, I'm guessing it may be having problems finding a private key or not trusting the cert provided by the QMgr. In the first case, setting SSLCAUTH(OPTIONAL) will work because the client' won't need it's private key. However if the problem is trusting the QMgr or other configuration issues, SSLCAUTH(OPTIONAL) won't help but tracing should sort that out.
Incidentally, the need to trace and diagnose on the client side is why IBM does not support client installations where the jars or libs were copied over rather than running the full client install. Although you can get the client to run by copying a few lib files and classes, this does not provide all the facilities for tracing and diagnostics. If you have not performed a full client install, some of what I've described here will not be possible. If that is the case, download and install the client from SupportPac MQC7.
Related
I have an multi layered application that I have developed. I communicate with the windows service using http with ServiceStack (AppHostHttpListenerBase). While this works fine in clean environments, I often find that customers computers are not so clean and one of the first problem areas is the introduction of an unwanted Proxy with causes my application not to run. I get alot of bad press that the application does not work well, when in reality it is a result of a hidden issue on the customer machine.
When I go to query my endpoints the proxy interferes and I lose all communications with the Service.
I am thinking of going back to WCF and using namedpipes but before I do so, wondered if there was a better way in the ServiceStack world (Which I absolutely love)
Ideas? Suggestions?
If a local HTTP proxy is causing issues one thing you could try is to use SSL which will let you tunnel your traffic as an opaque binary through their proxy minimizing potential for interference.
Configuring SSL for HttpListener is configured the same way for all HttpListener's, i.e. it's not specific to ServiceStack - and it needs to be configured on the OS where it's run.
This answer shows how to configure SSL on Windows: https://stackoverflow.com/a/11457719/85785
You'll be able to use https with ServiceStack HttpListener self-host by following the steps above, I used "https://*:8443/" for the url and "CN=localhost" to bypass the SSL browser warning dialog.
It's not specifically clear in the answer but you can get the Thumbprint from the details tab of the certificate where you then need to remove spaces. If it's easier, you can follow the walkthrough in the answer below to use MMC to import the certificate: https://stackoverflow.com/a/33905011/85785
I'm using Renci.SSHNet to establish a connection to SFTP servers. I've done so without any problems but I've recently ran into a server to which I can´t establish a connection through my code.
I keep getting the following error:
No suitable authentication method found to complete authentication
(publickey,keyboard-interactive).
The thing is, I know the host, user and password are correct as I can establish a connection using FileZilla. I've noticed while connecting to other servers using FileZilla that the fingerprints for the ones I can also connect to with my code are generated through RSA as opposed to the one that is giving me trouble, which is SHA2.
TL/DR: What I'm wondering is: is the Renci.SshNet.SFTP library compatible with sha-2 generated fingerprints or will I have to use another library for this?
The SSH.NET library does not support ECDSA key exchange algorithms (ecdh-sha2-*) yet (as of 2014.4.6-beta2 release).
It supports these:
diffie-hellman-group-exchange-sha256
diffie-hellman-group-exchange-sha1
diffie-hellman-group14-sha1
diffie-hellman-group1-sha1
The ecdh-sha2-*'s are commented-out, probably because the implementation is not complete/tested.
Though note that the server can support multiple algorithms and can agree on a different algorithm with different clients.
So the fact that you see an unsupported key type in the FileZilla, does not mean that the server necessarily insists on this key type.
It is clear that the server does not require ECDSA key exchange from the fact that the connection fail in the authentication phase. The authentication happens only after a successful key exchange. So your root problem is not the key exchange, but authentication.
If you need a help resolving your authentication problem, start a new question, include relevant source code, FileZilla log file and explain us what you did to setup the authentication on the server-side. A server-side log file might be helpful too.
I'm currently working on integrating a third party API to our software. One requirement of this is the use of an OAuth style authentication system over SSL/TLS.
This isn't a problem, and it WAS working for about a day and a half. Then all of a sudden, it starts returning this error to me constantly, even when trying to authenticate.
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
The fact that it was working and now it isn't confuses the bag out of me, and I have no idea where to even begin looking to solve this.
The methods involved are called from our WCF service hosted in an HTTPS environment. We have a valid signed certificate from a provider. Nothing changed in the implementation, it simply stopped working.
Do any of you have any suggestions on why we would get an error like this? I have no idea where to even begin looking.
UPDATE
The certificate exists in the trusted store.
We currently have our website as www.mywebsite.co.uk, with a valid certificate for said website. Our services are located at www.mywebsite.co.uk/Services.
We also use a Windows Service, which consumes the appropriate WCF located at www.mywebsite.co.uk/Services. Could it be the Windows Service that is causing issues? The Windows Service application is located on the hosting server, which is Windows Server 2012.
UPDATE 2
In order to workaround this issue, we've decided to use the method to ignore the certificate validation errors. This code excerpt can be found on a tonne of other articles here, but here it is anyway for any reader.
ServicePointManager.ServerCertificateValidationCallback = (obj, certificate, chain, errors) => true;
UPDATE 3
Okay, after a bit more looking I managed to get these errors from the ServerCertificateValidationCallback. It tells me that there is this error
RemoteCertificateNameMismatch
The server we are trying to access for API calls has an odd web address, that doesn't match the issuer/subject of the certificate. Is this what is throwing it off?
The server we are trying to access for API calls has an odd web address, that doesn't match the issuer/subject of the certificate. Is this what is throwing it off?
Yes, it is. Certificates are validated by checking for a match between the host name you are opening a connection to and the host name(s) identified in the certificate. The host name is the first part of the "web address" - e.g., stackoverflow.com or www.google.com.
Scenario:
A publically available Web Service that I have full control over.
But I only want this specific desktop application (my published application) to have access to the Web Service.
I could store a secret password in the desktop client, but that would be easy to crack.
Is there any known implementation that enforces this?
PKI, assymmetric keys?
If the public will have access to copies of this Desktop App, any good reverser will be able to crack it and "imitate" its transactions with the server. It doens't matter how secure is your cryptography, everything you app needs to encrypt/decrypt data is included in the binaries, so the cracker only needs to dig it out of it.
The objective of cryptography is to protect data while it is being transfered, from "middle-man" hackers, but if you have access to anyone of the peers, you can easily crack it.
Your server must never trust what comes from the client side.
[edit resuming]
Despite you cannot 100% guarantee a supposed client to your server is or isn't your App or some "emulator" made by thirdies, you can complicate things to them. Its a common practice in game anti-cheats to sometimes, randomly, make the client App a trick question like "whats the hash of your main.exe from offset A to offset B?" or "from now on packet type 0x07 swaps with packet type 0x5f". Once a fake is detected, server enter in a "silly mode", act malfunctional, and blacklist their IP/account to this mode for several hours so they cannot have sure of what their program is doing wrong.
If you detect someone is building an emulator, make them start all over again: jumble the packet type tables, cryptography tables, change some packet formats and force your clients to update. You won't see crackers bothering you for a while... LOL
WS-Security provides for X509 encryption.
Part of that implementation includes the possibility of only giving specific clients the generated public key. That way, only your selected clients can connect to the service.
The easiest way is message security using client and server certificates. The best way is to import the client certs in your server machines and hard code the client cert thumbprint in the app.config file. The other way is negotiation of certs which I haven't tried before.
If you are using IIS to host the service then client certificates using SSL is another option.
MSDN link on WCF Security.
I have set up a WCF service on a server which lives in its own Workgroup. I've tried to make a TCP/IP connection to it from a client that lives on the corporate domain. When I try to open a connection, I get a SecurityNegotiationException with the message:
"A remote side security requirement
was not fulfilled during
authentication. Try increasing the
ProtectionLevel and/or
ImpersonationLevel." The inner
exception reads: "The network logon
failed"
After speaking with some coworkers about the issues and performing some google research, I came to the conclusion that the issue is that the client is attempting to log on to the server using my corporate network login and password. Since the server is not part of the corporate network, it has no knowledge of my corporate identity and then rejects the login / connection attempt. Whether this analysis is correct or not, I have no idea.
Google results seem to suggest that perhaps the solution is that I need to impersonate user account that exists on the server machine. --I have also stumbled across this codeproject article which demonstrates user impersonation. Since the only account on the server is Administrator with no password, I tried domain as the computer's ip address as "10.0.0.11", username as "Administrator", and password as "".
http://www.codeproject.com/KB/dotnet/UserImpersonationInNET.aspx?display=Print
Unfortunately, it fails with the message:
"Logon failure: unknown user name or bad password"
Another hint to the problem: When the client and server are both machines on the corporate network, there are no connection problems at all.
How can I resolve the error and complete the connection to the server?
Even though it is not a best practice, I am completely okay with removing any security so I can keep this project moving forward
Until you grasp the details, best way to learn is to disable security. You have to create a new binding configuration at the server side with security mode set to "None". Name it "NoSecurity" for convenience. This configuration must have the same type (wsHttpBinding, etc.) you use at your endpoint. Then set the bindingConfiguration property of your endpoint to "NoSecurity".
Update your client configuration and you are set to go.
I know of no way to have a workgroup trust a domain, which means you have a couple of choices, as i see it
Add another endpoint in your WCF service that uses HTTP (a web service endpoint) and use this from the domain. This gets around the security problem, as you can impersonate here, or even set up a specific user that can access goodies in your workgroup server.
Whack down security in the WCF service. i would have to think about how to do this, but it is not a good idea anyway.
Create a domain and get a trust relationship.
The code project you mentioned is not dealing with impersonation in a way that is directly useful to WCF, as the authentication happens before you can even hit this code. I imagine you can whack at the framework bits to do it, but that would be nasty. There might be a way to use the code in an HTTP endpoint, but that can already be done without incurring the overhead of adding code that circumvents windows security.