From my .net client code, is there a way to obtain details about an SSL certificate being used by a WCF service? Assuming I can already connect successfully over SSL to the service.
I am hoping to report the expiration date of the server certificate on a dashboard. If the certificate has been updated / renewed since the last time the client communicated with the service, I'm trying to detect that as well.
Let's also assume the server cert is a real public cert from godaddy etc. i.e. the cert would not have been explicitly imported into the client store already.
Any thoughts? I was thinking I might find somewhere in System.ServiceModel.ClientBase that I could find this after opening a connection but haven't found anything yet.
Thanks!
Easiest way would probably be to just implement a certificate validation callback on the client so that you can have a chance to look at the SSL certificate provided by the server before it is trusted by the client:
http://msdn.microsoft.com/en-us/library/aa702579(v=vs.110).aspx
Related
I have a REST API which uses JWT bearer authentication over HTTPS. SSL certificate is installed on the web server hosting my REST API. Do I need to provide client certificates to different applications(users) who want to consume my API, to have a handshake between their server and my server using the client certificate which i provide them.
I tried calling my HTTPS REST API which I developed in C# from a python script running locally from my machine but I had to specify the verify flag to False or ssl.CERT_NONE for the call to succeed
import requests
requests.get('some https url', verify=False)
I know we can also use self signed certificates. I am worried about Man in the Middle attacks if they call my endpoint with verify=False and If someone tries to use my API in his app which is in production over https do I need to give him the client certificate for handshake or his app would be able to call my https api endpoint without me specifically providing a client certificate.
I tried to take some leads from this question but it doesn't explain how different users whose apps are trying to call my endpoint over https, will be able to perform a handshake with my rest api
Any guidance would be highly appreciated.
Quick answer: keep your private key file safe and you wont have any problems.
The long answer has to do with explaining asymmetrical encryption and how its implemented in a TLS handshake. When a client opens a HTTPS connection with your server a series of requests are sent back and forth:
Client sends HELLO
Server sends HELLO back including the servers SSL certificate
Client verifies the certificate with the certificate authority
The client sends back a random string of bytes encrypted with the servers public key
The server decrypts the string using the private key
After the final step a session is created between the client and server. In order for a man-in-the-middle attack to be successful the "man in the middle" needs to have your private key and proxy every action just described back to your server, otherwise one of the steps will fail and the client will get that "SERVER UNVERIFIED" error in their browser warning them that the connection is not secure.
This is a pretty brief explanation of the process, you can do some more reading here
We have a client that has their own PKI infrastructure and assigns private certs to use as SSL client authentication for application access to their rest APIs.
I need to be able to use a client cert with SslStream and not have it choke that it is not trusted. Users will not be educated enough to know how to add CA certs to their local trusted cert store. Plus, most would not have the access to do so either.
The client application is being written in .Net 4.6.1
What do I need to do to get SslStream not to throw an exception with an locally untrusted client certificate?
Have you looked at the constructor that accepts a certificate validation callback method? https://msdn.microsoft.com/en-us/library/ms145057(v=vs.110).aspx Seems like that's what you are asking to do.
I am using IBM MQ WebSphere client v 7.5 installed on an application server.
To securely connect to the MQ queue manager I have to pass certificate whose Name should be ibmwebspheremq + "userid". I put my code on the APP SERVER to test the MQ connectivity. If I specify domain user id it works fine for me but not for other domain users. So what certificate name should be used so that it works for all domain users??
Certificate Label : ibmwebspeheremq.kdb located on the local path
certificate Name: using strmqikm.exe, open above certificate and check the name
As of now this CN is "ibmwebspheremq" + 111111(domain userid) and it works fine for the domain user 111111 ,but for domain user 222222 it is throwing SSL errors.
P.S. Security must be maintained
Update from OP comments on 11 Sept 2015
I am using the .NET Application and done code through the help of IBM.WMQ interface provided with the dll amqmdnet. I have KDB certificates and I have just provided the local certificate's path in the configuration. I am able to access the MQ Server for the particular user on APP Server (where MQ client resides) but if I want to access for all users then how to? because in my case certificate label name (using strmqikm.exe) should be like ibmwebspheremq + userid. For individual users I am able to access the certificate by doing individual login to app server but not for all users at a time. There is only one certificate and as mentioned earlier it is non-JAVA application.
The MQ client either uses IBM's C code or it uses Java and the JRE's JSSE provider. Each of these have different behaviors and requirements.
The Java EE App Server will use the JSSE Provider and its rules for selecting a personal cert from the JKS. That may or may not include searching for a particular label. Anything using IBM's compiled C code API will require a specific label for the personal certificate in the KDB. Furthermore, the behavior has changed from version to version, as explained in IBM's Technote Specifying the userid in the SSL certificate label for an MQ client.
As explained in the Technote, the Java client uses standard Java methods for finding the personal certificate and is not dependent on the label at all. That requirement is only for the non-Java client. The App server uses a JKS and the non-Java clients use a KDB. Since you did not mention converting certificates between JKS and KDB, I will assume that your testers are not using the C client or a KDB.
Presumably then, your testers are using the same JKS as the app server. If they have the right path and the password to access it, and if it has a personal cert, they will be able to find and present the personal cert. If it has more than one personal cert, MQ has no control over how it selects which one it will present. That's a Java thing. If this is the problem the answer is simple - either use one personal cert and one keystore, or else each tester has their own JKS, each with its own personal cert.
Security must be maintained
In that case, the latter approach is preferred. Each tester should have their own JKS and their own personal cert.
The other possibility is that you have a variety of certs, each of which is being found by the client and properly presented to the server, but that there's a cert exchange problem. If each developer has their own cert and those are all self-signed, the public portion must be in the QMgr's KDB to be accepted.
If you want a more precise answer, you will need to provide a lot more detail such as what code, keystore, and certificate the testers are using to test with, whether these are self-signed certs, whether the testers are using the same app channel and testing from the same node, whether you are using SSLCAUTH, etc. I would also recommend using the debugging procedure I outlined in this answer.
MQ v7.5 C# client internally calls MQ C client to establish secure connections to queue manager. Logged in user id is used to make ibmwebspheremq<userid>certificate label and pick the correct client certificate from a KDB. Hence for #Dirty Developer, the application is getting connected when a user logs in for whom a certificate with a label that has his/her userid suffixed exists in KDB.
From MQ v8, there is no need to have a certificate label always suffixed with userid. MQ v8 provides a CertificateLabel property using which applications can specify any certificate label. MQ client will use the certificate label to locate a personal certificate that is sent during the SSL handshake. In MQ v8 .NET client, this property is named MQEnvironment.CertificateLabel. Here is more on Certificate Label in MQ v8.
After all this time I have spend in research finally I have an answer !!!
1) It is not possible to change certificate name for every user who want to use MQ on server at everytime.
2)We have to find certificate name such as it will work for all users( this is my question?:) ) and methodology to incorporate this changes.
Actual procedure :
3) I have developed a code to connect to MQ in WCF service and hosted the service on IIS
4)For IIS user on server I had SERVICE ACCOUNT which I binded with certificate label i.e. ibmwebspheremq +
5) All the clients who want to connect have to call the service that I've deployed on IIS server and volla !!!!!! it worked.
6)you must have that service account to be binded with your role/domain user id
7) Note : on server you must have to provide access to IBM folder for service account.
I'm using a Winforms client to connect to a WCF service hosted in IIS. The Winforms application will be available to customers to download and install on their computers. The customers have to login to the application using their username/passwords. I want a secure HTTPS enabled communication between the client application and the WCF. What is the best practice to provide such a functionality? Should I use client certificates or just a server certificate? Any input is much appreciated.
Thanks.
You have to have a server certificate.
If you want stronger authentication you can use client certificates. There is an administration of certificates overhead and potentially other costs to that though: Using certificates from a provider, generating them yourself, maintaining list of revocations and so on.
As you already authenticate the user with password, client certificate authentication is not needed. To ensure the communication is secured use a self-signed server certificate. In case if the clients needs to verify that they are connecting to the correct server then you need to get a signed certificate from a third party CA like verisign which could cost you atleast 100$.
I need an encrypted communication between C# and PHP to send HttpWebRequest's and download files from the server. Is that possible without buying a certificate for https? I think a certificate should'nt be needed in my case, isn't it? What do you recommend to use?
If you control both ends, you can generate your own certificate and manually check that the server is using the expected one. It's in the case where the client wants to verify that the server is using the correct certificate that you need the functionality provided by a certificate authority.
Normally, the certificate is loaded into the web server and the encryption/decryption is invisible to any code running on the server. I would be very surprised if you could do it with just "php stuff".