IIUC, you're reporting a difference output between the versions
- 3.28.4-1.2.el7_3
- 3.28.4-15.el7_4

That's surprising, because those versions don't have that much differences.

Using your attached example, I ran your scenario on two different computers, one having the older NSS 3.26, and one the newer NSS 3.33, and both produced idential output for me:

$ certutil -d dbm:. -O -n 'caSigningCert cert-pki-ca'
"CN=Cert Auth,O=FloAuth" [CN=Cert Auth,O=FloAuth]

  "caSigningCert cert-pki-ca" [CN=Certificate Authority,O=DOM-235.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM]

    "caSigningCert cert-pki-ca" [CN=Certificate Authority,O=DOM-235.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM]


Based on that, I have 3 comments:

(a) Given that you and I see different results wrt to the stability of this output, it would be interesting to get more results, produced using a greater set of NSS versions. Was this potentially a one-time change, that was already corrected in later upstream?

(b) The input to this command is ambiguous. With an ambiguous input, I believe there isn't any guarantee about the result set. I believe NSS has the right to become more complete, and extend its output with additional information. For example, the "certutil -L -n nickname" command may also print multiple certificates (IIRC) if there are multiple matches.

(c) You reported the difference, but you didn't give a justification why this would be a problem. Can you provide a business reason why a more extensive output would be problematic?

