Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 81097 invoked from network); 23 Dec 2008 03:07:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Dec 2008 03:07:58 -0000 Received: (qmail 14184 invoked by uid 500); 23 Dec 2008 03:07:58 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 13988 invoked by uid 500); 23 Dec 2008 03:07:57 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 13979 invoked by uid 99); 23 Dec 2008 03:07:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Dec 2008 19:07:57 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.218.11 as permitted sender) Received: from [209.85.218.11] (HELO mail-bw0-f11.google.com) (209.85.218.11) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Dec 2008 03:07:51 +0000 Received: by bwz4 with SMTP id 4so7000070bwz.1 for ; Mon, 22 Dec 2008 19:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=UHAKu+qwUxvowkxXxgiVyPROue6lcHsXcAOjS+83Q7U=; b=oCfcC5fZtZydznYmEEQF/iGN2LdGVa2EQ+6g/aH/tHH4pGokptWek8mR3GHwUEUyYw KZxN02HbSL2b41210k9Ov6Xwh/UeD7WYDdmpp3f38QzUyM+pFmsloRQhv03SxTNAeXJ0 APoeZ2NqQ10lV7D4K2OcVMyqc3VPm6zFbdN9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=NK2kQu9cgY0dUxXmVA9Cm3aUlXJaCYYz1V7xAz4gnqSV6IvWtL2LUbJWRsYfEPBD50 dzP4TT0LJjz2f+RWp5osmPmr8neMAEu6ubTygMu4g+CgATb5Py04v9+gqVgTElwZ2a6n cx7LIx4TODYpc/kEjm4NURbb3t7hqoypijw7I= Received: by 10.223.112.83 with SMTP id v19mr5580697fap.66.1230001647894; Mon, 22 Dec 2008 19:07:27 -0800 (PST) Received: by 10.223.103.200 with HTTP; Mon, 22 Dec 2008 19:07:27 -0800 (PST) Message-ID: Date: Mon, 22 Dec 2008 22:07:27 -0500 From: "Alex Karasulu" To: "Apache Directory Developers List" Subject: Re: [ApacheDS] Setting up my own certificate for SSL In-Reply-To: <494FBA68.8000800@labeo.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_76808_3831987.1230001647887" References: <49496318.1010700@labeo.de> <49496A6B.40703@apache.org> <494A624E.3040604@nextury.com> <494A9E73.6050906@labeo.de> <494AABCA.3030206@nextury.com> <494FBA68.8000800@labeo.de> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_76808_3831987.1230001647887 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 > > ------=_Part_76808_3831987.1230001647887 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 <stefan@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


------=_Part_76808_3831987.1230001647887--