[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: X509_V_FLAG_PARTIAL_CHAIN support in OpenLDAP
Doug Leavitt wrote:
Sorry for the delay. I needed to do some due diligence before responding.
On 06/06/15 13:35, Howard Chu wrote:
Doug Leavitt wrote:
Hi,
OpenSSL now has X509_V_FLAG_PARTIAL_CHAIN support in the code base as of
1.0.2a.
I would like to submit a patch to enable X509_V_FLAG_PARTIAL_CHAIN support
in OpenLDAP libldap, assuming it exists in the version of OpenSSL being use to
build
OpenLDAP.
What's the use case? It appears that the feature has been in OpenSSL since
around 2012, but I don't see much documentation or chatter about it. Why is
it useful, and do GnuTLS and MozNSS already support a similar feature?
The use case is:
You have a certificate issued by a CA:
rootCA -> mysystem
You don't want to trust all of the certificates issued by that CA. You only
want to trust that particular certificate.
"You" is too ambiguous here. Does the server carry a partial trust chain in
its config, or does the client?
Pretty sure adding this feature will break compatibility with default OpenSSL
installs. We already went thru this headache for GnuTLS.
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5991
Normal practice for servers is to trust only a single CA chain - the one that
issued its own cert and all the client certs that it intends to honor.
Normal practice for clients is to trust multiple CA chains, assuming the
client is used with multiple servers owned by disparate admin authorities.
(Or, if only used in one administrative context, just a single chain.)
So far it looks to me like you want to support broken server configurations.
I recognize the desire to only trust the immediate superior CA of an end
entity's own cert; that sort of makes sense. But certs can only be trusted if
you also trust their issuer, you cannot make valid assertions about a cert if
you don't follow the chain all the way back to a self-signer (which you also
explicitly trust).
Also if you only want to trust the 1-level superior of a particular cert, you
probably should not have been using commercial/3rd-party CAs in the first
place. Clearly in the scenarios you've outlined, the fact that someone paid
for a cert from a well-known commercial root CA is irrelevant here. They would
have been better off creating their own CA cert and using it to create their
end entity certs.
All of this smells of worst-practice to me.
OpenSSL by default ignores trust-list entries that are not for root CAs.
Adding just the "mysystem" certificate has no effect. With this change, you
can add the "mysystem" certificate and that will cause OpenSSL to accept this
certificate, even though the trust list does not include the CA's root
certificate.
A more complex case:
rootCA -> mycompanyCA -> mysystem
You don't want to trust all of the certificates issued by that CA. You only
want to trust certificates issued by your company's CA. Again, OpenSSL by
default will not let you trust an intermediate CA. With this change, you can
add mycompanyCA's certificate and that will cause OpenSSL to accept
certificates signed by your company CA.
The reason this is coming up now, is that the old Mozilla libldap/NSS
combination supported this by default but the combination of OpenLDAP/OpenSSL
currently does not. We first discovered the issue back in 2012 and realized
that OpenSSL did not support partial chains. Working through our security team
the project that discovered the issue convinced the OpenSSL upstream to add
the X509_V_FLAG_PARTIAL_CHAIN support so that eventually we could find a way
to incorporate that support back into OpenLDAP.
Additionally we have since uncovered some programs that depend on this Mozilla
functionality and we would like to see it supported in the OpenLDAP/OpenSSL so
those applications can finish moving off Mozilla libldap/NSS.
Moving forward to today it looks like OpenSSL has the support, disabled by
default, and both GNUTLS and NSS have the support for partial chains enabled
by default.
In GNUTLS, the support is here:
https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/verify.c#L868
In NSS the support is here:
http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/certvfy.c#532
where intermediate certificates are processed (with the final decision at
557), and that leaf certificates are handled at
http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/certvfy.c#916
In OpenSSL the support is disabled by default here:
https://github.com/openssl/openssl/blob/master/crypto/x509/x509_vfy.c#L819
Our hope is to have OpenLDAP/OpenSSL be either on par with OpenLDAP/NSS and
OpenLDAP/GNUTLS or at least have the option of be on par without having to
maintain a downstream code fork.
The code change itself is simple. At a minimum it is as simple as adding:
#ifdef X509_V_FLAG_PARTIAL_CHAIN
/*
* Allow intermediate or leaf certificates in the trust list to
* act as trust anchors.
*/
X509_STORE_set_flags(SSL_CTX_get_cert_store(ctx),
X509_V_FLAG_PARTIAL_CHAIN);
#endif
after:
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/libldap/tls_o.c;h=5d2367c6c1cc1e45707dbd070dadf88a556f8d74;hb=HEAD#l381
From our investigation always adding the support does not seem to be harmful
in any way and maintains compatibility with some existing software.
Hence the original question.
Thanks in advance for your consideration,
Doug.
Before I submit any patch I would like to know that would be acceptable
for integration.
Should support always be enabled if the version of OpenSSL has it
e.g. ifdef on X509_V_FLAG_PARTIAL_CHAIN
Should it be a config time option check and ifdef enable if found in
e.g. like the ifdef on HAVE_OPENSSL_CRL
Are there more requirements that is required in the patch, before it would
be accepted such as ldap_set_option support?
Thanks in advance,
Doug.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/