If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

certutil capability: generate CSR from orphan private key



10 years ago
4 years ago


(Reporter: Nelson Bolyard (seldom reads bugmail), Unassigned)


(Depends on: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


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

Comment 1

10 years ago
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.
Priority: -- → P1
Target Milestone: 3.12 → 3.12.1

Comment 2

10 years ago

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.

Comment 3

10 years ago
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.

Comment 4

10 years ago

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. 

Comment 5

10 years ago
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).  


9 years ago
Priority: P1 → P2
Target Milestone: 3.12.1 → ---

Comment 6

4 years ago
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.
You need to log in before you can comment on or make changes to this bug.