Score:0

the matching private key of a certificate -- how to get it?

jp flag

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?

Score:2
jp flag

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?

fgrieu avatar
ng flag
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).
Score:1
in flag

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

Maarten Bodewes avatar
in flag
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.
jp flag
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](https://arstechnica.com/information-technology/2018/03/23000-https-certificates-axed-after-ceo-e-mails-private-keys/). Trustico is still in business (I don't know why), but at least they [don't do that anymore](https://www.trustico.com/csr/generate-csr-howto.php).
dave_thompson_085 avatar
cn flag
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.
Maarten Bodewes avatar
in flag
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.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.