(In reply to Florence Blanc-Renaud from comment #3)
> Regarding (a):
> My bad, I am not able to reproduce this either with rhel 7.3


Please let's clarify what this means for this bug.

Does it mean, you confirm that the behavior hasn't changed?

(If correct, this isn't a regression bug. It's always important to know if a bug is a regression or something else.)


If the behavior hasn't changed and this isn't a regression bug, then your bug report means that you don't like the behavior of certutil.

Any change in behavior of certutil would have to be discussed upstream, get agreed upon, and implemented upstream.

Yes, it's not a regression.

I've read your comment 3.

IIUC, you're trying to use the NSS command line tools for advanced functionality. You want to correctly query the issuer/root certificates of a given input certificate, and use the result for further processing.

Your workflow apparently involves reusing the same nickname over time.

But you are using a tool interface that identifies certificates by nickname, which is ambigious in your environment, and therefore cannot result in precise results.

I think you cannot expect an environment to work, if you know the input to tools can be used in ambigious ways, and you indeed use workflows that involve ambiguity.

Ideally you should start to use unique nicknames for each certificate in your workflows.

Alternatively, maybe you need to develop your own tooling, based on the NSS C APIs, not based on the limited helper tools, to achieve what you need to have done.

Alternatively, if you believe this would help you, we could attempt to implement a more advanced parameter for identifying certificates by the tools. The standard key is "{issuer name, serial number}". If we invented a mechanism, that allowed you to provide issuer name and serial number, instead of the nickname, would that help you? You'd have to list all certificates, pick out the one you're looking for, extract the identifying key from that certificate, and then use that as the input parameter for tooling. This would avoid the ambiguity when requesting output from a tool, because you'd be able to precisely identify the certificate for which you are requesting information.

In my workflow, the certificate is the IPA CA certificate. It is possible to renew this cert with a different cert chain (for instance at install time it is a self-signed cert, then the customer prefers to use an externally signed cert and triggers a renewal with an ext CA). The first cert and the renewed cert are using the same private key. So far, no problem with certutil. Even though there are 2 certs with the same nickname, certutil -O displays the output adapted to the most recent cert (the ext-signed one).

Now if the customer decides to renew this cert a second time but as self-signed, the issue happens because certutil -O is ambiguous. IMHO when the db contains a cert and a renewed cert, certutil -O output should correspond to the most recent one, but I understand that this needs to be discussed with NSS team.

If I need to find the most recent cert corresponding to a given nickname in order to extract the issuer name and serial, the overhead is probably similar to adapting IPA code to handle the self-signed case and I don't really see an interest in the proposed mechanism (based on issuer name, serial number).

Thanks for explaining the expectations in more detail.

I looked at this again, and I see that -O always prints just one chain. It never attempts to display multiple chains, even if there are multiple matches. It attempts to find the best certificate, by using CERT_FindCertByNicknameOrEmailAddrCX, or falling back to PK11_FindCertFromNickname.

Then it proceeds to use CERT_CertChainFromCert to find the chain.

The output you reported (in the initial comment) probably means the following:

It identifies the self-signed certificate as the best match for your nickname, because it's the newest cert.

Then it attempts to find other certificates with the same issuer. There is one. It finds your older certificate, and it proceeds to display that and its chain.

Bob, what's your opinion on the expected behavior for CERT_CertChainFromCert, if it sees a self-signed cert?

Should NSS continue to search for potential other issuer certificates of a self-signed cert? (This is what it is currently doing, apparently).

Or is that a bug, and NSS should stop searching for issuers if it arrives at a self-signed cert (subject == issuer) ?

bump

So one could argue for either semantic. Part of the issue is what our various cert verification schemes do. The default verifier will always stop once it's found a self-signed cert. PKIX verifiers will check all the possible paths. There really isn't anyway for the library to know what the caller wants.

CERT_CertChainFromCert certainly shouldn't search for ever because a self-signed cert was presented.

The whole scenario, though sounds somewhat problematic. You have a self-signed leaf cert with the same subject as a root cert or an intermediate CA? In the same database? Sounds like a recipe for disaster anyway.

So what should we do here? Will NSS take this as an RFE to provide both options (ideally)?

IPA uses this to discover the CA chain of a given certificate and to ensure that the entire chain is available. While this switching back and forth between self and externally issued is unusual it isn't unprecedented.

Setting needs info - comment 14.

Re-reading and re-thinking about this bug. Let me summarize:

- you have databases that contain multiple certificates with the same
  subject name, old and new ones.

- some of the certificates are self-signed, others are externally signed

- all have the same nicknames

- when you use "certutil -O" to request information about the chain for one
  of those certs, indicated by nickname, and if the most recent one is
  self-signed, then the output includes information about the signers
  of an older cert.


In comment 11, I had made a suggestion, which I had hoped to be a simple solution. I had suggested to "don't show a chain if the best cert is self-signed" as the new default behavior.


Based on comment 13, I conclude my suggestion doesn't work in general. Because a smarter PKIX validator could potentially find a valid issuer certificate that has the same subject.

I understand Bob's comment as: The output of certutil -O should be the smartest that our default chain building code can do. Which means we probably shouldn't change the existing default behavior.


Rob suggested in comment 14 that we should implement both options, one simple option, and one smart option (the full PKIX option). But the PKIX implementation we have in NSS is on a path to get deprecated, because too many users have reported issues with it. Therefore I'm reluctant to implement an option that promises full PKIX chain lookup.

I'd rather prefer an option that promises that you get the simple behavior.

I understand IPA explicitly wants to request the simple beahvior: "Print the chain for the newest cert. Assume we are in a simple, non-PKIX path building world. If it's apparently a self-signed cert, because subject name and issuer name match, then don't attempt to resolve a chain."

We could implement this using a new parameter for -O:
  --assume-same-issuer-and-subject-is-self-signed

When this option is given together with -O, then certutil could compare subject and issuer, and if they match, don't lookup and don't print any chain, but only print the subject if the self-signed certificate.

Created attachment 1435035 [details]
patch v1

This patch implements an optional --simple-self-sign parameter for -O.

When executing this code against the attached DB, we get this output:

$ certutil -d dbm:. -O -n 'caSigningCert cert-pki-ca' --simple-self-signed
"caSigningCert cert-pki-ca" [CN=Certificate Authority,O=DOM-235.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM]

Would this enhancement solve your issue?

If yes, we can suggest this enhancement upstream.

Bob, would you be OK with this enhancement in general?

In short:

If the additional parameter --simple-self-signed is given, then "certutil -O" will only print the single cert, and not attempt to find a chain.

Hi Kai,

(in reply to comment #c17)
thanks for your proposal. The option would solve our issue and looks good to me.

This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:2237