You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Kiran Ayyagari <ka...@apache.org> on 2012/10/23 08:09:16 UTC
[ApacheDS] adding a global trust manager
Hi All,
I am currently implementing an X509 trust manager that is used for
checking client certificates while using TLS for replication.
This trust manager can work in any one of the two modes
1. trust all (default mode)
2. trust only the specified certificates
In the 2 mode trust manager loads a set of certificates stored in
DiT under ou=certificates,ou=system (a new branch) [1]
and checks against this list. The certificate that is not present
in this list but is signed by a known CA will be trusted
automatically.
The initial idea is to use this trust manager only for replication
connections, but I would like to know your thoughts about using it
in StartTLS and LDAPS connections by default?
[1] am thinking of replacing the unused
prefNodeName=sysPrefRoot,ou=system branch with
ou=certificates,ou=system, please raise any
objections you may have w.r.t this change.
--
Kiran Ayyagari
http://keydap.com
Re: System partition removal was Re: [ApacheDS] adding a global trust manager
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On 23 oct. 2012, at 11:50, Emmanuel Lécharny <el...@gmail.com> wrote:
> I renamed the thread to avoid any confusion.
>
> Le 10/23/12 11:26 AM, Kiran Ayyagari a écrit :
>> On Tue, Oct 23, 2012 at 1:44 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
>>> Hi Kiran,
>>>
>>> On 23 oct. 2012, at 08:09, Kiran Ayyagari <ka...@apache.org> wrote:
>>>
>>> Hi All,
>>>
>>> I am currently implementing an X509 trust manager that is used for
>>> checking client certificates while using TLS for replication.
>>>
>>> This trust manager can work in any one of the two modes
>>> 1. trust all (default mode)
>>> 2. trust only the specified certificates
>>>
>>>
>>> Sounds cool. :)
>>>
>>> In the 2 mode trust manager loads a set of certificates stored in
>>> DiT under ou=certificates,ou=system (a new branch) [1]
>>>
>>>
>>> Sorry to hijack a little the original topic here, but I think its related.
>>> I really think we should get rid of the system partition, it has no use and
>>> the only interesting thing it still holds is the default/admin user.
>>>
>> we discussed about this several times, but later I started to think
>> that we should keep it
>>
>> let me state the reasons that support this in my view:
>>
>> o this serves as a play ground for users without having to go
>> through the creation of a partition
>> and multiple restarts before he can actually inject an entry and use it
>
> I do agree. If we remove the ou=system partition, then we will have to create a new partition for users who want to play with the server, without having to create a specific new partition.
We already have it, "dc=example,dc=com". It's already included in the default config file.
>> o parts of the system partition comes with default protection using
>> ACI and this is also a nice to
>> have in out of the box installation
We could probably apply the same ACIs to "dc=example,dc=com".
>> o the system partition is very tightly coupled with the internals
>> (though _can_ be changed it requires substantial
>> amount of effort)
Probably.
Should it forbid us to make any change to it or remove it, maybe not.
> Especially when it comes to change the many tests depending on it...
>
> But I don't think those two last points are valid : just because we depend on a partition which should not have existed at the beginning, we should not refrain of thinking about removing it.
>
> Now, the ou=system not only contains the configuration - which could (should ?) be in a separate partition - it also stores the ou=groups and ou=users branches. I guess many users are storing entries in those branches, removing it can impact severely those existing users.
I'm not really sure it's used by our users, as most of the docs refer to "dc=example,dc=com" when it comes to populate the DIT.
> One other thing : the prefNodeName=sysPrefRoot branch can probably be removed (see http://osdir.com/ml/dev-directory-apache/2010-05/msg00190.html)
>>
>>> Everything that is configurable (including the default/admin user) has its
>>> place in the configuration partition.
>>> That includes the certificates you're talking about.
> Certficates are not part of the server configuration, if you except the admin user. And here, if the admin user contains its own certificate, that's fine.
We are not talking about users certificates here, but certificates that are used by the server itself to communicate with other servers.
That's a really server-level configuration to me.
> Maybe we need to have a server certificate, which is not asociated with the admin user though...
>
>> other than the feature that it can be edited using a text editor am
>> really not comfortable with this
>> config LDIF partition, cause it is quite inefficient in the way it
>> handles updates, a complete re-write
>> after each modification is making it vulnerable to corruption (when I
>> try applying an ACI it takes way too long to
>> complete and leaves the partition corrupted if the process is killed
>> in the middle)
> We can differ the update on disk. Before using a LDIF partition, it was a JDBM partition. Having a corrupted JDBM partition was even worse := we weren't able to fix it at all ! With a LDIF partition, we can still use a text editor and fix what has been broken...
>
> Morever, I do think that the performances is not really an issue : we don't modify the configuration frequently, and this is not an operation you want to do on production before bing sure that you won't break the server, I don't really mind if we are at risk to break the server.
>
> In other words : this is an admin task, and the admin must me cautious before changing anything... Including backups !
>> The point am trying to make is adding certificates to this partition
>> makes the backing LDIF file grow in large size
>> making any modify operation even more slow.
> I agree with that.
Indeed, I agree too, but as Emmanuel said, this isn't something that's going change every minute.
>>> ATM, the default password is not included in the configuration and it makes
>>> it uncomfortable having to first launch the server to be able to edit this
>>> value.
>> currently the config.ldif is not written to disk unless the server is
>> started for the very first time
>
> We can discuss this specific problem in another thread. It would be way better if the admin password was not stored in clear anywhere... (currently it *is* stored as PLAINTEXT : it would be way better to _at least_ stored the hash value of it...)
>
>>> It would be the same thing for those certificates.
>>>
>> adding a certificate content in an LDIF entry is quite involved, I
>> would personally prefer the server to take care
>> of it instead of manually encoding and adding in config.ldif
I see no difference between adding it to an LDIF partition or to a JDBM partition.
In the end, to be user friendly, an application with an nice UI is required.
> Agreed. Certificates are stored as a byte[], and in LDIF, it's a base64 value. Note that it's note *taht* complicated to create the LDIF file : Studio can do it for you :)
Exactly. ;)
Having the certificates out of the configuration makes them totally not configurable with the ApacheDS Configuration plugin or the user editing the config.ldif file, and it adds two locations for configuration elements which will probably confuse most of our users...
To me, it looks bad from a user POV.
Regards,
Pierre-Arnaud
>>> I think the configuration partition should really be the place where we
>>> store everything that can be configured.
>>> Once that's done, the system partition has no reason to exist anymore
>>>
>>> WDYT?
>>>
>> hope I have made my view clear in the above lines about keeping the
>> system partition :)
>
> I would keep the ou=system partition around atm. It's not a big deal to have it, it's convenient for tests, and for users.
>
> I would rather suggest that we remove the ou=configuration,ou=system branch, it's most certainly useless.
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
System partition removal was Re: [ApacheDS] adding a global trust
manager
Posted by Emmanuel Lécharny <el...@gmail.com>.
I renamed the thread to avoid any confusion.
Le 10/23/12 11:26 AM, Kiran Ayyagari a écrit :
> On Tue, Oct 23, 2012 at 1:44 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
>> Hi Kiran,
>>
>> On 23 oct. 2012, at 08:09, Kiran Ayyagari <ka...@apache.org> wrote:
>>
>> Hi All,
>>
>> I am currently implementing an X509 trust manager that is used for
>> checking client certificates while using TLS for replication.
>>
>> This trust manager can work in any one of the two modes
>> 1. trust all (default mode)
>> 2. trust only the specified certificates
>>
>>
>> Sounds cool. :)
>>
>> In the 2 mode trust manager loads a set of certificates stored in
>> DiT under ou=certificates,ou=system (a new branch) [1]
>>
>>
>> Sorry to hijack a little the original topic here, but I think its related.
>> I really think we should get rid of the system partition, it has no use and
>> the only interesting thing it still holds is the default/admin user.
>>
> we discussed about this several times, but later I started to think
> that we should keep it
>
> let me state the reasons that support this in my view:
>
> o this serves as a play ground for users without having to go
> through the creation of a partition
> and multiple restarts before he can actually inject an entry and use it
I do agree. If we remove the ou=system partition, then we will have to
create a new partition for users who want to play with the server,
without having to create a specific new partition.
>
> o parts of the system partition comes with default protection using
> ACI and this is also a nice to
> have in out of the box installation
>
> o the system partition is very tightly coupled with the internals
> (though _can_ be changed it requires substantial
> amount of effort)
Especially when it comes to change the many tests depending on it...
But I don't think those two last points are valid : just because we
depend on a partition which should not have existed at the beginning, we
should not refrain of thinking about removing it.
Now, the ou=system not only contains the configuration - which could
(should ?) be in a separate partition - it also stores the ou=groups and
ou=users branches. I guess many users are storing entries in those
branches, removing it can impact severely those existing users.
One other thing : the prefNodeName=sysPrefRoot branch can probably be
removed (see http://osdir.com/ml/dev-directory-apache/2010-05/msg00190.html)
>
>> Everything that is configurable (including the default/admin user) has its
>> place in the configuration partition.
>> That includes the certificates you're talking about.
Certficates are not part of the server configuration, if you except the
admin user. And here, if the admin user contains its own certificate,
that's fine.
Maybe we need to have a server certificate, which is not asociated with
the admin user though...
> other than the feature that it can be edited using a text editor am
> really not comfortable with this
> config LDIF partition, cause it is quite inefficient in the way it
> handles updates, a complete re-write
> after each modification is making it vulnerable to corruption (when I
> try applying an ACI it takes way too long to
> complete and leaves the partition corrupted if the process is killed
> in the middle)
We can differ the update on disk. Before using a LDIF partition, it was
a JDBM partition. Having a corrupted JDBM partition was even worse := we
weren't able to fix it at all ! With a LDIF partition, we can still use
a text editor and fix what has been broken...
Morever, I do think that the performances is not really an issue : we
don't modify the configuration frequently, and this is not an operation
you want to do on production before bing sure that you won't break the
server, I don't really mind if we are at risk to break the server.
In other words : this is an admin task, and the admin must me cautious
before changing anything... Including backups !
> The point am trying to make is adding certificates to this partition
> makes the backing LDIF file grow in large size
> making any modify operation even more slow.
I agree with that.
>> ATM, the default password is not included in the configuration and it makes
>> it uncomfortable having to first launch the server to be able to edit this
>> value.
> currently the config.ldif is not written to disk unless the server is
> started for the very first time
We can discuss this specific problem in another thread. It would be way
better if the admin password was not stored in clear anywhere...
(currently it *is* stored as PLAINTEXT : it would be way better to _at
least_ stored the hash value of it...)
>> It would be the same thing for those certificates.
>>
> adding a certificate content in an LDIF entry is quite involved, I
> would personally prefer the server to take care
> of it instead of manually encoding and adding in config.ldif
Agreed. Certificates are stored as a byte[], and in LDIF, it's a base64
value. Note that it's note *taht* complicated to create the LDIF file :
Studio can do it for you :)
>> I think the configuration partition should really be the place where we
>> store everything that can be configured.
>> Once that's done, the system partition has no reason to exist anymore
>>
>> WDYT?
>>
> hope I have made my view clear in the above lines about keeping the
> system partition :)
I would keep the ou=system partition around atm. It's not a big deal to
have it, it's convenient for tests, and for users.
I would rather suggest that we remove the ou=configuration,ou=system
branch, it's most certainly useless.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] adding a global trust manager
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Oct 23, 2012 at 1:44 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> Hi Kiran,
>
> On 23 oct. 2012, at 08:09, Kiran Ayyagari <ka...@apache.org> wrote:
>
> Hi All,
>
> I am currently implementing an X509 trust manager that is used for
> checking client certificates while using TLS for replication.
>
> This trust manager can work in any one of the two modes
> 1. trust all (default mode)
> 2. trust only the specified certificates
>
>
> Sounds cool. :)
>
> In the 2 mode trust manager loads a set of certificates stored in
> DiT under ou=certificates,ou=system (a new branch) [1]
>
>
> Sorry to hijack a little the original topic here, but I think its related.
> I really think we should get rid of the system partition, it has no use and
> the only interesting thing it still holds is the default/admin user.
>
we discussed about this several times, but later I started to think
that we should keep it
let me state the reasons that support this in my view:
o this serves as a play ground for users without having to go
through the creation of a partition
and multiple restarts before he can actually inject an entry and use it
o parts of the system partition comes with default protection using
ACI and this is also a nice to
have in out of the box installation
o the system partition is very tightly coupled with the internals
(though _can_ be changed it requires substantial
amount of effort)
> Everything that is configurable (including the default/admin user) has its
> place in the configuration partition.
> That includes the certificates you're talking about.
>
other than the feature that it can be edited using a text editor am
really not comfortable with this
config LDIF partition, cause it is quite inefficient in the way it
handles updates, a complete re-write
after each modification is making it vulnerable to corruption (when I
try applying an ACI it takes way too long to
complete and leaves the partition corrupted if the process is killed
in the middle)
The point am trying to make is adding certificates to this partition
makes the backing LDIF file grow in large size
making any modify operation even more slow.
> ATM, the default password is not included in the configuration and it makes
> it uncomfortable having to first launch the server to be able to edit this
> value.
currently the config.ldif is not written to disk unless the server is
started for the very first time
> It would be the same thing for those certificates.
>
adding a certificate content in an LDIF entry is quite involved, I
would personally prefer the server to take care
of it instead of manually encoding and adding in config.ldif
> I think the configuration partition should really be the place where we
> store everything that can be configured.
> Once that's done, the system partition has no reason to exist anymore
>
> WDYT?
>
hope I have made my view clear in the above lines about keeping the
system partition :)
> and checks against this list. The certificate that is not present
> in this list but is signed by a known CA will be trusted
> automatically.
>
> The initial idea is to use this trust manager only for replication
> connections, but I would like to know your thoughts about using it
> in StartTLS and LDAPS connections by default?
>
>
> Sounds like a good idea to me.
>
> There's a related issue on the API as well (with some kind of a patch
> proposal).
> https://issues.apache.org/jira/browse/DIRAPI-72
>
> Regards,
> Pierre-Arnaud
>
> [1] am thinking of replacing the unused
> prefNodeName=sysPrefRoot,ou=system branch with
> ou=certificates,ou=system, please raise any
> objections you may have w.r.t this change.
>
>
> --
> Kiran Ayyagari
> http://keydap.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: [ApacheDS] adding a global trust manager
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Kiran,
On 23 oct. 2012, at 08:09, Kiran Ayyagari <ka...@apache.org> wrote:
> Hi All,
>
> I am currently implementing an X509 trust manager that is used for
> checking client certificates while using TLS for replication.
>
> This trust manager can work in any one of the two modes
> 1. trust all (default mode)
> 2. trust only the specified certificates
Sounds cool. :)
> In the 2 mode trust manager loads a set of certificates stored in
> DiT under ou=certificates,ou=system (a new branch) [1]
Sorry to hijack a little the original topic here, but I think its related.
I really think we should get rid of the system partition, it has no use and the only interesting thing it still holds is the default/admin user.
Everything that is configurable (including the default/admin user) has its place in the configuration partition.
That includes the certificates you're talking about.
ATM, the default password is not included in the configuration and it makes it uncomfortable having to first launch the server to be able to edit this value.
It would be the same thing for those certificates.
I think the configuration partition should really be the place where we store everything that can be configured.
Once that's done, the system partition has no reason to exist anymore
WDYT?
> and checks against this list. The certificate that is not present
> in this list but is signed by a known CA will be trusted
> automatically.
>
> The initial idea is to use this trust manager only for replication
> connections, but I would like to know your thoughts about using it
> in StartTLS and LDAPS connections by default?
Sounds like a good idea to me.
There's a related issue on the API as well (with some kind of a patch proposal).
https://issues.apache.org/jira/browse/DIRAPI-72
Regards,
Pierre-Arnaud
> [1] am thinking of replacing the unused
> prefNodeName=sysPrefRoot,ou=system branch with
> ou=certificates,ou=system, please raise any
> objections you may have w.r.t this change.
>
>
> --
> Kiran Ayyagari
> http://keydap.com
Re: [ApacheDS] adding a global trust manager
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Oct 23, 2012 at 1:21 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 10/23/12 8:09 AM, Kiran Ayyagari a écrit :
>
>> Hi All,
>>
>> I am currently implementing an X509 trust manager that is used for
>> checking client certificates while using TLS for replication.
>>
>> This trust manager can work in any one of the two modes
>> 1. trust all (default mode)
>> 2. trust only the specified certificates
>>
>> In the 2 mode trust manager loads a set of certificates stored in
>> DiT under ou=certificates,ou=system (a new branch) [1]
>
>
> Will it be a separate partition ?
>
no, this is just a branch under ou=system partition
>
>> and checks against this list. The certificate that is not present
>> in this list but is signed by a known CA will be trusted
>> automatically.
>>
>> The initial idea is to use this trust manager only for replication
>> connections, but I would like to know your thoughts about using it
>> in StartTLS and LDAPS connections by default?
>
> Well, usually, we fetch the certificate from the user entry, so we only have
> one place to store every piece of information relative to a user. Typically,
> there is no specific reason to not store the public key certificate of a
> user somewhere else than in the user's entry.
>
yeah, a common area where all trusted certificates are stored is much easier to
handle (assuming the case where not all user entries contain
certificates unless in a PKI like env.)
> Now, we can certainly imagine a situation where you want to gather may
> certificates in a simple place.
>
> Keep in mind we can also add an index on certificate (although we will have
> to write a specific matching rule to the associated comparator in order to
> avoid doing a plain byte[] comparison of certificates. I'm sorry, but here I
> have not enough knowledge to foresee all the consequences of such a
> modification, I hav to do my homework :)
>
> Anyway, this is certainly an area we have to investigate !
>
currently searching is not the main concern here, but I agree with your point
>>
>> [1] am thinking of replacing the unused
>> prefNodeName=sysPrefRoot,ou=system branch with
>> ou=certificates,ou=system, please raise any
>> objections you may have w.r.t this change.
>
> Well, I'd rather keep this branch, and create a new one atm. We can delete
> the prefNodeName later if needed.
>
> Btw, will it impct the configuration ?
>
no, this is branch is not in use anywhere except in some tests while
comparing the DNs of search results
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
--
Kiran Ayyagari
http://keydap.com
Re: [ApacheDS] adding a global trust manager
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 10/23/12 8:09 AM, Kiran Ayyagari a écrit :
> Hi All,
>
> I am currently implementing an X509 trust manager that is used for
> checking client certificates while using TLS for replication.
>
> This trust manager can work in any one of the two modes
> 1. trust all (default mode)
> 2. trust only the specified certificates
>
> In the 2 mode trust manager loads a set of certificates stored in
> DiT under ou=certificates,ou=system (a new branch) [1]
Will it be a separate partition ?
> and checks against this list. The certificate that is not present
> in this list but is signed by a known CA will be trusted
> automatically.
>
> The initial idea is to use this trust manager only for replication
> connections, but I would like to know your thoughts about using it
> in StartTLS and LDAPS connections by default?
Well, usually, we fetch the certificate from the user entry, so we only
have one place to store every piece of information relative to a user.
Typically, there is no specific reason to not store the public key
certificate of a user somewhere else than in the user's entry.
Now, we can certainly imagine a situation where you want to gather may
certificates in a simple place.
Keep in mind we can also add an index on certificate (although we will
have to write a specific matching rule to the associated comparator in
order to avoid doing a plain byte[] comparison of certificates. I'm
sorry, but here I have not enough knowledge to foresee all the
consequences of such a modification, I hav to do my homework :)
Anyway, this is certainly an area we have to investigate !
>
> [1] am thinking of replacing the unused
> prefNodeName=sysPrefRoot,ou=system branch with
> ou=certificates,ou=system, please raise any
> objections you may have w.r.t this change.
Well, I'd rather keep this branch, and create a new one atm. We can
delete the prefNodeName later if needed.
Btw, will it impct the configuration ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] adding a global trust manager
Posted by Kiran Ayyagari <ka...@apache.org>.
On Wed, Oct 24, 2012 at 12:04 AM, Stefan Seelmann
<ma...@stefan-seelmann.de> wrote:
> Hi Kiran,
>
> On 23.10.2012 08:09, Kiran Ayyagari wrote:
>> Hi All,
>>
>> I am currently implementing an X509 trust manager that is used for
>> checking client certificates while using TLS for replication.
>>
>> This trust manager can work in any one of the two modes
>> 1. trust all (default mode)
>> 2. trust only the specified certificates
>
> I'm not sure if 'trust all' mode should be the default because then it
> is likely that users will keep that setting in production.
>
yeah
>> In the 2 mode trust manager loads a set of certificates stored in
>> DiT under ou=certificates,ou=system (a new branch) [1]
>> and checks against this list. The certificate that is not present
>> in this list but is signed by a known CA will be trusted
>> automatically.
>
> How is the certificate mapped to the user's DN (e.g. for access
> control)? Do you plan to use the DN of the certificate as user's DN, or
> is there a mapping to the user entry?
>
no, the certificate is not mapped to a user's DN
> Another thing regarding 'signed by a known CA will be trusted': Do you
> mean all CA in the JDK's cacerts file? Or are the trusted CA
> certificates also stored in the new ou=certificates,ou=system branch and
> must be populated? I ask because these days it is hard to trust those
> cacerts CAs...
>
no, not duplicating them in the DiT, but the default CA certs that come with JRE
yes, hard to trust but this is atleast the base line to begin with the 'trust'
>> The initial idea is to use this trust manager only for replication
>> connections, but I would like to know your thoughts about using it
>> in StartTLS and LDAPS connections by default?
>
> Why not.
>
one issue is that clients cannot connect with a random self signed
cert anymore (assuming 'trust all' flag is turned off)
> Kind Regards,
> Stefan
>
--
Kiran Ayyagari
http://keydap.com
Re: [ApacheDS] adding a global trust manager
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
Hi Kiran,
On 23.10.2012 08:09, Kiran Ayyagari wrote:
> Hi All,
>
> I am currently implementing an X509 trust manager that is used for
> checking client certificates while using TLS for replication.
>
> This trust manager can work in any one of the two modes
> 1. trust all (default mode)
> 2. trust only the specified certificates
I'm not sure if 'trust all' mode should be the default because then it
is likely that users will keep that setting in production.
> In the 2 mode trust manager loads a set of certificates stored in
> DiT under ou=certificates,ou=system (a new branch) [1]
> and checks against this list. The certificate that is not present
> in this list but is signed by a known CA will be trusted
> automatically.
How is the certificate mapped to the user's DN (e.g. for access
control)? Do you plan to use the DN of the certificate as user's DN, or
is there a mapping to the user entry?
Another thing regarding 'signed by a known CA will be trusted': Do you
mean all CA in the JDK's cacerts file? Or are the trusted CA
certificates also stored in the new ou=certificates,ou=system branch and
must be populated? I ask because these days it is hard to trust those
cacerts CAs...
> The initial idea is to use this trust manager only for replication
> connections, but I would like to know your thoughts about using it
> in StartTLS and LDAPS connections by default?
Why not.
Kind Regards,
Stefan