0
$\begingroup$

If A has a certificate issued by a CA_X, certainly A should have the private key of the certificate. My question is, does A generate the private key by itself, or , the private key is generated by CA_X, and somehow is sent by the CA_X to A?

$\endgroup$

2 Answers 2

2
$\begingroup$

According to my understanding, the private key should be generated and kept by the holder (or subject) of the certificate. The public key and some additional information is sent to the CA. Nevertheless, the CA should not know the private key of the certificate.

Is the above understanding right?

$\endgroup$
1
  • 1
    $\begingroup$ Yes, that's the standard way things are done. It's such that only the holder/subject of the certificate knows the private key. What's sent to the CA is called a Certificate Signing Request (CSR). It typically contains the public key, identifying information, and a signature of that using the private key. The CA sends back the certificate. CSR and certificate both can safely be made public (though usually, only the certificate is). $\endgroup$
    – fgrieu
    Apr 12, 2022 at 6:16
1
$\begingroup$

There are and have been certification authorities that do provide key pair generation services. That should definitely not be the preferred way however. First of all, it allows the CA to act as the entity that has the private key, as they may have retained it $^1$. Secondly, it means that the transport of the private key must be secured. Finally, it may also make storage less secure; generally you don't want to have the value put in unsecured memory, which may also be swapped to a storage device.

Generally you would try and keep the private key as secure as possible. That basically means that the key value is only transferred if a backup is required. Sometimes simply requesting a new key should be preferred, but generating a new key pair means that the certificate needs to be replaced as well, and that could take too many resources (money, communication overhead, key management procedures etc.). Sometimes the key value may also be used by multiple related servers (e.g. for wildcard certificates).

Note that to request a certificate you only sign the certificate signing request or CSR using the private key. That allows for the private key to remain in a secure key store or (hardware) token such as a TPM or HSM, rather than be loaded into insecure memory.


One of the CA's that provided key pair generation services was DigiNotar. It was a notoriously insecure CA that went bankrupt after it was discovered that you could request certificates for any domain.


$^1$ although they could of course sign any invalid certificate request - in principle they would not need a request of a specific user; the process would be rather different though, and it should normally end up in the audit logging if they were going to sign their own requests

$\endgroup$
4
  • $\begingroup$ I'm pretty sure that I saw a currently available CA provide key pair generation services. I'll try and find it, and publicly shame them. $\endgroup$
    – Maarten Bodewes
    Apr 13, 2022 at 16:31
  • 1
    $\begingroup$ For an example of how a CA generating & retaining private keys can go wrong: Trustico was storing private keys clients had generated online, and were amazingly lax about securing them, leading to 23,000 certificates having to be revoked with minimal notice. Trustico is still in business (I don't know why), but at least they don't do that anymore. $\endgroup$ Apr 14, 2022 at 8:02
  • 1
    $\begingroup$ Maarten: try issuers of EV codesigning certs; they are required (emphasis added) to "ensure that the Subscriber's private key is generated, stored, and used in a crypto module that meets or exceeeds ... FIPS 140-2 level 2 or CC EAL 4+". IMLE such CAs have decided it's cheaper for them to get a module (buying in bulk at a discount) that does not support key export, supervise the key generation, and ship it to you, rather than having you pay tens of thousands to audit your own device installation and operation. $\endgroup$ Apr 15, 2022 at 0:24
  • $\begingroup$ Well, there's something to that if the hardware doesn't allow export even to the CA, as long as the key usage itself is ephemeral. I would not like such a thing for e.g. non-repudiation, but I could see it as a (semi-)secure intermediate method for real time authentication and possibly decryption. In the end it comes down to context I suppose. $\endgroup$
    – Maarten Bodewes
    Apr 15, 2022 at 10:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.