[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs



Howard Chu wrote:
> Rich Megginson wrote:
>> Howard Chu wrote:
>>> rmeggins@redhat.com wrote:
>>>> Full_Name: Rich Megginson
>>>> Version: 2.4.23
>>>> OS: Fedora
>>>> URL:
>>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.patch 
>>>>
>>>>
>>>> Submission from: (NULL) (76.113.111.209)
>>>>
>>>>
>>>> MozNSS doesn't like self-signed CA certs that are also used for
>>>> TLS/SSL server certs (such as generated by openssl req -x509)
>>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that
>>>> case
>>>> so, see if the cert and issuer are the same cert, and allow the
>>>> use of it (with a warning)
>>>
>>> If you checked to see if the issuer is already trusted, I guess the
>>> patch is OK.
>>>
>>> But that aside, MozNSS's behavior sounds correct to me, and our
>>> documentation says to use explicit CA certs, separate from the server
>>> cert. Is it really a good idea to break this validation check?
>> Probably not, but openssl seems to allow it.  This provides parity with
>> the openssl implementation.
>>
>> This issue came up when testing openldap with NSS support in Fedora.
>> The Fedora package creates a self signed CA cert using openssl req
>> -x509.  This works with openldap+openssl, but fails with 
>> openldap+moznss.
>
> In the OpenSSL case, it only succeeds if the cert is configured as 
> both a CA cert and a server cert. I.e., the client must have been 
> configured to trust the cert already. I believe for your patch, it 
> should fail when CERT_FindCertIssuer() returns NULL. No?
You are correct.  I've uploaded a new patch.

URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714-2.patch <ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.patch>

Here is the diff between the two patches:
32,34c32
< +                                     /* no issuer - warn and allow */
< +                                     status = SECSuccess;
< +                                     rc = 0;
---
 > +                                     /* no issuer - fail */
36c34
< +                                                "TLS: warning: the 
server certificate %s has no issuer - "
---
 > +                                                "TLS: error: the 
server certificate %s has no issuer - "

>
>>> Also, where does this check occur in the main sequence of verification
>>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already
>>> been checked successfully?
>> Yes.  This check occurs in the cert chain processing, which is done 
>> last.
>
> OK.
>