413949 - certutil should better support multiple certs with the same subject

Status: NEW

(NSS :: Tools, enhancement, P5)

Description

[Julien Pierre]

There are many commands today in certutil that only take a nickname (alias for subject name) to select a certificate. Sometimes this is not sufficient, as there can be multiple certs with the same subject available.

The list of commands with this problem includes :

-V (verify)
-O (print chain)
-M (modify trust)
-L (list certs). Right now, this command prints all certs with the given subject. But there is no way to select a particular one
-D (delete certificate).

We need to decide how we want to fix this. I propose to add additional arguments to those commands to filter and differentiate the certs.

I think most likely, adding an optional serial number argument will be sufficient. However, technically, it's valid PKI for two certs to have the same subject as well as the same serial number, if they have different issuers. So for the sake of completeness, we could also add an optional issuer nickname argument to these commands.

Bob, Nelson, what do you think of this proposal ?

Comment 1

[Julien Pierre]

Actually it would have to be an optional issuer subject name argument, since the issuer cert may not be present ...

Comment 2

[Julien Pierre]

I propose to add the following optional arguments to those certutil commands mentioned above in comment 0 :
a) --sn <serialnumber>
b) --issuernickname <nickname>
c) --issuersubject <subject>

The user would still have to specify -n nickname. Those would be additional optional switches to select the particular cert.

In practice, only a) is probably really necessary. It's not very likely to have 2 certs with the same subject, serial number, and different issuers. But it's legal.

One of the issues with implementing a) is that we don't have functions to convert large serial numbers to/from DER. In RFC3280 the serial numbers can be up to 20 bytes - 160 bits. I think we can do the conversion for 32 bits and perhaps 64 bits with the current code, but no more.

b) is necessary if we find ourselves in that exceptional case where we have 2 certs with the same subject, same serial numbers, but 2 different issuers

c) is necessary if we find ourselves in that exceptional case where we have 2 certs with the same subject, same serial numbers, but 2 different issuers, and we don't have the issuer cert in the database

b) and c) would be mutually exclusive.

As far as implementation, I would probably create one function in cmd/lib that takes the cert nickname, serial number, issuer nickname, and issuer subject. Then, I would replace the calls to PK11_FindCertFromNickname in certutil with a call to that function. I notice that sometimes certutil also calls CERT_FindCertByNicknameOrEmailAddr . I'm not sure why. But these calls may need to be replaced as well.

Bob, Nelson, Please give me some feedback about this proposal before I start implementing it.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

AFAIK, no professional CA issues certs with serial numbers that would fit in
32 bits.  I think the serial number should probably be input in hex.

Also, there should be no ambiguity.  There is another certutil option for
specifying serial numbers when generating certs.  I think there should not 
be TWO options that both mean "specify a serial number with this option".
There would be no end of bugs from confused users who used the wrong one.

Comment 4

[Julien Pierre]

Nelson,

We can reuse -m serialnumber for the purposes here. I don't know if that takes hex right now and what the limitation is on size.
What about the other parts of my proposal ?

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

The existing -m option takes an input number that is interpreted by atol 
(IIRC), so it can be decimal or hex, but is limited to 32 bits. 

The other ideas are OK, but IMO, this is low priority.  We need to devote 
our efforts to the NSS 3.12 features already committed.

Comment 6

[Julien Pierre]

Well, this came up in the context of an escalation, so I don't think it should be low priority. Also, these features would be useful for PKIX testing even if they are not vital.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Unsetting target milestone in unresolved bugs whose targets have passed.

Comment 8

[Lucas Yamanishi]

To add a use case, I'm trying to implement certificates stored in the cert DB as a Puppet resource type.  To do that I need a consistent way to manage them as data objects.  Using the nickname works most of the time, but I've run into this multi-cert-single-subject issue for some intermediate CAs.

My pain-point started with `-A` (Add certificate to a database).  At present if multiple certificates with the same subject are added, the nickname option is honored only for the first certificate.  Subsequent certificates take the nickname of the first certificate.  After reading through this ticket and #749242, I understand that is by design-- the nickname is just an alias to the subject.

I think that is the real problem, though.  Intuitively to me it feels like individual certificates should be the atomic unit, not subjects.  The subject is just an attribute of the data blob.  I suppose in the context of the PKIX the certificate is just an attribute of the subject, but the nickname could still be independent.

That said, adding serial-number and issuer-subject options would probably be enough to satisfy my use case, although it would be more complicated for me than relying solely on the nickname.

Comment 9

[Julien Pierre]

Lucas,
AFAIK, adding serial-number and issuer-subject (and/or issuer-nickname) should satisfy every possible legal PKI use case.

Comment 10

[Robert Relyea]

I believe pkcs #11 url support fixes this issue. You can ask for any pkcs #11 object (including certs) by their attributes Issuer and serial-number are supported attributes.

Comment 11

[Dan Kerse]

Perhaps updating the documentation would help to include some pkcs #11 examples including referencing the serial number.

One common use case not covered in the certutil documentation is when you want to delete an expired or soon to expire certificate and associated key from the database, where a more recently issued certificate + key exists with the same nickname.

In my experience the following command will blatantly disregard the key-id and remove the more recent certificate + key.

 certutil  -F -n <common-nickname-shared by old-and-new-certificate> -k <key-id-of-soon-to-expire-certificate> -d <cert-dir>

When this happens as a clean-up activity during the a certificate renewal process the user must then start from scratch - i.e. generate yet another certificate signing request and go back to the CA to request another new certificate.