views:

111

answers:

2

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?

A: 

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.

Bruno
he needs the private keys because they are his ssl client's identity. Presumably he has several ssl servers that need to verify his connection.
IanNorton
Of course, what I was wondering is why use client certificates instead of alternative systems such as Kerberos. There, the KDC would also need to be secured too, but there seems to be less risk using a well-tested KDC software than developing a bespoke service to store the keys and certs. This scenario might not work for various reasons (e.g. Kerberos not applicable, perhaps if you need to connect externally or other reasons). I just think we could provide better answers with more details regarding the environment.
Bruno
Bruno, I am not storing Private Key in the database, but the password to access the private key. I am using .Net class X509Certificate2, Constructor (Byte[], String). This constructor creates a new X509Certificate2 object using a byte array and a password that is needed to access the certificate data. It is used with PKCS12 (PFX) files that contain the certificate's private key. Calling this constructor with the correct password decrypts the private key and saves it to a key container. As we are consumning third party web services they require client SSL certificate authontication.
amz
A: 

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.

IanNorton