169383 - Intermediate CA cert missing from SSL client auth cert chain

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[B DOREL]

High , I use mozilla 1.1 to browser to browse HTML pages sent by a tomcat server
the trouble is :

  when I set my server to authenticate the client the authencation fails
if I use IE or Netscape it succed .
  I set ssl debug option on the server :
    Mozilla case : when the client authenticate itself
it send just its certificate (not the complete certificate chain) the server
is not able to complete the chain up to the root CA so the trust validation
fails
    Netscape or IE case : when the client authenticate itself it send the 
certificate chain minus the root CA (remenber the server send the acceptable
CAs so the root CA is not necessary) the server complete the chain and 
trust the certificate 
  
  In my opinion the client authenticate succed in case of certicate chain 
with 2 levels : the root CA + the client Unfortunatly my certificate chain 
have 3 levels : the root CA + intermediate certificate autorithy + client

Cheers 

B DOREL

Comment 1

[Jamie Nicolson]

This is not a bug in JSS. Reassigning to NSS for evaluation.

Comment 2

[Wan-Teh Chang]

Nelson, could you take a look at this?  Thanks.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Submittor, 

Please attach base64 encoded copies of all the certs in the chain for your 
client auth cert, including the root CA cert, to this bug report.  Please 
do not include the private keys.

Is it the case that the missing intermediate CA cert has the same exact 
subject name as the root CA cert?  

If so, that is an invalid cert chain.  No issued cert should EVER have
the same exact subject name as the subject name in the cert for its 
issuer, unless it is a self-signed cert.   If your intermediate CA cert's
subject name is the same as the root CA's subject name, then the intermediate
CA cert's subject and issuer names are the same, which makes it a self-issued
cert (as defined in RFC 3280).  Any self issued cert is expected to be 
self-signed, and a root in any chain in which it appears.   

NSS now treats all self-issued certs as being the end of their own chains.
NSS will exclude the self-issued CA cert from the chain that it sends to 
the https server for client authentication.  

Cert chains that have multiple certs with the same exact subject name have
worked in past versions of NSS.  But they were always improper, IMO.  Whether 
or not NSS is changed to allow them again, the best solution IMO is to reissue
certs so that they do not have the same subject name as their issuer, unless
they truly are self signed root CA certs.  Also, Be sure not to reuse serial 
numbers when reissuing certs.  A valid CA never issues two certs with the
same serial number, and NSS depends on that.

Comment 4

[B DOREL]

Attachment: Client certificate

Comment 5

[B DOREL]

Attachment: Intermediate certificate

Comment 6

[B DOREL]

Attachment: Root ca

How can I set mozilla to trust (or not) an incoming certificate from
 a server automatically : my server have the same rootCA  
The server certificate is also signed by this certificate but 
mozilla ask me to check the incoming server's certificate when i 
connect the server.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Thank you for attaching your certs.  I see why the cert chain is short.

None of your certs (except the root) has the same name for the subject
and the issuer, so that hypothesis about the problem is disproven.

Here is the story.

Your intermediate CA cert has an Authority Key Identifier (AKI) extension
that contains a keyIdentifier AND an issuer-and-serial-number pair.
Your root CA cert has no Subject Key Identifier (SKI) extension.  Therefore
NSS 3.4 determines that it is NOT the issuer cert of the intermediate CA cert.

Versions of NSS prior to NSS 3.4 used the AKI extension as a hint to help
find the right issuer.  If a cert could be found that matched the AKI 
extension, then that cert was taken to be the issuer, otherwise, NSS fell
back on doing an ordinary match of subject name to the sought issuer name.

However, as I read it, beginning in NSS 3.4, the AKI extension is treated 
as an absolute matching requirement.  If the AKI extension is present, the 
issuer cert MUST match the AKI extension.  That means that if the AKI
extension contained a keyIdentifier, then the issuer cert MUST contain a
Subject Key Identifier (SKI) that matches that keyIdentifier.  If a cert
is found with matching name, but not matching identifier, then it is 
assumed not to be the issuer.  I cannot say, absolutely, that this new 
behavior is wrong, but if it is, then it is a regression in NSS 3.4.

NSS has a function CERT_CertChainFromCert that was rewritten in NSS 3.4.
When it is asked to omit the root cert from the chain, it used to only
omit the last cert if the last cert was really a root.  Now, it omits the 
last cert even if that is not a root.  That is definitely a regression.

Another observation about NSS's handling of an AKI extension: when an AKI 
extension contains both a keyIdentifer AND a pair of (issuer, serial number), 
NSS ignores the (issuer, serial number) pair and considers only the 
keyExtension field.  It has always done so; this is not a recent regression.
But if an AKI extension is supposed to help identify the right issuer, and is
not an absolute requirement, then it seems that NSS should search for a 
match on EITHER keyIdentifer OR (issuer, serial number).  And if the AKI
extension is an absolute requirement, and both parts are present, then it
seems that NSS should check for matches on BOTH keyIdentifier AND (issuer,
serial number).  

While we work out what NSS _should_ do, you can work around this by ensuring
that all the certs in your chain have Subject Key Identifiers, and that each
CA's SKI matches the KeyIdentifier field in the AKI extension in every cert
issued by that CA.

