openldap-devel

openldap-devel@openldap.org

1420 discussions

Status of ldap_init_fd and LDAP_PROTO_EXT?
by Volker Lendecke 15 Apr '17

15 Apr '17

Hi! What's the status of those two? They are mentioned in the manpages of for example Debian Jessie and FreeBSD 11 (maybe from ports?), but the manpage explicitly says you have to #include <ldap_pvt.h>, which is not shipped. What's the reason of them being in ldap_pvt.h? Are they supposed to change in the future? The function is now more than 10 years old, without too much change in that decade. Not being able to fully asynchronously connect to a server was my main reason to start my own little ldap library a few years ago, so I think this can be useful code :-) Thanks, Volker

1 0

ITSes to review for 2.4.45
by Quanah Gibson-Mount 14 Apr '17

14 Apr '17

The following ITSes look like candidates for 2.4.45, and have patches provided: 8427 8376 (Patch URL <ftp://ftp.openldap.org/incoming/howard-guo-160222.patch>) 8349 8037 7721 7520 (Patch no longer on dropbox, but Symas still has it available) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Storing TLS credentials in the directory
by Howard Chu 11 Apr '17

11 Apr '17

Quanah Gibson-Mount wrote: > --On Sunday, April 09, 2017 9:57 PM +0100 Howard Chu <hyc(a)symas.com> wrote: > >> You cannot write a decent design from scratch. It's important to have a >> baseline of functionality to get an idea of scope. The current overlay >> provides that baseline. > > Some immediate things I see after reading the man page for the current autoca > are: > > a) Not going to work well for databases that use "" as a suffix, and then > support multiple domains beneath that (Zimbra had many customers that did > this. One customer handled 10k unique top level domains.) > > b) Related to the above, importing CA's for those customer domains would fail > (because they aren't located in the suffix) I figured you would mention that. None of those are a target use case. If you're running infrastructure for a lot of different domains, you are probably already using some other full-blown CA. My primary use for this is quick setup within a single domain. Typically for private networks. No web browser is going to recognize an auto-generated CA cert, so it's not really suited for (nor intended for) certificates that will be used by a general public. > c) While there is an option to specify the keysize, there is no option to > specify the digest to use. There should be a note on what the default digest > is, and an option to use other digests. With Zimbra, we had a default of > sha256, and options of ripemd160, sha, sha1, sha224, sha256, sha384, sha512 Could add that. It uses whatever the OpenSSL default algorithm is, currently sha256. > d) I don't see a mechanism for creating star certs, which can be fairly > critical. I also don't see a mechanism for doing multiple DNS names, which > can be critical for a server with several CNAMES names. Again, unlikely for private setups. But if you can suggest an attribute that the overlay can read to retrieve multiple DNS names it could of course be added. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Storing TLS credentials in the directory
by Quanah Gibson-Mount 11 Apr '17

11 Apr '17

--On Sunday, April 09, 2017 9:57 PM +0100 Howard Chu <hyc(a)symas.com> wrote: > You cannot write a decent design from scratch. It's important to have a > baseline of functionality to get an idea of scope. The current overlay > provides that baseline. Some immediate things I see after reading the man page for the current autoca are: a) Not going to work well for databases that use "" as a suffix, and then support multiple domains beneath that (Zimbra had many customers that did this. One customer handled 10k unique top level domains.) b) Related to the above, importing CA's for those customer domains would fail (because they aren't located in the suffix) c) While there is an option to specify the keysize, there is no option to specify the digest to use. There should be a note on what the default digest is, and an option to use other digests. With Zimbra, we had a default of sha256, and options of ripemd160, sha, sha1, sha224, sha256, sha384, sha512 d) I don't see a mechanism for creating star certs, which can be fairly critical. I also don't see a mechanism for doing multiple DNS names, which can be critical for a server with several CNAMES names. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Storing TLS credentials in the directory
by Howard Chu 10 Apr '17

10 Apr '17

Michael Ströder wrote: > Howard Chu wrote: >> Turbo Fredriksson wrote: >>> Everything I’ve seen about the subject is so darn _complex_! It shouldn’t HAVE >>> to be. >> >> Indeed, there's no reason for it. > > Hmm, every time in a customer encryption/PKI project the customer requested that it > should be secure *and* easy to use. This is kind of a contradiction to begin with. Bootstrapping is usually the hardest part. That's the part I've focused on making easier. > > Also this short discussion already oversimplifys all the possible use-cases and > considerations when talking about storing/using/protecting private keys. Personally I'd > never use such a autoca overlay running on the "normal" directory server. (Over)simplification is exactly what is needed, most of the time. > So every technical design should start with a decent description of the use-cases or will > blatantly fail. This will lead to reviewing which name spaces have to be put in which > naming extension for which usage and who is authorized to use the keys and issue certs. > Simply starting with schema for private key storage is putting the cart before the horse. You cannot write a decent design from scratch. It's important to have a baseline of functionality to get an idea of scope. The current overlay provides that baseline. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

Re: Storing TLS credentials in the directory
by Howard Chu 10 Apr '17

10 Apr '17

Turbo Fredriksson wrote: > On 9 Apr 2017, at 17:55, Howard Chu <hyc(a)symas.com> wrote: >>> 2) What if I want a new certificate for that RDN? >>> Such as the previous one is [about to] expire and it needs to be >>> refreshed (preferably (?) without destroying/removing the old one). >> >> Currently you would have to delete the old one first. > > Ok, thanx. Not that big a’ deal I guess. I've noted this in the manpage now. > >>> 3) Is the CAs _public_ key available as well? >>> Same reason as point 1. >> >> If the overlay generated it, then it is stored in cACertificate;binary in the suffix entry of the database. > > Awesome! Update the man page about this as well then :) Done. > >>> 4) If I already have a CA “on premises” and that have created an >>> intermediate CA I’d like to use for “autoca”, could this be done? >> >> You can replace cACertificate;binary and cAPrivateKey;binary of the suffix entry to force this. > > I see, that’s quite smart! So they’re writable, not just read-only then. > This should probably also be documented. > > Is that true for userCertificate and userPrivateKey as well? Yes. Also noted in the manpage. If you're running git master, you can look at test066-autoca and see how it works. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Storing TLS credentials in the directory
by Howard Chu 09 Apr '17

09 Apr '17

Turbo Fredriksson wrote: > On 9 Apr 2017, at 14:24, Howard Chu <hyc(a)symas.com> wrote: > >> Please read the slapo-autoca(5) manpage for more info. > > This is exactly how easy I’m envisioning this to be! Brilliant, thanx! > > So if I’m understanding this correctly, all you have to do to request > a certificate for a specific object, is to read the “userPrivateKey;binary” > of that RDN? You must request exactly two attributes, otherwise the overlay ignores it: userCertificate;binary userPrivateKey;binary > Now, I know it’s well to early for feature requests :D, but I have a few > questions (and a feature request :): > > 1) Why is both certificates (private AND public) in the same attribute? > I can see the reason to have the public … “public” (with a much > more relaxed ACL/ACI). They aren't, they are in two separate attributes. > 2) What if I want a new certificate for that RDN? > Such as the previous one is [about to] expire and it needs to be > refreshed (preferably (?) without destroying/removing the old one). Currently you would have to delete the old one first. > 3) Is the CAs _public_ key available as well? > Same reason as point 1. If the overlay generated it, then it is stored in cACertificate;binary in the suffix entry of the database. > > 4) If I already have a CA “on premises” and that have created an > intermediate CA I’d like to use for “autoca”, could this be done? You can replace cACertificate;binary and cAPrivateKey;binary of the suffix entry to force this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Storing TLS credentials in the directory
by Howard Chu 09 Apr '17

09 Apr '17

One of the things that has been a long-standing obstacle to the automatic CA code is the fact that there's no LDAP syntax/matchingrule/attributes for storing private keys in the directory. There's schema for storing userCertificate and cAcertificate, but not the corresponding keys. This is also a stumbling block for being able to configure TLS directly in cn=config, instead of using separate files. Currently the autoca overlay defines a syntax and matching rule for use with private keys but this needs to move into the core code so that back-config can also use it. At this point I need to pick an OID arc for it, which prompted me to troll thru all the existing OID assignments. It's clear that nobody in the standards organizations considers storing private keys in the directory to be a safe thing to do. IMO this is just a matter of password security and good ACLs, and the standards should not preclude the option. It is no worse than storing userPassword. Comments? openldap-commit2devel(a)OpenLDAP.org wrote: > A ref change was pushed to the OpenLDAP (openldap.git) repository. > It will be available in the public mirror shortly. > > The branch, master has been updated > via 79284a06d3bea085ed92f17f2a2b5a15746f83a0 (commit) > via 2012795d3b1a29913e9f3a5b3a35d40fd8f5f903 (commit) > via b402a2805f8b96d2751a7315ea5e70e5082965ed (commit) > from 2b920ecaecc2e4858a33d0c8151bcf3b3d71cadd (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log ----------------------------------------------------------------- > commit 79284a06d3bea085ed92f17f2a2b5a15746f83a0 > Author: Howard Chu <hyc(a)openldap.org> > Date: Sun Apr 9 03:55:01 2017 +0100 > > Catalog of assigned OID arcs > > With some specific elements as well, but not exhaustively listed. > Patches welcome. > > commit 2012795d3b1a29913e9f3a5b3a35d40fd8f5f903 > Author: Howard Chu <hyc(a)openldap.org> > Date: Sun Apr 9 02:21:06 2017 +0100 > > Add config support for binary values > > Use base64 for .conf files, straight binary for back-config > > commit b402a2805f8b96d2751a7315ea5e70e5082965ed > Author: Howard Chu <hyc(a)openldap.org> > Date: Sun Apr 9 00:13:42 2017 +0100 > > Add options to use DER format cert+keys directly > > Instead of loading from files. > > ----------------------------------------------------------------------- > > Summary of changes: > doc/devel/OIDs | 69 ++++++++++++++++++++++++++++++++++++++++++ > include/ldap.h | 3 ++ > libraries/libldap/ldap-int.h | 6 ++++ > libraries/libldap/tls2.c | 34 ++++++++++++++++++++- > libraries/libldap/tls_o.c | 56 +++++++++++++++++++++++++++++++--- > servers/slapd/bconfig.c | 13 +++++++- > servers/slapd/config.c | 34 +++++++++++++++++++-- > servers/slapd/config.h | 2 ++ > 8 files changed, 208 insertions(+), 9 deletions(-) > create mode 100644 doc/devel/OIDs > > > --- > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Storing TLS credentials in the directory
by Howard Chu 09 Apr '17

09 Apr '17

Turbo Fredriksson wrote: > On 9 Apr 2017, at 11:29, Howard Chu <hyc(a)symas.com> wrote: > >> Turbo Fredriksson wrote: >>> On 9 Apr 2017, at 04:06, Howard Chu <hyc(a)symas.com> wrote: >>> >>> Only difference might be that the local FS isn’t available _outside_ the host, a directory >>> is. >> >> As soon as a host offers something like ssh, then that distinction is gone too. > > True. > >> Moreover, a secure mechanism for distributing private keys to users is required but nobody >> ever specifies how to do that. Certainly LDAP/TLS is more manageable than sneakernet and >> this is more bootstrappable. > > Yeah, I’ve been struggling like crazy about this the last couple of months. > > There’s many scripts and some products that can be/handle a CA, but > no one seems to have thought about the actual distribution of the result(s). > > Or how to restrict queries, distribution and what type of cert is/can be requested. > > And every link I’ve ever seen about certs, “then copy it securely to the > destination”. But no wording on HOW to do that or how to script it (in a > more .. “automated” fashion). > > Everything I’ve seen about the subject is so darn _complex_! It shouldn’t HAVE > to be. Indeed, there's no reason for it. > So if you can do something like this, and leave the ACL/policies etc to the admin, > using existing functionality (ACL/ACI/ppolicy or whatever), I’d be a very happy man! :) This is coming along now... > > Are you actually talking about OpenLDAP being a “CA” as well? As in, being able > to create certificates by requests, or are you talking about OpenLDAP “only” > being the … “backend-storage” for such a tool? The autoca overlay turns slapd into a CA. It can generate certificates for any users (and servers) in the directory. Please read the slapo-autoca(5) manpage for more info. For bootstrapping purposes I'm now extending back-config to be able to use certificates/keys stored directly in cn=config. The autoca overlay will be extended to store its generated CA cert in cn=config, so that a slapd can immediately support TLS as soon as the overlay is used (without requiring restarts). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 4

Re: Storing TLS credentials in the directory
by Howard Chu 09 Apr '17

09 Apr '17

Turbo Fredriksson wrote: > On 9 Apr 2017, at 04:06, Howard Chu <hyc(a)symas.com> wrote: > >> It's clear that nobody in the standards organizations considers storing private keys in the directory to be a safe thing to do. IMO this is just a matter of password security and good ACLs, and the standards should not preclude the option. It is no worse than storing userPassword. > > I agree (fwiw). > > > It needs to be stored SOMEWHERE. Usually it’s in/on the filesystem. And the only two (?) > things that protect it there is: > > 1) The access permissions on the file. I.e., “ACLs". > 2) No/limited users allowed on the system. I.e., "password security" (?) > > So using “ACLs" and "password security" on the filesystem or in the directory, shouldn’t be > that different. > > Only difference might be that the local FS isn’t available _outside_ the host, a directory > is. As soon as a host offers something like ssh, then that distinction is gone too. Moreover, a secure mechanism for distributing private keys to users is required but nobody ever specifies how to do that. Certainly LDAP/TLS is more manageable than sneakernet and this is more bootstrappable. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel