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.
Related
Have implemented SSL with self-signed certificate On Apache Tomcat 7.0.47 using Java keytool.exe.It's working fine in Browser.
Issues are:
1) while invoking the API's in java/dot net client am getting exception as "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel"
Solutions i got through online are:
1) Need to ignore invalid certificates then what's the use of SSL implementation.
2) Need to import cert into client truststore.
Could anyone suggest me how to solve this problem,is anyother ways to implement SSL and invoke those API's in client application. don't want to ignore the Cert
It's working fine in java client using InstallerCert.java class but need to invoke HTTPs API's in dot net client,any help would be really appreciated
Thanks in Advance
You need to establish trust relationship between client and server, in order to call server APIs. For java you can follow these steps to achieve your goal -
Generate certificate for server (You can do this by using installCert.java)
Once this certificate is generated usually it will be keystore file and/or .cert file
You copy this file(s) into your JAVA_HOME/lib directory
Then restart your server and this should be done
More info can be found from these sources -
security-ssl-certificate-error-use-your-trusted-certificate and http://miteff.com/install-cert
Hope this helps. There are other ways also, to generate certificate but this way is easiest as per my understanding. :-)
I am using WCF services with C#.
I am using the transport security mode by setting the client and service certificates.
In the middle of operation I would like to change the certificates that I am using and use certificates signed by other CA.
Is it possible to change these certificates in the middle of operation without restarting the service host? If so how?
Is it enough if I just call set certificate with other certificate passed:
serviceHost.Credentials.ServiceCertificate.SetCertificate(...)
serviceHost.Credentials.ClientCertificate.SetCertificate(...)
Someone have encountered this problem and resolved it?
I have tested this as a high-availability issue. You can't do it. The service acquires its certificate when the ServiceHost opens and never again.
If your goal is to support HA, you need to put multiple services behind a load-balancer and restart them one-by-one.
You can't change certificates without restarting the web service, unfortunately. I've looked into this extensively. There's no way to do it. Sorry
I'm working on a client-server project implemented using WCF. The clients are deployed on different machines and communicate with services through the internet. I'm relatively new to WCF, and am a bit confused on choosing the appropriate binding for my Web services. The clients need to be authorized to perform operations, however, I'm implementing my own authentication algorithm and trying to avoid Windows authentication for various reasons, but I still need to make sure the message transferred in the channel is encrypted.
Right now I'm using wsHttpBinding with security mode set to Message. Full configuration looks like this:
I've set the authentication type in IIS to Anonymous Authentication to make sure the requests are passed through, and was expecting a service call to fail since MessageClientCredentialType in my binding is explicitly set to Windows. However, when I run the code, the service successfully gets called and returns the expected values. I have a feeling that I'm missing something - why is the call authorized? Can I make sure the message is still encrypted even though authentication type is set to Anonymous? Any help is appreciated.
Edit
To clarify on this, I tested the service with a client deployed to a machine outside the network on a different domain.
This MSDN article kind of sums up a lot of security issues relevant to WCF
http://msdn.microsoft.com/en-us/library/ms733836.aspx
regarding your specific situation,
the negotiateServiceCredential="true" means that you streamline certificate distribution to your clients for message encryption.
This option will only work with windows clients and has some performance problems.
read more here http://msdn.microsoft.com/en-us/library/ff647344.aspx
search the topic "streamline certificate distribution" in this page.
Which account do you use to make the call to the service? Allowing anonymous in IIS lets your request pass through to the service and service should authenticate if your caller has credentials that windows understands (Active directory/NTLM).
In your case, I think you are testing it in your own environment so service responds. Once you deploy it over internet, I doubt your service will allow anybody outside of your domain if you keep clientcredentialtype to windows.
Check these link for securing services on the Internet -
http://msdn.microsoft.com/en-us/library/ms734769.aspx
http://msdn.microsoft.com/en-us/library/ms732391.aspx
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.
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.