I have stored Client SSL certificate in database as a file and its private key's password in a column (not using certifcate store) for each web service that requires certificate.The reason I prefered this that I don't have to worry about user privellege to access the certificate if the code is moved to another server (Dev/QA/Prod). As certificate stored in centralized location, I dont have to install it in each machine. Moreover business people can upload certificate any time they want without intervening Developer and certificate will be different for QA and Production environment. Now my concern is that storing certificate in database compromise the security rather than storing it in certificate store?
I guess you mean "I have stored Client SSL certificate in database as a file, its private key and its private key password". Maybe the X.509 certificate and its private key are in a single container, presumably in PKCS#12 format. (Or do you just really want to store only the certificate? Storing just the certificate is fine, but why would you store the private key's password too.)
This isn't necessarily wrong, but you have to make sure access to this data-based is well protected.
In general, the private key is really that: private. Some certification authorities even mandate in their policies that no one other that the end-user may know the private key (at least with reasonable protection, e.g. within the browser or in a PKCS#12 file for which only they know the password). This makes sense when using public and private keys.
I think you need to look carefully at all the angles of your design. It's not clear why you want to store the private keys in a database for the users to retrieve. It may make sense to store private keys in a central place, but this may also defeat the point of using client-certificate to authenticate (it really depends on the full picture and the degree of security you really want).
Storing all your users' private keys in a central place is probably not as secure as having each user use their own store, but it may be acceptable. Ultimately, it depends on the threats you may encounter.
From a security point of view, your strategy of placing the private keys AND the password in the database gives away rites to all the keys to the database admin, the software author AND the system admin.
placing the private key's password on the system but not in the database only hands total control to the system admin and software author.
One other solution would be to store the private key in a hardware device (HSM) and only store references in your database. Your software would then use a hardware crypto API like PKCS#11 to perform the SSL client handshake crypto and your private keys would never be in system memory or on disk at all.