You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Stefan Zoerner <st...@labeo.de> on 2008/12/17 21:37:44 UTC
[ApacheDS] Setting up my own certificate for SSL
Hi all,
I am facing some problems with the current (since 1.5.3, I assume) SSL
configuration. In earlier days, it was possible to provide a keystore
with the public/private key, certificate etc. here
http://cwiki.apache.org/confluence/display/DIRxSRVx11/3.3.+How+to+enable+SSL
Now, the server creates a keypair when it starts the first time and
stores it in the entry uid=admin,ou=system, in different attributes.
To be honest: This is an example why our documentation is so bad. The
old behavior has been well described in the docs. Someone changed it
completely, and did not update the docs. Same situation holds true for
the whole configuration. :-(
Nevertheless, the new SSL functionality seems to be simpler, because it
is possible to set it up automatically. But if I plan to use a custom
certificate, it should be at least possible. Today, there was a
corresponding question on the user list.
I wanted to update the docs to reflect the changes, and I am still
trying to figure out, what an easy way for our users would be.
A question for the current implementation: Is there any way to
configure/influence the key creation at startup? I assume no, but
perhaps I am missing something.
Currently, the only way to set up my own certificate is modifying the
attribute values for uid=admin,ou=system
This is not an easy task, because we do not have any tools for that.
There is no wizard in Studio yet. Even if there would be one -- it
should be possible without a UI client, ...
I was able to store my private key, but I am a little bit confused about
some attribute. What exactly is contained in userCertificate and what in
publicKey?
I assume, userCertificate holds the certificate the server presents to
client. But why do we need publicKey as well. I think it is contained in
the userCertificate. No?
Thanks in advance and Greetings from Hamburg,
Stefan
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Emmanuel Lecharny <el...@gmail.com>.
Stefan Seelmann wrote:
> Hi Stefan,
>
> Stefan Zoerner schrieb:
>
>> Hi all,
>>
>> I am facing some problems with the current (since 1.5.3, I assume) SSL
>> configuration. In earlier days, it was possible to provide a keystore
>> with the public/private key, certificate etc. here
>>
>> http://cwiki.apache.org/confluence/display/DIRxSRVx11/3.3.+How+to+enable+SSL
>>
>>
>> Now, the server creates a keypair when it starts the first time and
>> stores it in the entry uid=admin,ou=system, in different attributes.
>>
>> To be honest: This is an example why our documentation is so bad. The
>> old behavior has been well described in the docs. Someone changed it
>> completely, and did not update the docs. Same situation holds true for
>> the whole configuration. :-(
>>
>> Nevertheless, the new SSL functionality seems to be simpler, because it
>> is possible to set it up automatically. But if I plan to use a custom
>> certificate, it should be at least possible. Today, there was a
>> corresponding question on the user list.
>>
>> I wanted to update the docs to reflect the changes, and I am still
>> trying to figure out, what an easy way for our users would be.
>>
>> A question for the current implementation: Is there any way to
>> configure/influence the key creation at startup? I assume no, but
>> perhaps I am missing something.
>>
>
> I have no idea. The only direction I could point you to the class where
> the initial private key and certificate are created, see [1].
>
The KeyStore is created at startup :
Provider provider = Security.getProvider( "SUN" );
LOG.debug( "provider = {}", provider );
CoreKeyStoreSpi coreKeyStoreSpi = new CoreKeyStoreSpi(
getDirectoryService() );
KeyStore keyStore = new KeyStore( coreKeyStoreSpi, provider,
"JKS" ) {};
try
{
keyStore.load( null, null );
}
catch ( Exception e )
{
// nothing really happens with this keystore
}
chain = LdapsInitializer.init( keyStore );
(this is in LdapService.start() method).
I don't know how good it is to specifically use the "SUN" security
provider compared to any other (Bouncy Castle or whatever), and I'm
pretty sure that many users would like to use their own pre-existing
keystores.
This is an area where we are lacking expertise, that's for sure. I wish
we can have a better SSL handling for the upcoming 1.5.5 version, and
I'm ready to spend some times on that in te next two weeks, but I would
also appreciate any help, as I'm not a specialist in java security...
>
>> Currently, the only way to set up my own certificate is modifying the
>> attribute values for uid=admin,ou=system
>>
>> This is not an easy task, because we do not have any tools for that.
>> There is no wizard in Studio yet. Even if there would be one -- it
>> should be possible without a UI client, ...
>>
>
> You are right, if we create some tooling we should put all common code
> into the shared libraries, and then create a wizard for studio and a
> CL-tool.
>
Kiran is proposing to work on this CL tool, I think it's a good idea. An
d for sure it _must be available in studio and a as CL, with a common part.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Alex Karasulu <ak...@gmail.com>.
Hi Emmanuel,
On Tue, Dec 23, 2008 at 4:24 AM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Alex Karasulu wrote:
>
>> I agree with you. You're right that this is not the best solution for our
>> users currently. I'm thinking that we should run faster into the future
>> with the tooling to support cert management in the DIT rather than
>> reverting
>> back to the use of the keystore file.
>>
>> When you scratch the itch with the keystore file no one will come to the
>> table to really create the tooling. Once the pressure is gone, the
>> advance
>> will never happen. Let the users complain. Let them also get involved and
>> affect change is what I say.
>>
>>
> As much as I agree with you on the global imagine, I think that we should
> also allow 'antiquated' users to play with there keystore file, if it's just
> a matter of a few lines of code to be injected in the server (and so far, it
> costed me less than an hour to restore those lines). Writing the tooling to
> store a certificate at the right place in the DiT, plus all the associated
> tests, will cost a couple of days.
>
> I don't have time for more than that right now, and if you consider that
> the current documentation tells the users how to use the keystore, that also
> mean to update the documentation.
>
> On a more general base, I think that Stefan and Christine, plus a few
> others, have spent a considerable amount of time writing this doco, and we
> should respect this effort.
Absolutely, I respect this very much. My suggestions are not intended to
disrespect their dedication to the documentation pages, I apologize if my
comments insinuated that in any way.
That mean we should check the current doco to see if we will outdate it when
> doing some modification on the server, and if so,n immediately reflect the
> change in the doco.
> Now, this is not easy too, as we are always working on new features which
> will be released days or even weeks (months ?) after, so the doco will
> _never_ reflect the next version, or if it does, users won't have the
> current version doco. Unless we find a way to have versionned documentation.
>
> Kiran proposed to work on the tooling, and I think it will solve everthing,
> but it will take time. Hopefully, we will have them for 1.5.5, but this is
> not guaranteed...
OK this is not that much a big deal. I just wanted my view point to come
across with ample consideration. Seeing how I've been absent recently, I
know I have no right to weigh in heavily on one direction or another. I had
enough time to comment but obviously not enough to write the tooling :-) or
update the documentation.
Anyways I have talked this too much and you guys know what you're doing
better than I to manage the project. I humbly defer the judgment call to
you guys for these reasons as well as your having serious validity in your
counter argument.
Cheers,
Alex
> Alex
>>
>> On Mon, Dec 22, 2008 at 11:03 AM, Stefan Zoerner <st...@labeo.de> wrote:
>>
>>
>>
>>> Hi Alex!
>>>
>>> Alex Karasulu wrote:
>>>
>>>
>>>
>>>> Also setting up your own certificate and adding it to the DIT is pretty
>>>> easy even without specific tooling. Note that this use of the external
>>>> file
>>>> store is the antiquated way to do it. Certs were designed to be stored
>>>> in
>>>> directories in the first place. This file thing is going backwards and
>>>> often the case when you don't have a directory. Why would a directory
>>>> store
>>>> it's certs in a file when it has access to the directory store in the
>>>> first
>>>> place. If we consider the big picture the cert in the DIT way is the
>>>> best
>>>> option.
>>>>
>>>>
>>>>
>>> I see the problems with the keystore file, but the current DIT solution
>>> is
>>> IMHO not sufficient to work with for our users.
>>>
>>> Sun Java System Directory Server for instance offers tooling to create a
>>> key pair in the DIT, export a CSR (certificate signing request), and
>>> import
>>> a certificate signed from a third party.
>>>
>>> Our current implementation creates a key pair and stores it in some
>>> attributes in an entry automatically . Currently, there is no
>>> (documented)
>>> way to influence on how keys and certificate look like.
>>>
>>> I don't think that it is "pretty easy" setting up your own certificate.
>>> At
>>> least I don not have any idea on how to accomplish this task without
>>> custom
>>> application development.
>>>
>>> I have started like this:
>>>
>>> 1. Create key pair with keytool
>>> 2. Store public and private key in DIT
>>> 3. Create certificate
>>> 4. (optional) Sign certificate
>>> 5. Store (signed) certificate in DIT
>>>
>>> My problem is step 2, You can't export a private key from a keystore with
>>> keytool (AFAIK). I had to write a program for this step.
>>>
>>> Perhaps you can outline a better solution and I will document it step by
>>> step in the wiki.
>>>
>>> My favorite for the future would be an extended operation for key pair
>>> creation. It would be easy to trigger it with studio.
>>>
>>> Greetings from Hamburg,
>>> Stefan
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Emmanuel Lecharny <el...@gmail.com>.
Alex Karasulu wrote:
> I agree with you. You're right that this is not the best solution for our
> users currently. I'm thinking that we should run faster into the future
> with the tooling to support cert management in the DIT rather than reverting
> back to the use of the keystore file.
>
> When you scratch the itch with the keystore file no one will come to the
> table to really create the tooling. Once the pressure is gone, the advance
> will never happen. Let the users complain. Let them also get involved and
> affect change is what I say.
>
As much as I agree with you on the global imagine, I think that we
should also allow 'antiquated' users to play with there keystore file,
if it's just a matter of a few lines of code to be injected in the
server (and so far, it costed me less than an hour to restore those
lines). Writing the tooling to store a certificate at the right place in
the DiT, plus all the associated tests, will cost a couple of days.
I don't have time for more than that right now, and if you consider that
the current documentation tells the users how to use the keystore, that
also mean to update the documentation.
On a more general base, I think that Stefan and Christine, plus a few
others, have spent a considerable amount of time writing this doco, and
we should respect this effort. That mean we should check the current
doco to see if we will outdate it when doing some modification on the
server, and if so,n immediately reflect the change in the doco.
Now, this is not easy too, as we are always working on new features
which will be released days or even weeks (months ?) after, so the doco
will _never_ reflect the next version, or if it does, users won't have
the current version doco. Unless we find a way to have versionned
documentation.
Kiran proposed to work on the tooling, and I think it will solve
everthing, but it will take time. Hopefully, we will have them for
1.5.5, but this is not guaranteed...
> Alex
>
> On Mon, Dec 22, 2008 at 11:03 AM, Stefan Zoerner <st...@labeo.de> wrote:
>
>
>> Hi Alex!
>>
>> Alex Karasulu wrote:
>>
>>
>>> Also setting up your own certificate and adding it to the DIT is pretty
>>> easy even without specific tooling. Note that this use of the external file
>>> store is the antiquated way to do it. Certs were designed to be stored in
>>> directories in the first place. This file thing is going backwards and
>>> often the case when you don't have a directory. Why would a directory store
>>> it's certs in a file when it has access to the directory store in the first
>>> place. If we consider the big picture the cert in the DIT way is the best
>>> option.
>>>
>>>
>> I see the problems with the keystore file, but the current DIT solution is
>> IMHO not sufficient to work with for our users.
>>
>> Sun Java System Directory Server for instance offers tooling to create a
>> key pair in the DIT, export a CSR (certificate signing request), and import
>> a certificate signed from a third party.
>>
>> Our current implementation creates a key pair and stores it in some
>> attributes in an entry automatically . Currently, there is no (documented)
>> way to influence on how keys and certificate look like.
>>
>> I don't think that it is "pretty easy" setting up your own certificate. At
>> least I don not have any idea on how to accomplish this task without custom
>> application development.
>>
>> I have started like this:
>>
>> 1. Create key pair with keytool
>> 2. Store public and private key in DIT
>> 3. Create certificate
>> 4. (optional) Sign certificate
>> 5. Store (signed) certificate in DIT
>>
>> My problem is step 2, You can't export a private key from a keystore with
>> keytool (AFAIK). I had to write a program for this step.
>>
>> Perhaps you can outline a better solution and I will document it step by
>> step in the wiki.
>>
>> My favorite for the future would be an extended operation for key pair
>> creation. It would be easy to trigger it with studio.
>>
>> Greetings from Hamburg,
>> Stefan
>>
>>
>>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Alex Karasulu <ak...@gmail.com>.
I agree with you. You're right that this is not the best solution for our
users currently. I'm thinking that we should run faster into the future
with the tooling to support cert management in the DIT rather than reverting
back to the use of the keystore file.
When you scratch the itch with the keystore file no one will come to the
table to really create the tooling. Once the pressure is gone, the advance
will never happen. Let the users complain. Let them also get involved and
affect change is what I say.
Alex
On Mon, Dec 22, 2008 at 11:03 AM, Stefan Zoerner <st...@labeo.de> wrote:
> Hi Alex!
>
> Alex Karasulu wrote:
>
>> Also setting up your own certificate and adding it to the DIT is pretty
>> easy even without specific tooling. Note that this use of the external file
>> store is the antiquated way to do it. Certs were designed to be stored in
>> directories in the first place. This file thing is going backwards and
>> often the case when you don't have a directory. Why would a directory store
>> it's certs in a file when it has access to the directory store in the first
>> place. If we consider the big picture the cert in the DIT way is the best
>> option.
>>
>
> I see the problems with the keystore file, but the current DIT solution is
> IMHO not sufficient to work with for our users.
>
> Sun Java System Directory Server for instance offers tooling to create a
> key pair in the DIT, export a CSR (certificate signing request), and import
> a certificate signed from a third party.
>
> Our current implementation creates a key pair and stores it in some
> attributes in an entry automatically . Currently, there is no (documented)
> way to influence on how keys and certificate look like.
>
> I don't think that it is "pretty easy" setting up your own certificate. At
> least I don not have any idea on how to accomplish this task without custom
> application development.
>
> I have started like this:
>
> 1. Create key pair with keytool
> 2. Store public and private key in DIT
> 3. Create certificate
> 4. (optional) Sign certificate
> 5. Store (signed) certificate in DIT
>
> My problem is step 2, You can't export a private key from a keystore with
> keytool (AFAIK). I had to write a program for this step.
>
> Perhaps you can outline a better solution and I will document it step by
> step in the wiki.
>
> My favorite for the future would be an extended operation for key pair
> creation. It would be easy to trigger it with studio.
>
> Greetings from Hamburg,
> Stefan
>
>
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Stefan Zoerner <st...@labeo.de>.
Hi Alex!
Alex Karasulu wrote:
> Also setting up your own certificate and adding it to the DIT is pretty
> easy even without specific tooling. Note that this use of the external
> file store is the antiquated way to do it. Certs were designed to be
> stored in directories in the first place. This file thing is going
> backwards and often the case when you don't have a directory. Why would
> a directory store it's certs in a file when it has access to the
> directory store in the first place. If we consider the big picture the
> cert in the DIT way is the best option.
I see the problems with the keystore file, but the current DIT solution
is IMHO not sufficient to work with for our users.
Sun Java System Directory Server for instance offers tooling to create a
key pair in the DIT, export a CSR (certificate signing request), and
import a certificate signed from a third party.
Our current implementation creates a key pair and stores it in some
attributes in an entry automatically . Currently, there is no
(documented) way to influence on how keys and certificate look like.
I don't think that it is "pretty easy" setting up your own certificate.
At least I don not have any idea on how to accomplish this task without
custom application development.
I have started like this:
1. Create key pair with keytool
2. Store public and private key in DIT
3. Create certificate
4. (optional) Sign certificate
5. Store (signed) certificate in DIT
My problem is step 2, You can't export a private key from a keystore
with keytool (AFAIK). I had to write a program for this step.
Perhaps you can outline a better solution and I will document it step by
step in the wiki.
My favorite for the future would be an extended operation for key pair
creation. It would be easy to trigger it with studio.
Greetings from Hamburg,
Stefan
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Alex Karasulu <ak...@gmail.com>.
Also setting up your own certificate and adding it to the DIT is pretty easy
even without specific tooling. Note that this use of the external file
store is the antiquated way to do it. Certs were designed to be stored in
directories in the first place. This file thing is going backwards and
often the case when you don't have a directory. Why would a directory store
it's certs in a file when it has access to the directory store in the first
place. If we consider the big picture the cert in the DIT way is the best
option.
Alex
On Mon, Dec 22, 2008 at 10:37 AM, Alex Karasulu <ak...@gmail.com> wrote:
> Yes let's make sure these hurried changes don't break StartTLS. For some
> reason I think there were some issues I encountered with keeping the
> keystore on a file.
>
> Why change the present setup with the keys in the DIT if it works. I think
> this just going to cause problems down the road. Don't remember how exactly
> but my gut tells me it's going to. Sorry this is not enough information but
> I cannot remember exactly what problems I had with the previous external
> file configuration.
>
> Alex
>
>
> On Thu, Dec 18, 2008 at 3:00 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
>
>> Stefan Zoerner wrote:
>>
>>> Emmanuel Lecharny wrote:
>>>
>>>> Ok, after having looked at the code, I think we should restore the way
>>>> ADS 1.5.1 was handling an external keystore.
>>>>
>>>> What about adding the two missing parameters in server.xml ? :
>>>>
>>>> <ldapService id="ldapsService"
>>>> enabled="true"
>>>> tcpPort="10636"
>>>> enableLdaps="true"
>>>> nbTcpThreads="8">
>>>> <directoryService>#directoryService</directoryService>
>>>> </ldapService>
>>>>
>>>> should become :
>>>>
>>>> <ldapService id="ldapsService"
>>>> enabled="true"
>>>> tcpPort="10636"
>>>> enableLdaps="true"
>>>> nbTcpThreads="8"
>>>> keystoreFile="/home/user/.keystore">
>>>> certificatePassword="changeit">
>>>> <directoryService>#directoryService</directoryService>
>>>> </ldapService>
>>>>
>>>> wdyt ?
>>>>
>>>
>>> This we be a good option for those users who like the old style of using
>>> a keystore file created with standard server tools. For the current
>>> questions on the ML and my VSLDAP requirements it would be fine.
>>>
>>> Disadvantage of this approach is the plain text password in the XML file.
>>> It offers an intermediate user the chance of extracting the private key from
>>> the keystore.
>>>
>> We have no way to crypt the password... This is where this solution is
>> weak.
>>
>>>
>>> The new approach has the advantage that the private key is relatively
>>> save in the server DIT.
>>>
>>> Is it planned to support both approaches?
>>>
>> Definitively, yes. At least, this is what I have implemented, and what I'm
>> currently testing.
>>
>>> The keystore is only used if it is provided in the XML. Otherwise the key
>>> stored in the DIT is used?
>>>
>> Taht's it.
>>
>>> Or should we remove the DIT variant completely?
>>>
>> No, I think that we should consider ADS as a good KeyStore itself.
>>
>>> Alex as added in March or April; I don't remember the reason for the
>>> change.
>>>
>> I don't know why Alex removed the previous configuration, but the DIT
>> approach was the most easier one for users who don't want to deal with the
>> burden of creating a certificate, stores it into a keystore, etc. And it was
>> really smooth, as you have nothing to do to make LDAPS working with this
>> approach.
>>
>>>
>>> It would be nice to have en extended LDAP operation for key pair
>>> creation. Call parameters could carry the parameters needed. It would be
>>> easy to trigger the functionality via Studio or CL tool. Adding the keypair
>>> with an LDAP request seems not to be a good idea, because the private key
>>> should not be transported over the wire. This is perhaps a feature for the
>>> 2.0
>>>
>> We can wrap that quickly in the server, if I have a complete description
>> of what must be done. I'm not a security expert, and I don't have time to
>> become one :) Any detailed instruction will though be welcomed, as it will
>> help anyone to implement the feature.
>>
>> Thanks !
>>
>> PS: I will commit what I'm working on (related to SSL) in an hour or so.
>>
>>>
>>> Greetings from Hamburg,
>>> Stefan
>>>
>>>
>>>
>>>
>>
>> --
>> --
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>>
>
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Alex Karasulu <ak...@gmail.com>.
Yes let's make sure these hurried changes don't break StartTLS. For some
reason I think there were some issues I encountered with keeping the
keystore on a file.
Why change the present setup with the keys in the DIT if it works. I think
this just going to cause problems down the road. Don't remember how exactly
but my gut tells me it's going to. Sorry this is not enough information but
I cannot remember exactly what problems I had with the previous external
file configuration.
Alex
On Thu, Dec 18, 2008 at 3:00 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Stefan Zoerner wrote:
>
>> Emmanuel Lecharny wrote:
>>
>>> Ok, after having looked at the code, I think we should restore the way
>>> ADS 1.5.1 was handling an external keystore.
>>>
>>> What about adding the two missing parameters in server.xml ? :
>>>
>>> <ldapService id="ldapsService"
>>> enabled="true"
>>> tcpPort="10636"
>>> enableLdaps="true"
>>> nbTcpThreads="8">
>>> <directoryService>#directoryService</directoryService>
>>> </ldapService>
>>>
>>> should become :
>>>
>>> <ldapService id="ldapsService"
>>> enabled="true"
>>> tcpPort="10636"
>>> enableLdaps="true"
>>> nbTcpThreads="8"
>>> keystoreFile="/home/user/.keystore">
>>> certificatePassword="changeit">
>>> <directoryService>#directoryService</directoryService>
>>> </ldapService>
>>>
>>> wdyt ?
>>>
>>
>> This we be a good option for those users who like the old style of using a
>> keystore file created with standard server tools. For the current questions
>> on the ML and my VSLDAP requirements it would be fine.
>>
>> Disadvantage of this approach is the plain text password in the XML file.
>> It offers an intermediate user the chance of extracting the private key from
>> the keystore.
>>
> We have no way to crypt the password... This is where this solution is
> weak.
>
>>
>> The new approach has the advantage that the private key is relatively save
>> in the server DIT.
>>
>> Is it planned to support both approaches?
>>
> Definitively, yes. At least, this is what I have implemented, and what I'm
> currently testing.
>
>> The keystore is only used if it is provided in the XML. Otherwise the key
>> stored in the DIT is used?
>>
> Taht's it.
>
>> Or should we remove the DIT variant completely?
>>
> No, I think that we should consider ADS as a good KeyStore itself.
>
>> Alex as added in March or April; I don't remember the reason for the
>> change.
>>
> I don't know why Alex removed the previous configuration, but the DIT
> approach was the most easier one for users who don't want to deal with the
> burden of creating a certificate, stores it into a keystore, etc. And it was
> really smooth, as you have nothing to do to make LDAPS working with this
> approach.
>
>>
>> It would be nice to have en extended LDAP operation for key pair creation.
>> Call parameters could carry the parameters needed. It would be easy to
>> trigger the functionality via Studio or CL tool. Adding the keypair with an
>> LDAP request seems not to be a good idea, because the private key should not
>> be transported over the wire. This is perhaps a feature for the 2.0
>>
> We can wrap that quickly in the server, if I have a complete description of
> what must be done. I'm not a security expert, and I don't have time to
> become one :) Any detailed instruction will though be welcomed, as it will
> help anyone to implement the feature.
>
> Thanks !
>
> PS: I will commit what I'm working on (related to SSL) in an hour or so.
>
>>
>> Greetings from Hamburg,
>> Stefan
>>
>>
>>
>>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Emmanuel Lecharny <el...@gmail.com>.
Stefan Zoerner wrote:
> Emmanuel Lecharny wrote:
>> Ok, after having looked at the code, I think we should restore the
>> way ADS 1.5.1 was handling an external keystore.
>>
>> What about adding the two missing parameters in server.xml ? :
>>
>> <ldapService id="ldapsService"
>> enabled="true"
>> tcpPort="10636"
>> enableLdaps="true"
>> nbTcpThreads="8">
>> <directoryService>#directoryService</directoryService>
>> </ldapService>
>>
>> should become :
>>
>> <ldapService id="ldapsService"
>> enabled="true"
>> tcpPort="10636"
>> enableLdaps="true"
>> nbTcpThreads="8"
>> keystoreFile="/home/user/.keystore">
>> certificatePassword="changeit">
>> <directoryService>#directoryService</directoryService>
>> </ldapService>
>>
>> wdyt ?
>
> This we be a good option for those users who like the old style of
> using a keystore file created with standard server tools. For the
> current questions on the ML and my VSLDAP requirements it would be fine.
>
> Disadvantage of this approach is the plain text password in the XML
> file. It offers an intermediate user the chance of extracting the
> private key from the keystore.
We have no way to crypt the password... This is where this solution is weak.
>
> The new approach has the advantage that the private key is relatively
> save in the server DIT.
>
> Is it planned to support both approaches?
Definitively, yes. At least, this is what I have implemented, and what
I'm currently testing.
> The keystore is only used if it is provided in the XML. Otherwise the
> key stored in the DIT is used?
Taht's it.
> Or should we remove the DIT variant completely?
No, I think that we should consider ADS as a good KeyStore itself.
> Alex as added in March or April; I don't remember the reason for the
> change.
I don't know why Alex removed the previous configuration, but the DIT
approach was the most easier one for users who don't want to deal with
the burden of creating a certificate, stores it into a keystore, etc.
And it was really smooth, as you have nothing to do to make LDAPS
working with this approach.
>
> It would be nice to have en extended LDAP operation for key pair
> creation. Call parameters could carry the parameters needed. It would
> be easy to trigger the functionality via Studio or CL tool. Adding the
> keypair with an LDAP request seems not to be a good idea, because the
> private key should not be transported over the wire. This is perhaps a
> feature for the 2.0
We can wrap that quickly in the server, if I have a complete description
of what must be done. I'm not a security expert, and I don't have time
to become one :) Any detailed instruction will though be welcomed, as it
will help anyone to implement the feature.
Thanks !
PS: I will commit what I'm working on (related to SSL) in an hour or so.
>
> Greetings from Hamburg,
> Stefan
>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hammond, Steve wrote:
> >From what I remember from when it was moved, it is required to be in the
> Server DIT for StartTLS to work. I don't know the reason for that tho.
>
Ok, I just committed the fix. One can now use both system.
The new configuration for using an external keystore is :
<ldapService id="ldapsService"
enabled="true"
tcpPort="10636"
enableLdaps="true"
nbTcpThreads="8"
keystoreFile="/home/elecharny/zanzibar.ks"
certificatePassword="mypassword">
<directoryService>#directoryService</directoryService>
</ldapService>
If one want to use the internal keystore, it's enough to simply remove
the last two parameters :
<ldapService id="ldapsService"
enabled="true"
tcpPort="10636"
enableLdaps="true"
nbTcpThreads="8">
<directoryService>#directoryService</directoryService>
</ldapService>
This will be available for 1.5.5
If you have any suggestion, feel free to reply to this mail !
Thanks !
PS : I will update the site accordingly.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
RE: [ApacheDS] Setting up my own certificate for SSL
Posted by "Hammond, Steve" <st...@Polycom.com>.
>From what I remember from when it was moved, it is required to be in the
Server DIT for StartTLS to work. I don't know the reason for that tho.
-----Original Message-----
From: Stefan Zoerner [mailto:stefan@labeo.de]
Sent: Thursday, December 18, 2008 12:03 PM
To: Apache Directory Developers List
Subject: Re: [ApacheDS] Setting up my own certificate for SSL
Emmanuel Lecharny wrote:
> Ok, after having looked at the code, I think we should restore the way
> ADS 1.5.1 was handling an external keystore.
>
> What about adding the two missing parameters in server.xml ? :
>
> <ldapService id="ldapsService"
> enabled="true"
> tcpPort="10636"
> enableLdaps="true"
> nbTcpThreads="8">
> <directoryService>#directoryService</directoryService>
> </ldapService>
>
> should become :
>
> <ldapService id="ldapsService"
> enabled="true"
> tcpPort="10636"
> enableLdaps="true"
> nbTcpThreads="8"
> keystoreFile="/home/user/.keystore">
> certificatePassword="changeit">
> <directoryService>#directoryService</directoryService>
> </ldapService>
>
> wdyt ?
This we be a good option for those users who like the old style of using
a keystore file created with standard server tools. For the current
questions on the ML and my VSLDAP requirements it would be fine.
Disadvantage of this approach is the plain text password in the XML
file. It offers an intermediate user the chance of extracting the
private key from the keystore.
The new approach has the advantage that the private key is relatively
save in the server DIT.
Is it planned to support both approaches? The keystore is only used if
it is provided in the XML. Otherwise the key stored in the DIT is used?
Or should we remove the DIT variant completely? Alex as added in March
or April; I don't remember the reason for the change.
It would be nice to have en extended LDAP operation for key pair
creation. Call parameters could carry the parameters needed. It would be
easy to trigger the functionality via Studio or CL tool. Adding the
keypair with an LDAP request seems not to be a good idea, because the
private key should not be transported over the wire. This is perhaps a
feature for the 2.0
Greetings from Hamburg,
Stefan
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Stefan Zoerner <st...@labeo.de>.
Emmanuel Lecharny wrote:
> Ok, after having looked at the code, I think we should restore the way
> ADS 1.5.1 was handling an external keystore.
>
> What about adding the two missing parameters in server.xml ? :
>
> <ldapService id="ldapsService"
> enabled="true"
> tcpPort="10636"
> enableLdaps="true"
> nbTcpThreads="8">
> <directoryService>#directoryService</directoryService>
> </ldapService>
>
> should become :
>
> <ldapService id="ldapsService"
> enabled="true"
> tcpPort="10636"
> enableLdaps="true"
> nbTcpThreads="8"
> keystoreFile="/home/user/.keystore">
> certificatePassword="changeit">
> <directoryService>#directoryService</directoryService>
> </ldapService>
>
> wdyt ?
This we be a good option for those users who like the old style of using
a keystore file created with standard server tools. For the current
questions on the ML and my VSLDAP requirements it would be fine.
Disadvantage of this approach is the plain text password in the XML
file. It offers an intermediate user the chance of extracting the
private key from the keystore.
The new approach has the advantage that the private key is relatively
save in the server DIT.
Is it planned to support both approaches? The keystore is only used if
it is provided in the XML. Otherwise the key stored in the DIT is used?
Or should we remove the DIT variant completely? Alex as added in March
or April; I don't remember the reason for the change.
It would be nice to have en extended LDAP operation for key pair
creation. Call parameters could carry the parameters needed. It would be
easy to trigger the functionality via Studio or CL tool. Adding the
keypair with an LDAP request seems not to be a good idea, because the
private key should not be transported over the wire. This is perhaps a
feature for the 2.0
Greetings from Hamburg,
Stefan
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Emmanuel Lecharny <el...@gmail.com>.
Ok, after having looked at the code, I think we should restore the way
ADS 1.5.1 was handling an external keystore.
What about adding the two missing parameters in server.xml ? :
<ldapService id="ldapsService"
enabled="true"
tcpPort="10636"
enableLdaps="true"
nbTcpThreads="8">
<directoryService>#directoryService</directoryService>
</ldapService>
should become :
<ldapService id="ldapsService"
enabled="true"
tcpPort="10636"
enableLdaps="true"
nbTcpThreads="8"
keystoreFile="/home/user/.keystore">
certificatePassword="changeit">
<directoryService>#directoryService</directoryService>
</ldapService>
wdyt ?
Stefan Seelmann wrote:
> Hi Stefan,
>
> Stefan Zoerner schrieb:
>
>> Hi all,
>>
>> I am facing some problems with the current (since 1.5.3, I assume) SSL
>> configuration. In earlier days, it was possible to provide a keystore
>> with the public/private key, certificate etc. here
>>
>> http://cwiki.apache.org/confluence/display/DIRxSRVx11/3.3.+How+to+enable+SSL
>>
>>
>> Now, the server creates a keypair when it starts the first time and
>> stores it in the entry uid=admin,ou=system, in different attributes.
>>
>> To be honest: This is an example why our documentation is so bad. The
>> old behavior has been well described in the docs. Someone changed it
>> completely, and did not update the docs. Same situation holds true for
>> the whole configuration. :-(
>>
>> Nevertheless, the new SSL functionality seems to be simpler, because it
>> is possible to set it up automatically. But if I plan to use a custom
>> certificate, it should be at least possible. Today, there was a
>> corresponding question on the user list.
>>
>> I wanted to update the docs to reflect the changes, and I am still
>> trying to figure out, what an easy way for our users would be.
>>
>> A question for the current implementation: Is there any way to
>> configure/influence the key creation at startup? I assume no, but
>> perhaps I am missing something.
>>
>
> I have no idea. The only direction I could point you to the class where
> the initial private key and certificate are created, see [1].
>
>
>> Currently, the only way to set up my own certificate is modifying the
>> attribute values for uid=admin,ou=system
>>
>> This is not an easy task, because we do not have any tools for that.
>> There is no wizard in Studio yet. Even if there would be one -- it
>> should be possible without a UI client, ...
>>
>
> You are right, if we create some tooling we should put all common code
> into the shared libraries, and then create a wizard for studio and a
> CL-tool.
>
>
>> I was able to store my private key, but I am a little bit confused about
>> some attribute. What exactly is contained in userCertificate and what in
>> publicKey?
>>
>> I assume, userCertificate holds the certificate the server presents to
>> client. But why do we need publicKey as well. I think it is contained in
>> the userCertificate. No?
>>
>
> I assume too.
>
> Kind Regards,
> Stefan
>
>
> [1]
> http://svn.apache.org/viewvc/directory/apacheds/trunk/core/src/main/java/org/apache/directory/server/core/security/TlsKeyGenerator.java?view=markup
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Stefan Seelmann <se...@apache.org>.
Hi Stefan,
Stefan Zoerner schrieb:
> Hi all,
>
> I am facing some problems with the current (since 1.5.3, I assume) SSL
> configuration. In earlier days, it was possible to provide a keystore
> with the public/private key, certificate etc. here
>
> http://cwiki.apache.org/confluence/display/DIRxSRVx11/3.3.+How+to+enable+SSL
>
>
> Now, the server creates a keypair when it starts the first time and
> stores it in the entry uid=admin,ou=system, in different attributes.
>
> To be honest: This is an example why our documentation is so bad. The
> old behavior has been well described in the docs. Someone changed it
> completely, and did not update the docs. Same situation holds true for
> the whole configuration. :-(
>
> Nevertheless, the new SSL functionality seems to be simpler, because it
> is possible to set it up automatically. But if I plan to use a custom
> certificate, it should be at least possible. Today, there was a
> corresponding question on the user list.
>
> I wanted to update the docs to reflect the changes, and I am still
> trying to figure out, what an easy way for our users would be.
>
> A question for the current implementation: Is there any way to
> configure/influence the key creation at startup? I assume no, but
> perhaps I am missing something.
I have no idea. The only direction I could point you to the class where
the initial private key and certificate are created, see [1].
>
> Currently, the only way to set up my own certificate is modifying the
> attribute values for uid=admin,ou=system
>
> This is not an easy task, because we do not have any tools for that.
> There is no wizard in Studio yet. Even if there would be one -- it
> should be possible without a UI client, ...
You are right, if we create some tooling we should put all common code
into the shared libraries, and then create a wizard for studio and a
CL-tool.
>
> I was able to store my private key, but I am a little bit confused about
> some attribute. What exactly is contained in userCertificate and what in
> publicKey?
>
> I assume, userCertificate holds the certificate the server presents to
> client. But why do we need publicKey as well. I think it is contained in
> the userCertificate. No?
I assume too.
Kind Regards,
Stefan
[1]
http://svn.apache.org/viewvc/directory/apacheds/trunk/core/src/main/java/org/apache/directory/server/core/security/TlsKeyGenerator.java?view=markup
Re: [ApacheDS] Setting up my own certificate for SSL
Posted by Emmanuel Lecharny <el...@gmail.com>.
Stefan Zoerner wrote:
> Hi all,
>
> I am facing some problems with the current (since 1.5.3, I assume) SSL
> configuration. In earlier days, it was possible to provide a keystore
> with the public/private key, certificate etc. here
>
> http://cwiki.apache.org/confluence/display/DIRxSRVx11/3.3.+How+to+enable+SSL
>
>
> Now, the server creates a keypair when it starts the first time and
> stores it in the entry uid=admin,ou=system, in different attributes.
>
> To be honest: This is an example why our documentation is so bad. The
> old behavior has been well described in the docs. Someone changed it
> completely, and did not update the docs. Same situation holds true for
> the whole configuration. :-(
/me and the dev team hiding under a rock ...
>
> Nevertheless, the new SSL functionality seems to be simpler, because
> it is possible to set it up automatically. But if I plan to use a
> custom certificate, it should be at least possible. Today, there was a
> corresponding question on the user list.
>
> I wanted to update the docs to reflect the changes, and I am still
> trying to figure out, what an easy way for our users would be.
>
> A question for the current implementation: Is there any way to
> configure/influence the key creation at startup? I assume no, but
> perhaps I am missing something.
>
> Currently, the only way to set up my own certificate is modifying the
> attribute values for uid=admin,ou=system
>
> This is not an easy task, because we do not have any tools for that.
> There is no wizard in Studio yet. Even if there would be one -- it
> should be possible without a UI client, ...
>
> I was able to store my private key, but I am a little bit confused
> about some attribute. What exactly is contained in userCertificate and
> what in publicKey?
>
> I assume, userCertificate holds the certificate the server presents to
> client. But why do we need publicKey as well. I think it is contained
> in the userCertificate. No?
I gonna check that. You know, to be honest, if I started to update the
page about configuration, it's because I was totally lost in
configuration. I can read the code, but there are many new parameters I
don't know about. At some point, as I needed to add a new configuration
parameter, I just told me "look, emmanuel, this is an insane
situation... You can't even figure out what should be found in the
server.xml, and what is valid or invalid... Time to write doco !"
So I started ...
It's not specially funny, and I can feel the pain for those who created
the initial doco, seeing all what they did totally FU. Not to mention
our users !
So, time to wake up and kick some asses !
/me writing docs ;)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org