I am building an application and I am planning on using OpenSSL for securing data transfers.
I am planning on only having the client validate the server\'s certificate.
Just to make sure we have our terminology straight, an "SSL certificate" in common parlance is really composed of two components:
The public certificate component is signed by your chosen CA (certificate authority), after which it can be freely distributed. It does not need to be secured or encrypted, and indeed it will be sent to clients that connect to your server as part of the SSL negotiation.
The private key component should be protected. In the majority of cases, this is simply stored as an encrypted file on the server. Upscale solutions use dedicated "tamperproof" crypto hardware (HSMs -- hardware security modules) to store the private key. These range from smart-card based solutions to multi-key, network enabled appliances with m/n controls etc etc. There are risks (not to mention costs) associated with HSMs that I will not go into here.
Many applications simply retain the private key on disk. There are a couple of options to secure the key file:
As always, there is a security trade-off. In particular, if you are using password-protected encryption on the private key file and you experience an unexpected application restart (eg power outage), then somebody will need to be available to provide the password to the app as it restarts. Storing the password in a file that is read by system initialization scripts (as encouraged by at least two web server vendors) adds little in terms of real security. It's hard to recommend leaving the private key file unencrypted but if you are the sole admin/techy in a small shop, you should definitely consider what might happen if the server reboots when you are not available, and what the costs might be to your business.