My use case is very simple : I have a GUI application, and inside this application I host a service however clients of this services must be able to authenticate with UserName safely (The only thing I want is to encrypt messages to be sure that nobody can sniff to retrieve password of clients, I don't care about more security).
So, I want to ship a certificate with my GUI application and that my host (which is inside the GUI application... I know it's a little dirty) use the certificate to encrypt messages.
So my question is : Does my requirements oblige me to install the certificate inside the store on the host machine ?
Am I obliged to generate a new certificate with makecert for every host ?
What is the easiest way to deploy my application ?
(I control the client application so the validation of the certificate is not a problem)
First of all you should not use makecert to generate production certificates.
You could store the certificate in code and not in the machine but keep in mind that the security of the whole encryption is as good as the security of the certificate's private key. If the machine where the application will be run is secure you could use the certificate "incode" but if you cannot guarantee the security of the host machie you should install the certificate in Windows Store. Make sure the user running the application has permissions to read the certificate's private key.
If using WSE or WCF make sure you test the default message or transport encryption methods provided to see if they are good enough for your use.
Here is some references for installing certificate with private key (.pfx file) programmaticly.
Related
I am trying to wrap my head around certificates and any help is appreciated. So far this is what I understand, please correct me if I am wrong.
When using the browser when I navigate to the https site the browser downloads the certificate(without the private key) and then continues to send the data over https?
I have come across some sites (especially when developing) that require you to install the certificate on the local machine before making a service call. What is the purpose here and how does it work?
I have also seen some scenarios where you need to install the certificate on the client machine for authentication purposes for example if you are using an email client, how does this work?
When using the browser when I navigate to the https site the browser downloads the certificate(without the private key) and then continues to send the data over https?
No, the browser and the server stablish a SSL/TLS secure channel with a symmetric encryption key. During the handshake process the server presents the https certificate and digitally signs some data with the private key as a proof of authenticity.
I have come across some sites (especially when developing) that require you to install the certificate on the local machine before making a service call. What is the purpose here and how does it work?
The client must trust the server certificate. Usually it has a list with the Certification Authorities for which certificates are accepted. For other certificates is needed to add them to the trust list. If not, the communication will be rejected
I have also seen some scenarios where you need to install the certificate on the client machine for authentication purposes for example if you are using an email client, how does this work?
Probably the same case as the previous one. Also the public part of the certificate of a user can be used to encrypt a message for him
I am developing an app to run in Cloud Foundry.
The app makes constant connections to a web service using https protocol.
The web service uses a pair of self-signed certificate created by openssl.
As there is no DNS setup, I am using IP address as the Common Name(CN) in the ssl certificate.
However, the web service IP address varies from time to time. The ssl certificate has to be re-generated each time.
In order for the app to connect, it needs to trust the SSL certificate so I have been packaging the public key for the web service’s SSL cert as a file with my app.
The problem is that I have to re-upload the app to Cloud Foundry once the public key of the SSL cert changes.
Here are some possible solutions:
Register a host name in DNS. In that case, the certificate is only bound to host name. (Might not be possible cos of the budget. )
Create a private CA and issue certificates from the CA, then install the CA as the trusted CA on the client. It is feasible and a common way for internal services. However, what if the app is pushed to the CF? How can we configure the node for the certs?
Disable the SSL server authentication. Not sure whether it would put the app at risk if the authentication is skipped. For the time being, the app pulls data from the web service.
I've been thinking of keeping the public key in the database. In that case, I don't need to re-upload the app to make it take effect. But I am not sure whether it is a safe way.
Question
I am seeking for a common and safe way to keep the SSL server cert in a Cloud Foundry env. Are any of the above solutions viable? If not, is there any other CF preferred ways?
Thank you
This is a bit old, but in case this helps...
Did you try to generate your server SSL certificate with whatever hostname (even "localhost"). As you are uploading this certificate in your application (i.e. to "blindly" trust it), I think that it could work and this would avoid dependencies with your IP address.
Here's my scenario:
I need to host a WCF web service app that will be consumed by multiple customers. Each customer is responsible for their own client app, and they will be building their client apps with different technologies. It's likely that none of their clients will be .Net (probably will be Java or something else).
I need to implement Message Level Security to abide by their policies (Transport security is not sufficient).
Given the above requirements, I am having a hard time understanding how to implement Message Security in WCF that can be used by clients that I do not control. Everything I've read discusses the scenario where I would be building my own client, and that the client would even be in my network's domain.
If I implement Message Security with Certificate, can I install one certificate on my server and have each client be responsible for installing their own certificates on their servers? Would we then be able to use Message Security by simply sharing the Public Keys?
Basically, what you're saying here in your last paragraph is true. You'd give the subscribers of your WCF service the public key (.cer) file that they'd install and register within the LocalMachine/My store of their client machines.
On the host side, you'd install the cert public key in your LocalMachine/TrustedPeople store and the private key (.pfx or .pvk) in the host LocalMachine/Personal store.
You can vary the location of where you install/registry the public and private keys a bit, but then you'd have to configure your WCF service to find those cert elements on your server. The clients would have to do the same.
This does work. I've done it.
You can automate some of this using a .bat file and the makecert.exe and certmgr.exe DOS commands to ensure everything gets installed in the correct places.
I'm using SharePoint 2010 and I'm configuring a web part using ChannelFactory and Certificate to access a WCF service.
But I'm getting this error message:
Error occured: Could not establish secure channel for SSL/TLS with authority 'my FQDN'.
How could I configure my SharePoint web application to have access to read this installed certificate?
(I'm sure the certificate is installed correctly on the server where sharepoint is installed and all the WCF configurations are correct)
Many thanks in advance,
Are you talking about a client certificate that SharePoint would use to authenticate itself when connecting out to some service? If that is the case, then you would need to install a certificate along with a private key. Otherwise, if you are just talking about a root certificate to validate some server certificate on a remote service, you do not need the private key.
Assuming that you mean a client certificate with private key (I don't know how SharePoint uses certificates), then you would have to install the certificate along with a private key, and then, make sure SharePoint has access to the private key.
It's not enough just to install with the private key -- you have to either install logged in as the Windows account that the code using the private key will be running under, or, if you install the certificate into the Local Machine "Personal" store, for example, you have to set an ACL on the certificate to give another Windows account access to the private key. To do that, you can use the WinHttpCertCfg tool. Cf. here for the general idea, and here to download the tool. Or from the MMC Certificate snap-in, select the certificate in the Local Machine, Personal store, right-click, select All Tasks, Manage Private Keys, and grant access from there.
Have you tried uploading it to the Manage trusts area?
http://centraladmin/_admin/ManageTrust.aspx
Rebooted the server?
Installed on all servers in the farm? Into the machine store (not service or personal)?
I have a WCF Server Deployed through IIS. I want to Create a Certificate for it. I could do this by making the server a certificate server.
But then when the client connects to that server I want the client to automatically trust the certificate without having to register that the server as a "trusted authority".
Is this possible?
All this seems a lot of work to put username password protection on a WCF Service!
The short answer is no the client will need to add the server cert root as a trusted authority.
The slightly longer answer is that there is a workaround for needing to implement transport security in WCF when using message based authentication - this workaround is usually used when you want to rely upon another security mechanism that the WCF server is not aware of, like an ISA server providing SSL.
Have a look at Yaron Naveh's post. The essential idea is that you create a transport binding that pretends that it is secure.
With all that, you still need security (you don't want to send your creds in the clear) and so will still need a trust chain for your cert. So, it may not actually help you, but hopefully it gives you some options to consider.
Edit
Sorry if my answer was misleading. The server certificate root cert must by in the client trusted store. My additional detail was giving another option for providing the security (you can use an ISA server with a trusted cert to give your SSL connection)
In a similar situation to yours (needing secure communication when pushing client applicaitons to non technical customers) I have programatically installed the needed root certs.
Here is an SO post that details how to do that: How can I install a certificate into the local machine store programmatically using c#?
You can if you add this to your code but be aware of what you are doing!
System.Net.ServicePointManager.ServerCertificateValidationCallback += ( se, cert, chain, sslerror ) => { return true; };
Well if there would be such a way, it would be a security hole.
If a certificate is not linked to a trusted authority it is easily forged. So your choice is either to link it one way or another (directly or through a parent certificate you control), or configure your client so that it does not require the certificate i.e. using http rather than https.
Just keep in mind that it leaves your clients open to a variety of attacks
Edit
One of the possible attack scenarios is a man in the middle attack - a program inserts itself between your service and the client and channels the information though itself. This way the intruder has complete control over the information flow.
It can make copies of passwords or it can "adjust" the results in both directions any way it wants. The only thing which prevents this from happening is the certificates. But if they are not rooted, they can be forged.