1

I want to build a PKI (public key infrastructure) to host certificates for users.

My use case is, that I want to use the certificates for e2e encryption between the users.

  • Users must be able to download valid certificates for a random user. (sharing is initiated by the sender)
  • Certificates must still be valid, even if the receiver did not log in for a long time. (in theory months, years)

For that to work,

  1. the user has to send me a CSR (certificate signing request)
  2. I have to check the CSR for validity
  3. I create the certificate with the CSR and my intermediate signing certificate

Now I want to prolong the existing certificate. For that I could store the CSR in the database and just repeat step 3.

  • Is this a good idea? (I have the feeling that it is not, but I cannot pinpoint the exact issue with this.)
  • If not, what are good and reliable alternatives? (e.g. I want to keep the certificate valid, even if the user does not log in for a longer time)

2 Answers 2

1

Is this a good idea?

In fact, it is a standard procedure for CAs. CAs keep all incoming CSRs (along with other relevant information) for audit purposes and a proof that a certificate for a given public key was requested. CAs often keep both, successful and unsuccessful requests.

2
  • Two things: 1) Do they reuse it to issue a new certificate? 2) Can you provide proof for your claim that it's standard procedure? Thanks
    – klara-l
    Commented Jan 3, 2019 at 10:43
  • 1) It depends on CA policy. If requester wants to renew the certificate and reuse the key pair, new CSR is not generated. In this case, CSR can be reused. 2) general purpose CA software Microsoft ADCS, EJBCA, XCA does this by default.
    – Crypt32
    Commented Jan 3, 2019 at 11:00
1

A CSR contains essentially the same information which end up in the final certificate, although the CA will likely add some additional information and might decide to ignore some information from the CSR. Specifically the CSR does not contain the private key for the certificate. Given that it should be no problem if the CA stores the CSR.

4
  • But what about the fact that now the CA does not ask for the possession of the private key each time it renews the certificate?
    – klara-l
    Commented Jan 3, 2019 at 10:33
  • @kaidowei: You've asked only for extending an existing certificate if the user does not log in for a long time. There is nothing known about your actual use case of where the certificates ends up and what it is used for. But the user itself can only make use of the certificate if he still has the private key. Any changes needed to the certificate due to lost or compromised private key or that the user should no longer own the certificate are a different issue - and are more an aspect of revoking an existing and still valid certificate. Commented Jan 3, 2019 at 10:40
  • I updated my question to add info about the usecase. I'm not concerned about a stolen private key in this question but about missing some attack where the CA just refreshes certificate without checking in with the user (getting a new CSR)
    – klara-l
    Commented Jan 3, 2019 at 10:52
  • @kaidowei: by reissuing a certificate from the CSR you just extend the validity of the information in the certificate (subject...) and declare the key pair as still valid. If you can do this without contacting the user depends on the specific use case and even the additional information you've provided about this are not enough to decide if this is ok or not. Maybe it is sufficient to describe this automatic behavior in your terms of service and require the user to make any updates to the information and key if needed. Commented Jan 3, 2019 at 10:58

You must log in to answer this question.

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