I'm trying to debug a validation failure when using
CERT_VerifyCertificate(). The cert being validated is a SSL Server Cert,
it is signed by a root cert. I have confirmed the server cert validates
using CERT_VerifyCertificate() in a stand alone program an the root cert
imported and trusted into an NSS database. I've also confirms it
validates with openssl verify.
The problem seems to come when the cert is used in an SSL handshake (in
this particular instance when the openldap libary is making a TLS
connection to an openldap server (the openldap library is using NSS,
e.g. tls_m.c).
Stepping through CERT_VerifyCertificate as called by the openldap
library I have found where verification failure occurs. First also let
me say that I've also run the connection through the NSS ssltap tool and
I can see that the server is sending the client 2 certs, the server cert
and the root ca cert that signed it. Hence during the connection attempt
there is cert chain of length 2.
The verify failure occurs cert_VerifyCertChainOld() in this code:
> /* make sure that the issuer is not self signed. If it is, then
> * stop here to prevent looping.
> */
> if (issuerCert->isRoot) {
> PORT_SetError(SEC_ERROR_UNTRUSTED_ISSUER);
> LOG_ERROR(log, issuerCert, count+1, 0);
> goto loser;
> }
This suggests to me that NSS will not accept a cert chain with the root
cert in it. Is that correct?
My understanding (and verified via some additional research) is that
while it's not optimal/common to include the root cert in the chain it
is in fact permissible. The basic idea I believe is the root cert in the
chain is ignored and previous cert in the chain is validated by finding
the root issuer in the trust store. Yes/No/Comments?
The stand alone validation succeeds apparently because there is no chain
to traverse with a root cert in it.
Is NSS behaving incorrectly by rejecting a chain with a root cert?
Is the server behaving incorrectly by sending a chain with a root cert?
What causes a root cert to be included in a chain?
Any suggestions, comments, or insights which will help me get around the
problem?
P.S.: The certs are generated with GNUtls, There seem to be some
oddities in the certs, for instance the server cert includes a
BasicConstraints extension with the CA flag set to False, it doesn't
seem to be creating a problem for NSS during validation. The CA cert
also has BasicConstaints but with the CA flag set to true and path
length set to 2. Not sure if this is relevant to this issue or not.
--
John
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
