Should I store my users' certificates and private keys or not?

Question

Situation

I am doing an internship in a company and I am currently working on a web application that has the following features:

• This is a private application, users can only be added by an administrator of the application
• Users can add PDF files online
• Those files are stored in the application server

My mission as an intern is the following:

• I have to implement a feature that allows clients to sign the PDF files using this mechanism.
  It has to be simple to use : one button "Sign" next to the file and the server signs it automatically using the user certificate. The basic idea is that each client would be granted a certificate when his account is created (the Certificate Authority would be trusted by the application). At some point I will have to get the private key of the user in plaintexte to sign the file on the server (I am thinking about using phpseclib library to read certificates).

Question

• Should I store the users' certificates and/or private keys on the server? * Isn't there a better way to store users private keys, such as a trusted web application that has REST API or some easy way to access it?

• Edit : My situation has evolved and now my question is more like the following:

  • Is it safe to store .pfx or p12 files on the server? I know they contain private keys but is the file as itself really secured (let's say there is one client password for each file).

Note : I am still a student and not an expert in security, please tell me if you need further information to answer.

Answer 1

Well, from security perspective, clients should sign PDF files on their devices. The value of the signature after PDF is uploaded is very low, because there is no guarantee that PDF wasn't tampered during transmit. In your scenario, you can't be sure that sent and signed PDFs are the same, because PDF's integrity is not guaranteed during transmit.

In other words, the procedure should be as follows: client acquires/generates PDF document -> sign -> upload to server -> register. In this scenario you can be sure that you have exact PDF created by client (if signature is valid).

The fact that server holds client certificates and their private keys makes things worse. You can impersonate legitimate client, craft signatures legitimate client never did. If the attacker hacks your server -- keys from all users are automatically compromised. Private keys should be stored at client devices, otherwise they have no control over the key, thus no liability for signatures. The outcome -- signature's zero value and failed project.

Answer 2

As users are added by an administrator, storing the user certificates on the server is a common usage. If users could be dynamically added, you should still store the certificate passed at connection time for later reference.

Storing the keys in the server is not common. The key is more or less a password, and best pratices recommend to only store the hash (here the public key contained in the certificate) on the server. So the best pratice rules recommend to not store the private keys on the server.

But here your mission seems to be to sign the files server side. You have no option but storing the private keys server side. The down side is that a server admin can sign a file on behalf of any user...

AFAIK, this is an uncommon requirement. A signing operation - if you expect non repudiation - should occur client side to ensure that the private key is always under the exclusive control of its owner. But that also requires a collaboration between the server that would send the unsigned file and receive back the signed one, and a process running client side (a client side java applet for example).