We Keep Coding

One Way SSL Implementation in .net - Need assistance

We need to Implement one way ssL connection to a remote server . We have been given the APi end point and also the public key certificate.
We are trying to use the HttpClient to connect but it seems this approach requires us to have a private key as well.
Is there an example one way SSL implementation example in .net that we can refer

Configured SSL on Apache Tomcat 7.0.47

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. :-)

secure communication between c# client and java server

I want to secure communication between simple C# WPF client and Java server. Now i have already implemented raw sockets communication, and my security is based on:
server send RSA public key to client ->
<- client send back encrypted with RSA public key, AES key for future communication.
but i'm not assured that someone (the men in the middle) will catch and replace my public key. I suppose that for avoiding men in the middle i need to use CA certificates. Can someone help me, how to make a SSL connection between Java server ans C# client using certificates ? And where i can find some certificates for testing purpose.

Start trying to see if it helps: C# SSL and Java SSL. I can try to help more then this, if you need.
Edit:swapping links.

Driving a Certificate Authority programatically (C# or C++)

I'm writing a client/server application that requires the server needs to be able to authenticate the client and also requires all comms to be encrypted.
The mechanism to provide this needs to be self contained within the server and client application and also to be fully automated (no human interaction required). SSL seems to be the best way to do this and is also something I am familiar with using.
For each client that needs the client software deploying to it, I planned to create (on the fly) an MSI installer with the application, the clients certificate (signed by the server) and private key and the servers public certificate (so the clients can authenticate the server - the server certificate could be self signed).
I can generate the key for the client and make a CSR, but don't seem to be able to find a way of actually signing the CSR and generating a certificate for the client thou. I have looked into the Win32 Crypto API, but haven't managed to find any examples of how to actually sign a CSR and get a client certificate.
I know how to do all of this from the command line with the openssl tool, but am not sure of how to do it from within an application.
Please note that making system calls out to the openssl tool and passing in the parameters I know to work is not an option as it's a huge security risk to rely on the openssl tool not being compromised in any way. Doing it this way wouldn't for fill the self contained requirement.
I am going about this the right way, or is there a better way to achieve the same thing - basically authentication of the clients connecting to the server and a way of the connecting client to authenticate the server they connect to, all encrypted.
I cannot make any assumptions about the server (or clients) having a static IP or hostname (DNS can be broken anyways), nor can I make any assumptions about any existing PKI infrastructure.
I am writing this primarily in C#.Net, but would consider writing a C++ extension to this if it gives me this functionality.
Finally this is my first post here, so if I've missed out something obvious or have been short on any details, please ask and I'll fill in the gaps :)
Thanks,
James

In C# you can use PKIBlackbox package of our SecureBlackbox product which provides all the functionality you are looking for in .NET. Maybe BouncyCastle library also includes this functionality.

You need to rethink at least part of this. What you are doing is radically insecure. The client's private key needs to be generated at the client. Otherwise it isn't private, so it cannot possibly satisfy any of the tenets of PKI,. including the purpose for which you are issuing it. You lose uniqueness and you also lose non-repudiability. These are both fatal flaws.

Flash & C# encryption

I am creating a TCP connect with Flash to a C# daemon.
Now I have come to the part of encryption... I know that Flash is decompilable and so not safe to store private keys on.
I need 2 way encryption because of the messages that have to be send back to the Flash client.
I have been thinking and googling, but cannot find a proper solution yet.
Anybody got an idea??

You'd usually use a hybrid encryption.
Client opens a session on the server, acquiring public key for an asymmetric encryption.
Client generates a key for a symmetric encryption, and sends this key to the server, encrypted with the public key previously acquired.
The rest of the communication is encrypted using a symmetric encryption with they key now known to both client and server.
greetz
back2dos

back2dos' solution will work (and be the easiest) if your connection is SSL/TLS.
If you are forced to use regular sockets (e.g., the server does not have an SSL certificate), then you'll need to do the same by hand. In this case, you'll need to use a Diffie-Hellman key exchange, which enables the creation of a shared secret that is not actually sent over the wire.
Again, if possible, use back2dos' solution. It's a lot easier.