Even though bug 341371 was fixed in NSS 3.12, certutil still lacks a way to generate a CSR for an orphan private key. An orphan private key is an existing private key in the key DB for which there is NO cert with the corresponding public key in the cert DB. When you want to generate a CSR for an existing private key in your key DB, and you also have a certificate with the corresponding public key in your cert DB, you can specify the private key indirectly by giving the nickname of the cert with the corresponding public key. NSS finds the cert by the nickname, and then finds the private key corresponding to that cert. That is the technique used to generate a CSR for an existing private key when you have a corresponding cert, which was implemented in bug 341371. But Private keys do not have nicknames, so one cannot refer to a private key directly by nickname. If there is no cert with a corresponding public key in the cert DB, you cannot reference the existing public key by a nickname. A method is needed to refer to a private key on the command line that works even for orphan private keys. All private keys accessible to NSS have PKCS#11 Key IDs (CKA_ID). These are binary numbers that may be expressed in hex, and may be up to 20 bytes long. certutil -K will print out the CKA_IDs for the private keys in the users key DB. (that was bug 291384.) Bug 291383 proposes to allow users to enter private key CKA_IDs in hex as command line arguments, for the purpose of deleting those private keys. This bug now proposes to use the same technique, entering the CKA_ID in hex as a command line option argument, for the purpose of specifying a private key for the generation of a CSR. This will enable the generation of multiple CSRs for the same private key, even while the private key is still an orphan (before the first correpsonding cert is imported to the cert DB. Related bugs: Bug 67890: create self-signed cert with existing key that signed CSR Bug 291383: certutil cannot delete orphan private keys Bug 291384: certutil -K behavior doesn't match usage Bug 341371: certutil lacks a way to request a certificate with an existing key
Bug 67890 is very much like this bug, but it intends to skip the generation of the CSR, and instead issue a self-signed cert using an existing private key. It proposes to add yet another way to specify the private key to be used, namely by supplying a CSR that was previously signed with that same private key. That is also another way to do it. So, there should be at least two ways to specify orphan keys: - by CKA_ID inhex - by naming a file that contains a CSR signed with the same key.
Nelson, We probably don't want to require a CSR file to select the orphan private key. At least in the case of deletion, it's most likely that the CSR is lost.
True, but having just generated a CSR, we ought to be able to use it to specify the private key for the generation of a second CSR.
Nelson, The private key might be orphan in a token for other reasons than having just generated an initial CSR. Specifying by CKA_ID is a more generic way than passing a CSR. I would consider the second way (passing in existing CSR file) to be optional for resolving this bug.
Using a CSR is actually the easier of the two methods to implement, and IINM, there is already a patch that implements the find-key-by-CSR part attached to bug 67890. I'm sure that the find-key-by-CSR and find-key-by-CKA_ID methods, once developed for one purpose (such as _deleting_ orphan keys), will also be immediately useful for the other purposes (such generating CSRs, issuing self-signed certs).
Any progress on this bug? I like the idea of using CKA_ID to identify the key in the database (but see below), it would be use for many purposes. What's prompted our interest at the moment is we would like to be able to have a crypto agnostic utility (e.g. either OpenSSL or NSS) which follows the same basic sequence of steps, yet using the specified crypto provider. But currently when using the command line tools (e.g. certutil) there is no way to create a keypair in one step and then in a subsequent step generate a CSR from the key pair. It would also be useful for things like reissuing certs when the original CSR is lost. Is there any reason a nickname (or other user supplied identifier) can't be used to label (identify) the key pair generated with -G? And then use that identifier to specify the key used in the CSR? That would be ideal because then the user is in control of identifying the key generated with -G, otherwise you have to generate the key and then query the key database and *assume* the CKA_ID of the last listed key is the one you generated. Not always a good assumption and subject to races.