Howard Chu wrote:
Rich Megginson wrote:
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.
OK, committed. Thanks for the patch.
And thank you for your help.
URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714-2.patchftp://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.