238146 - CERT_IsCACert() misidentifies v3 self-signed certs as CAs

Status: REOPENED

(NSS :: Libraries, defect, P3)

Description

[John G. Myers]

The fix to bug 178692 has caused a regression in PSM where it miscategorizes all
self-signed certs as Certificate Authorities.  Not all self-signed certs are
capable of signing other certs, thus are not CA certs.

Comment 1

[Wan-Teh Chang]

John, I think you meant the fix to bug 171224 has caused
this regression, right?

Comment 2

[John G. Myers]

Correct, it was the fix to bug 171224 that caused the regression.

Comment 3

[John G. Myers]

Attachment: Simplistic fix

Someone would also need to audit all the other calls to CERT_IsCACert() to
check whether or not they also want to test cert->isRoot

Comment 4

[Ian McGreer]

Not all self-signed certs are categorized as CAs.  Only those which do not have
extensions or trust settings restricting them from being CAs are.  The cert in
question must not have the basicConstraints or nsCertType extensions present, in
which case it is valid as a CA, even if that is not its intended usage.

Comment 5

[John G. Myers]

Per RFC 3280 4.2.1.10 paragraph 4, certificates that do not have a basic
constraints extension are not usable as CAs.  So certificates which omit both
the basicConstraints and nsCertType extensions are not valid for use as CAs.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

The cert in question is an X509 v1 cert.  As such, it has no extensions.
It cannot have a basic constraints extension.  Yet that does not mean that
it cannot be a CA cert or a root CA cert.  

NSS has always chosen to identify self-issued X509 v1 certs as root CA certs.
Indeed many of the trusted root CA certs are precisely self issued v1 certs.
Such certs may also be used for non-CA purposes, if they are trusted for 
those purposes, e.g. trusted as SSL "peers" or SMIME "peers".

The cited statement in RCC 3280 applies to X509 v3 certs.   It applies
to certs conforming to that profile.  V1 certs to not conform to the profile.
They are still widely used as root CA certs today, and are grandfathered in.  

The real issue, in this case, is that there is a software company whose
software produces self-issed self-signed v1 certs for SSL servers.  
Those certs always have serial number zero, by the way.  

Once the certs are marked as trusted for use as SSL peers, NSS has no
trouble with them ... until the user inevitably generates a second cert
with the same subject (and issuer) names, which also has serial number zero.
Then it runs afoul of thd duplicate issuer and serial problem.  

Comment 7

[John G. Myers]

CERT_IsCACert() will identify an extensionless v3 self-signed cert as a CA cert.
It should only do so for v1 and v2 certs.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

John, have you established that there are NO trusted v3 root CA certs 
that lack basic constraints?  

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 144459 [details] [diff] [review]
Simplistic fix

"We could do that, but it would be wrong."  R.M. Nixon

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

This bug doesn't block 178692, as the latter involves an X509 v1 cert.
This bug is low priority, since an X509 v3 cert without the relevant
extensions would be an invalid cert (unless it was a root CA cert), 
and any bug about such a cert would probably get closed as invalid.

Comment 11

[John G. Myers]

Of the current builtin CA certficates, "entrust.net Certification Authority
(2048)" lacks a basic constraints extension, but has a Netscape Certificate Type
extension indicating CA usage.  The remaining either have a basic constraints
extension or are v1.

X.509 v3 certs are permitted to lack the basic constraints (and NS cert type
extensions) when they are not intended to be used as CA certs.  So valid v3
non-CA certs will get miscategorized as CA certs.
 

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

If they are self-issued, and lack auth key ID extensions, yes it does.
Does PKIX allow self-signed, self-issued non-CA certs?

Comment 13

[John G. Myers]

I don't see how RFC 3280 prohibits self-signed certs or requires self-signed
non-CA certs to have either the Authority Key Identifer or Subject Key
Identifier extension.  Perhaps you could give a citation?