Comment 8

[Robert Relyea]

I believe this is a regression. The intention, I believe, was to maintain the
same semantics we had in NSS 3.3, and we should go back to that behavior.

The only exception would be if the PKI specs say we must match the AKI extension
if they exist.

bob

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

I think the code should do the right thing.  NSS 3.3 may have been closer 
to right than 3.4 is with respect to handling of key identifier extensions,
but I think even it was wrong.  I think we should meet about this ASAP.

This bug report now reports (at least) two errors:

1. CERT_CertChainFromCert now drops the last cert from the chain, even if
that last cert is not a self-issued root.  It should only drop the root
if it really is a root.

2. The correct handling of Authority Key Identifiers in finding issuer 
certs.  The subissues are:

2a: NSS now treats the keyIdentifier field in the AKI extension as a 
MUST HAVE to match an issuer.  Previously NSS would choose a cer that 
matched the AKI keyId, if one existed, but would still look for a match
on issuer name if not.

2b: NSS completely ignores the (issuer, serial) option pair in the AKI 
extension if the keyIdentifier option also is present.  That seems wrong.
If AKI is an absolute requirement, and both AKI options (keyID and issuer-SN)
are present, then both should have to match.  If AKI is a hint about finding
the right cert and both AKI options are present, and no match is found on
the keyIDentifier option, then the issuer-SN option should also be used to 
attempt to find the right cert.  

Perhaps this bug should be split into two bugs, and issue 2 above should go 
into a separate bug from this one.

Bob, I think this bug should be assigned to Ian or yourself.

Comment 10

[Ian McGreer]

taking bug

Comment 11

[Ian McGreer]

Nelson-

I believe (1) and (2b) are obvious bugs that should be fixed.

(2a) is a little more ambiguous.  The keyIdentifier field of the AKI extension
is opaque -- applications cannot assume a particular method for generating this
value, and therefore can't generate this value on-the-fly to check against an
issuer.  I think it's a bit confusing for a CA to issue certs with AKI
extensions, without setting the SKI extension in its own cert.  To me, the
presence of an AKI extension in a cert should indicate that there is a
*specific* CA cert issuer, and an issuer cert missing that specific identifier
is not the correct issuer.

Imagine the case where a CA begins with a signing cert with no SKI, decides
later on that SKIs are a good idea, issues a new signer cert with a SKI, then
signs certs containing a matching AKI for that SKI.  If a user had the first CA
cert but not the second, he would find that an end entity cert having the AKI
would incorrectly chain to the cert not having the SKI.

However, there is nothing in RFC 3280 that demands this behavior, and my opinion
doesn't amount to much.  I would consider this another case where NSS 3.3 was
not incorrect, so we should not change the behavior.

Comment 12

[Ian McGreer]

We should also consider this sentence from RFC 3280:

"The keyIdentifier field of the authorityKeyIdentifier extension MUST
   be included in all certificates generated by conforming CAs to
   facilitate certification path construction."

Also, regarding SKIs:

"To facilitate certification path construction, this extension MUST
   appear in all conforming CA certificates..."

The ambiguity created by having an end entity cert with an AKI and a CA cert
with no SKI is outside of the standard.

Comment 13

[Ian McGreer]

Substitute "outside of" with "not allowed by" in the last comment.

Comment 14

[Ian McGreer]

Attachment: patch to address all three issues

with regards to:

(1) The patch replicates the behavior of NSS 3.3.  If the last cert in the
chain is not self-issued (at least, the issuer and subject DN's are not
equivalent), the cert will be kept regardless of the value of the includeRoot
argument.  This is susceptible to the situation described in bug 157218, where
the issuer and subject DN's are equivalent, but the AKI is different than the
SKI.  However, that bug pertained to CERT_FindCertIssuer, and was a regression
from NSS 3.3.  The change in this patch will reproduce the NSS 3.3 behavior for
CERT_FindCertChain.  Will this be sufficient, or do we need to check the values
of the AKI and SKI extensions when includeRoot == PR_FALSE?

(2a) The requirement for the SKI extension when an AKI extension is present in
an issued cert is relaxed.  If the SKI extension is not present in a CA cert,
we will fall through to checking issuer/serial, and if that is not present, we
return nssCertIDMatch_Unknown.	I leave this as a separate case to signify that
we did not make a positive match, but we also did not have a mismatch.	The
result is ambiguous.  In this patch, we keep certs that match with
nssCertIDMatch_Unknown in the set of possible issuer certs.

(2b) The (issuer, serial) option of the AKI is now handled.  It will be used if
 <1> the AKI did not have a keyIdentifier value, or <2> the AKI had a
keyIdentifier value, but the CA's SKI is not present.

This patch will correctly chain the certs attached to this bug.

review invited.

Comment 15

[Ian McGreer]

Comment on attachment 100415 [details] [diff] [review]
patch to address all three issues


This patch is incorrect.  See bug 171224.

Comment 16

[Wan-Teh Chang]

Submitter, the fix for this bug has been checked in.
Could you please verify it with the latest Mozilla
trunk daily build?

Comment 17

[Ian McGreer]

I have tested this chain myself with beta3, marking fixed.