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


  • 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.

2 Answers 2


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.

  • I agree with the "client acquires/generates PDF document -> sign -> upload to server -> register" but my tutor want it to be simple for the user : they have no knowledge about PDF features and certificates at all, and it's more intuitive to just have a button sign.
    – Shashimee
    Commented Jun 7, 2017 at 7:03
  • tutor want it to be simple for the user -- I can understand, but your solution doesn't achieve the goal your tutor is pursuing. When the solution doesn't achieve the goal, the solution is useless. You may have to develop client-side application that would have 'Sign' button that will do everything you need to upload signed PDF.
    – Crypt32
    Commented Jun 7, 2017 at 8:36

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

  • Yes the files have to be signed server side. "Storing the keys in the server is not common", is it ok in terms of security if I encrypt the keys (using salt) and store them on the server ?
    – Shashimee
    Commented Jun 7, 2017 at 7:13
  • @Shashimee: Security is not an absolute concept... If the keys are stored and used on the server (whatever the details), you will not have a non repudiation signing, meaning that it will have little to no value for a legal court, because as I said an admin could sign on behalf of a user. You (and your company) can say whether it is enough for your security requirements, I cannot because I do not know them. I said it is uncommon, because digital signing is generaly expected to be a proof of an action by somebody, while here it is definitely not. Commented Jun 7, 2017 at 13:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .